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

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 <ml-AT-vdspek.org> 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
http://www.boostpro.com