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

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2008-02-15 11:11:26

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.

> 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.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail