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@boostpro.com> 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