Re: [boost] Why Boost.Build?

Subject: Re: [boost] Why Boost.Build?
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2011-03-29 20:38:47

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