From: Andy Moreton (andy.moreton_at_[hidden])
Date: 2005-09-20 13:52:38
On Tue, 20 Sep 2005 17:08:04 GMT, Edward Diener wrote:
> David Abrahams wrote:
>> Kevin Wheatley <hxpro_at_[hidden]> writes:
>>>David Abrahams wrote:
>>>>On the Boost.Build list we were just discussing the fact that some
>>>>people otherwise inclined towards Boost have chosen Scons over
>>>>Boost.Build. It would be useful for us to understand some of the
>>>>reasons why, if some of you wouldn't mind letting us know. No flames,
>>>not a flame, but some test results (Noel Llopis' Blog) shows a few
>>>These are updated from previously.
>> Wow, harsh. The numbers aside, I think his commentary is rather
> The speed of a build should hardly be the entire reason for determining
> what build system to use, but it was the total reason for recommending
> build systems in the article mentioned above.
Correctness comes first, but I think the article was reasonably fair. The
author is trying to find a build system to solve a real-world problem. The
requirements that it should be fast, simple to customise for other
platforms and tools and perform as well on incremental builds as on full
rebuilds seem a reasonable place to start. If the synthetic benchmark he
uses seems unfair, please produce some constructive criticism as to how it
can be made more realistic.
Returning to the title of the thread, the only things I've used BBv1 and
BBv2 for are building Boost itself, and some toy projects (the exercises
from the TMP book). Based on that (limited) experience, I would not
consider [b]jam or BoostBuild for any serious work. Producing a language
with more baroque and undebuggable syntax and semantics than 'make' takes
I think that the effort expended on BBv1/BBv2 would have been far better
spent on fixing the performance issues in scons.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk