Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2005-09-16 06:00:54

"Ralf W. Grosse-Kunstleve" <rwgk_at_[hidden]> writes:

> --- Larry Evans <cppljevans_at_[hidden]> wrote:
>> On 09/14/2005 06:56 AM, rwgk wrote:
>> [snip]
>> > - Since I am quite happy with SCons it would take something vastly
>> > better to motivate me to switch. The syntax would have to be at least
>> > as nice and powerful as Python.
>> From my *brief* look at:
>> it appears that scons requires the user to decide to separate
>> the different variant buids into different directories, and
>> the directory names also have to be specified by the user.
>> In constrast, bjam does this for the programmer, IIUC.
> That's probably right.
> I cannot afford/never wanted variant builds. On the fastest machine with 8 CPUs
> our build from scratch takes about 5 minutes. On the slowest machine with 1 CPU
> it takes about 10 hours. For one variant. Maintaining multiple variants would
> be impractical. Therefore to me bjam's creative directory trees seemed overly
> complicated. It is hard to find the results of a build.

bjam writes the full path of the target to stdout as it is built, and
you can always use a stage directory to gather your targets nearby.
However, for me, it's rare that I actually need to find the file
anyway. I run my tests through Boost.Build.

> I also never figured out how to get bjam to build a specific target

bjam target-name

> maybe since I never had the patience to figure out the complicated
> path names.

You don't need to name the path.

> Whith the scons repository support, the build directory
> is the current working directory. The path names of the generated
> files were obvious to me from day one. I can use file-name
> completion ("tab") to specify rebuilding of specific targets. I can
> easily rebuild specific targets with custom compilation flags by
> capturing the scons output, editing it (i.e. to change -O3 to -O0
> -g) and submitting them with a tiny script. Most of the time I know
> exactly in which translation unit the bug is located and just
> recompiling this one unit is fully sufficient to support debugging.

I don't want my build system to encourage that kind of
flying-by-the-seat-of-one's-pants. Reliability and speed need to go
together. Of course, I'm willing to sacrifice scons' md5 checks and
just use timestamps, so what does that tell you?

Dave Abrahams
Boost Consulting

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at