Re: [boost] Why Boost.Build?

Subject: Re: [boost] Why Boost.Build?
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-03-29 21:48:26

At Tue, 29 Mar 2011 17:46:48 -0700,
Steven Watanabe wrote:
> 
> AMDG
> 
> On 03/29/2011 05:04 PM, Dave Abrahams wrote:
> >
> > Part of that is because the design tries to do too much.
> > Specifically, the production of multiple build configurations with a
> > single build command offers most users no benefit in exchange for the
> > enormous complication it causes in design, implementation, and
> > especially in writing build instructions (Jamfiles in our case).
> 
> Whatever you're talking about here, it's outside of
> my experience. I have never written a Jamfile that
> was made significantly more complex by the fact that
> multiple configurations can be built at once.

Then you either haven't done anything outside of the absolute basics
(which I know is not the case), or you can't see the complexity for
some reason.

> > For
> > the few who do benefit from the feature, the ability to build multiple
> > configurations easily could have been written as another layer that
> > invokes the build system multiple times.
> >
> 
> I disagree.  Being able to build multiple variants of libraries is
> pretty much a must-have on Windows, given that debug and release are
> not necessarily ABI compatible.  

Of course it is.  But you don't have to do it in one invocationi of
the basic build tool.  You could configure builds from different root
build directories.  And then yous can automate that to make it
seamless, if that's what you need.

> I guess it doesn't matter much to me /how/ it's handled, 

*Exactly*.

> but it can't be treated as an afterthought that doesn't really
> matter.

I didn't say it doesn't matter.  I said they way we dealt with the
requirement made the solution more complex for everyone.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com