Martin Slater
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???
This test was subsequently debunked as non-representative: it happened to hit an odd performance corner in Boost.Build because of the way artificial source file naming interacted with some of Boost.Jam's internals. That issue has since been fixed. http://article.gmane.org/gmane.comp.lib.boost.build/10160 -- Dave Abrahams Boost Consulting www.boost-consulting.com