On Tue, 20 Sep 2005 17:08:04 GMT, Edward Diener wrote:
David Abrahams wrote:
Kevin Wheatley <hxpro@cinesite.co.uk> 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, please!
not a flame, but some test results (Noel Llopis' Blog) shows a few interesting results:
http://tinyurl.com/7fdns (www.gamesfromwithin.com)
These are updated from previously.
Wow, harsh. The numbers aside, I think his commentary is rather flame-ish.
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 some doing. I think that the effort expended on BBv1/BBv2 would have been far better spent on fixing the performance issues in scons. AndyM