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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk