Re: Scons vs BBv2

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:
>> 
>> http://www.scons.org/doc/HTML/scons-user/c2029.html
>> 
>> 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
www.boost-consulting.com