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

Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
From: paul (pfultz2_at_[hidden])
Date: 2017-06-21 16:54:30

On Wed, 2017-06-21 at 16:44 +0100, Niall Douglas via Boost wrote:
> 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.

Before cmake 3.0. CMake 3.0 introduced interface targets(mainly to support
boost libraries), which allow you to link in usage requirements.