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

Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
From: Peter Dimov (lists_at_[hidden])
Date: 2017-06-21 13:46:49

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.

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.