From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2008-02-15 05:31:31
K. Noel Belcourt wrote:
> In our projects, we find the bjam startup time (the time for the
> first build action to run) can be very lengthy (anywhere from 2-6
> minutes or more, on fast hardware with all source files located on
> local disks). This is entirely due to the size of our projects, the
> large numbers of files involved, and we accept this. But one of our
> more common development use cases occurs where a developer repeatedly
> edits the same small number of files, then builds and debugs their
> changes, and then repeats the cycle. In this development model, the
> developer isn't altering any dependencies so the exact same set of
> files are compiled and linked each time, with no changes to include
> or library paths, or anything.
I've brought up the subject in this mailing list some time ago (but can't
find the actual posts in the archive). IIRC, what I was asking for was the
ability to limit the header scanning to e.g. the "immediate" include
I also seem to remember some discussion about the more complex scenario of
having a dedicated "bjam daemon" running in the background and continously
updating the dependency information for certain projects.
> Because the bjam startup time can be very long and the dependencies
> are not changing, I believe it would be useful to add the ability for
> bjam to write out the build actions to a file that our developers
> could then execute (e.g. as a shell script) to dramatically shorten
> their development cycle times.
I'd prefer an additional switch to bjam if possible, e.g.
"bjam --no-external-deps" (or perhaps "bjam --fast-and-unsafe").
> Would this capability be useful to the community?
Yes, definitely (especially for us test-first programmers)!
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk