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
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk