Re: [boost] [ot] choosing a build system

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 <matt.chambers42-AT-gmail.com> 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
http://www.boostpro.com