Re: scons and bjam

From: David Abrahams (dave_at_[hidden])
Date: 2004-06-29 10:40:10

Vladimir Prus <ghost_at_[hidden]> writes:

> Toon Knapen wrote:
>> Continuing the discussion on using C++ and/or python for implementing
>> the future bjam I have some related question that I think is very
>> important to the bjam community for knowing our strong and weak points
>> compared to other systems:
>>
>> How would you (dear bjam developers) compare the advantages and
>> disadvantages of scons and bjam-v2 ? Would you consider a system based
>> on scons but dealing with Jamfile's better than an 100% scons solution
>> and why?
>
> In my opinion, V2 has some advantages: 
>
> - strong support for build variants/features
> - portability of Jamfiles: you use features, not specific options of specific 
> compiler
> - convenient features like project requirements and usage requirements
> - nice toolsets
> - ... something else I've forgotten ...
>
> The obvious advantage of SCons is use of signatures, though I'm not 100% sure 
> how critical it is -- we have only one case where they would be really needed 
> -- Boost.Book.

I'm not even sure that's a big advantage. It's just a way to track
changes more reliably than by using timestamps, right?

> Probably, SCons performs better as a build engine -- e.g. dependencies on 
> generated headers, scanning targets after they are created and so on. We have 
> those two things I've described, but they are based on a non-so-ideal jam 
> engine.

I think I basically agree with Vladimir, but I'll say it differently:
what Scons has over Boost.Build v2 is mostly "what Scons has over
bjam". 

In other words, the low-level architecture of Scons for handling
targets, dependencies, invoking build actions, etc. is superior, and
its scripting language is superior. One area where Python loses to
Jam IMO is that Python isn't well-tuned, syntactically, to the job of
writing build specifications (like Jamfiles).

I think Scons mostly lacks anything that corresponds to the
higher-level layer of Boost.Build.

> One thing on which I'm not sure is how SCons constructs the set of 
> transformations to build the final target from sources. Maybe it's something 
> we can look at.

I don't think Scons contains anything nearly so smart as what we're
doing, and especially not so smart as what's in
tools/build/v2/generators_prototype.py.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com