On 3/29/2011 7:04 PM, Dave Abrahams wrote:
The design made this tradeoff because it was primarily trying to serve developers and testers of Boost libraries on multiple toolsets. That turns out to not be the primary audience of our build system, since users end up having to deal with it---but even if that were the primary audience, I doubt that scaling the steep learning curve would be worth the benefit overall.
Even though I was the one who contributed to the increase of end users dealing with BBv2, with the creation of the build&install support, I've always been a proponent that having users rely on the Boost build setup is a bug. I.e. users should be able to drop source code into their own build system without *any* other extra effort. And the fact that many Boost libraries can't do that is sad. So Boost end users should *not* be the primary audience! And like Emil says in reply to this also, for those of us that use BBv2 the only painful drawback is the speed. Which is solvable in many ways. One of which, porting to Python, has shown the likely speed improvements. To put it another way.. Jam is an OK designed scripting base for BBv2.. But bjam is a terrible implementation of that design :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail