Boost logo

Boost :

Subject: Re: [boost] [ot] choosing a build system
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-05-21 12:47:15

on Tue May 15 2012, Matthew Chambers <> wrote:

> On 5/14/2012 2:36 AM, Dave Abrahams wrote:
>> Right. And 90% of use-cases don't want to take care of any of those
>> things. That's why we wrote the rules as we did. Generating all the
>> possible variants of a library is a packager's job, not part of the
>> regular development workflow nor something that users regularly want.
> If multiple library variants are desired to be supported, then it
> shouldn't just be part of the regular development workflow, it should
> be part of continuous integration.

Strike "just," and I agree with you. Most CI should go on somewhere
away from the average developer's machine, although it's always good to
be able to duplicate that procedure locally.

> Boost.Build makes it much easier for me to create various build
> configurations targeting the different variants without cluttering the
> build files.

Right. And Ryppl is going going to add what's necessary in a layer on
top of cmake. In fact, this would be a good time to find out what it is
that you need so that we can implement it in the Ryppl build tool.

> For an application that only cares about building one way, the extra
> abstraction isn't so useful, I agree. For libraries, it's very useful.

Why should "building-many-ways" be more of a concern for libraries than
for applications?

Dave Abrahams
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at