Re: [boost] Why Boost.Build?

Subject: Re: [boost] Why Boost.Build?
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2011-03-30 02:59:50

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).  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.

It would be true if all you ever wanted was to build *everything*
using the same set of properties. However, if there's need to
variate build properties of specific targets, outer wrapper
just will not work.

Say, program_option runs some tests using static link and some tests 
using shared link, which naturally builds the library itself twice 
with different configurations. Trying to do that with naive wrappers 
would mean you'd build *all* tests both using static linking and shared 
linking, at extreme expense of testing time. Of course, you can add some
conditional to run some tests using static linking, no matter what, and 
very soon you'll reinvent all of Boost.Build again.

In practice, while new users are often confused about declarative nature,
maybe due insufficiently clear treatment of that in the docs, I can definitely
tell you that it's not a big problem going forward. Conditional requirements,
like

        <toolset>gcc:<cxxflags>whatever

is something that seem to cause next to zero queries on Boost.Build mailing list
and on IRC. 

- Volodya

-- 
Vladimir Prus
Mentor Graphics
[phone]