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. However, it was fixed. It turns out that end users really like to be able to target_link_libraries() to some library and not have to care about what dependencies that library itself has or indeed anything else for the same reason as they like auto-linking. They don't want to have to care about that stuff. In the real world of course, most use of header only libraries is wrapped into a precompiled header. The number of individual users not using precompiled headers is probably higher, but in terms of corporate users it's rare not to see precompiled headers. One little trick I occasionally do for clients is to replace precompiled headers with static libraries and I often halve the compile times. People underrate static libraries.
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.
That's another possibility, and I can see the attraction. But I suspect this is cart before horse, mountain out of molehill stuff. I think 98% of end users are wholly doing one of these three use cases: 1. All shared Boost libraries. 2. All static Boost libraries. 3. Precompiled headers/Header only Boost libraries. So keep it simple for now, support those three, see what happens after an extended beta programme. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/