Re: [boost] Why Boost.Build?

Subject: Re: [boost] Why Boost.Build?
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-03-30 03:23:04

On 30/03/2011 02:04, 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.
>
> 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.

Just a quick word to say that after I've done a lot of work with CMake, 
some non-trivial, I've come to fully agree with you.

Setting up a single configuration in an outside directory with CMake and 
building it there makes things much simpler than the Boost.Build 
paradigm of building everything at once whenever you want to write 
simple code and let the user configure it to get what he wants.
It's simply less overwhelming to only have to consider one process at a 
time.
The separation between procedural code executed by cmake at configure 
time and the resolving of targets with dependencies by make at build 
time is also a great plus: that allows to have easy scripting within the 
CMakeLists.txt themselves.

I'm actually quite looking forwarding to seeing the scripting 
capabilities of Boost.Build with the Python rewrite.

What I'm still missing from CMake is the many high-level and 
high-portability features of Boost.Build.
With CMake I often find myself writing my own modules to portably enable 
some flags etc.