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.