Boost logo

Boost :

Subject: Re: [boost] [ot] choosing a build system
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-05-14 03:36:11

on Sat May 12 2012, Olaf van der Spek <> wrote:

> On Sat, May 12, 2012 at 5:56 AM, Dave Abrahams <dave_at_[hidden]> wrote:
>> You mean, in a single build run?
>> This is exactly the sort of situation where I think the abstraction
>> capabilities you're wishing for are a net loss.  It's not that much
>> better to write
>>     lib foo : a.cpp b.cpp : : <link>static <link>shared ;
>>     (or is it <link>static/shared?  I forget.  And that's part of the
>>      problem)
>> than it is to write
>>     set(sources a.cpp b.cpp)
>>     add_library(foo STATIC ${sources})
>>     add_library(foo SHARED ${sources})
>> and the latter one matches up really well with what users understand.
>> Furthermore, anyone who wants to build a library both ways with less
>> boilerplate can write a simple function that does it.
> Except that not all variants should be build on all platforms. Linux
> (probably) doesn't need the static ones. And on Windows you're missing
> the static runtime one.
> Your rules don't appear to take care of variant naming either.

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.

Dave Abrahams
BoostPro Computing

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