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.