Re: [boost] Why Boost.Build?

Subject: Re: [boost] Why Boost.Build?
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-03-29 20:04:25

At Sun, 27 Mar 2011 11:34:43 -0400,
Edward Diener wrote:

> When software is very good, but very complicated, it is often hard to
> get developers to realize that it is to their interest to explain the
> software as methodically and as thoroughly as they should. 

Yes, but there is an alternative: simpler software (where one element
of simplicity is similarity to, and a foundation of, tools and
paradigms with which many people are already familiar).

> They often resent it because they have produced this wonderful
> software system which they understand, and worked very hard on, and
> they can not understand why others should not understand it as well
> as they do with the explanation they produce to suit their own
> needs. I honestly believe this is the mindset into which the
> developers of Boost Build have settled. The system itself is
> wonderful, and does a tremendous number of things automatically for
> the developer, but when the developer needs to do something outside
> the normal way the Boost Build system operates, it is next to
> impossible finding this information in the documentation, because so
> much is missing or just assumes that the programmer should somehow
> know.

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.

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.

Just so it's clear I'm not blaming anyone else: these problems are as
much due to my own shortsightedness as to anything else.

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