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!
Just something I came across on another mailing list you may be interested in. Martin ----------------------------------------------------------------- I keep meaning to put up a followup article to the build system one. I consider a bunch of other build systems, including Boost.Jam. I looked into Boost.Jam because it was supposed to be the great followup to Jam, with all the little things fixed and support for a bunch of very useful things out of the box. Well, somebody dropped the ball big time with that. First of all, I found Boost.Jam to be extremely complex (nothing like the original Jam, which wasn't exactly simple either). But the big problem was performance. Here's a comparison of a build with the same set of files: Jam on Windows: - Full rebuild: 6m 52s - Incremental build: 3.1s - Incremental single libray: 0.3s BoostBuild v2 (3.1.10) on Windows: - Full rebuild: 12m 03s - Incremental build: 55.5s - Incremental single libray: 2.0s I find the difference in performance simply baffling. How bad can you screw up the performance of a full build using the same compiler??? Anyway, as I said, I'll put up a full article this weekend including results for Boost.Jam, Ant, Nant, VS2005 and a few others. --Noel Games from Within http://www.gamesfromwithin.com -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.24/100 - Release Date: 13/09/2005