Re: [boost] [cmake] Minimum viable cmakeification for Boost

Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-21 15:44:41

On 21/06/2017 14:46, Peter Dimov via Boost wrote:
> Niall Douglas wrote:
> 
>> > The one remaining question I have here is how does a library link to
>> its > dependency. The obvious approach seems to be for filesystem::sl
>> to link > to system::sl and for filesystem::dl to link to system::dl,
>> right? (And > a hypothetical filesystem::hl would probably link to
>> system::sl.)
> ...
> 
>> That's the default convention I've always followed in my own code.
> 
> It's more complex than that. Even header-only libraries would need all
> three subtargets, for several reasons. One, we want the dependency
> enumeration to be scripted and therefore not depend on library
> specifics. Two, we can have chains pumpkin -> asio -> system, where I
> want pumpkin::static to propagate down to system::static, for which I'd
> need it to link to asio::static.
> 
> There's also the question of the "maintainer-preferred" default
> subtarget. If plain asio maps to asio::header, as is natural because it
> _is_ ::header, this will propagate down to system and switch it into
> header-only mode, and I probably don't want that. So the default, even
> for header-only libraries, would need to be, f.ex. ::static.
> 
> In addition to all that, we want some sort of error to be issued when
> the project links to both system::static and system::shared -- not sure
> how this is done in CMake.
> 
> All in all, I think that if we keep this scheme, we need to drop
> ::header and stick to ::static and ::shared. This will eliminate the
> surprise of header-only libraries linking to ::header targets downstream.

Before cmake 3.5 you couldn't add dependencies to header only targets on
the basis of your reasoning. So end users had to know what a header only
targets also needed to be linked against.

However, it was fixed. It turns out that end users really like to be
able to target_link_libraries() to some library and not have to care
about what dependencies that library itself has or indeed anything else
for the same reason as they like auto-linking. They don't want to have
to care about that stuff.

In the real world of course, most use of header only libraries is
wrapped into a precompiled header. The number of individual users not
using precompiled headers is probably higher, but in terms of corporate
users it's rare not to see precompiled headers. One little trick I
occasionally do for clients is to replace precompiled headers with
static libraries and I often halve the compile times. People underrate
static libraries.

> We may also think about the alternative of giving control of whether
> system means system::static or system::shared to root level, and only
> express dependencies using the unsuffixed form.

That's another possibility, and I can see the attraction.

But I suspect this is cart before horse, mountain out of molehill stuff.
I think 98% of end users are wholly doing one of these three use cases:

1. All shared Boost libraries.

2. All static Boost libraries.

3. Precompiled headers/Header only Boost libraries.

So keep it simple for now, support those three, see what happens after
an extended beta programme.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/