Re: [Boost-build] Improving development (edit, build, debug) cycle times

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2008-02-18 03:06:08

Rene Rivera wrote:
> Johan Nilsson wrote:
>> 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.
>
> There's already such an option. Which is now buggy because the
> response file feature.

[ The above wasn't my comment. Please reply to the correct posting. ]

>
>> 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 directories.
>>
>> 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.
>
> And those discussions I likely pointed out that it's not the
> dependency scanning that is slow. Currently the slow part is the
> string manipulations, i.e. memory usage, which things like feature
> propagation and manipulations that BBv2 does aggravates.

I'm convinced that you're correct on this, but: If dependency scanning could 
be minimized on demand, wouldn't memory usage benefit as well?

/ Johan