The ::hl suffix means "link against the header only library edition", the ::sl suffix means "link against the static library edition" and the ::dl suffix means "link against the dynamic library edition".
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.)
(Exceptions where the dependency is always ::dl or always ::sl notwithstanding. The question is about the case where it also supports both, or all three.)
That's the default convention I've always followed in my own code. But I agree it feels a little wrong, I can see where a dynamic library might want to use the static library edition of a dependency sometimes if they are setting -fvisibility=hidden. Because cmake targets propagate their dependencies to consumers, if the library developer says that the ::dl edition uses ::dl dependencies, and the end user wants it to use the ::sl dependency, unless the library developer adds a special target for them then you must resort to monkey patching the properties to change the hard coded dependency the library developer chose for you. As much as this might seem important, it isn't as much as it might seem in practice. Static libraries generally are not compiled to be linked into DLLs, so they don't mark their symbols as public etc, indeed in cmake they aren't even compiled with -fPIC by default. So the actual occasions where you do need to link static library editions into shared libraries happens less often in practice than you might think. Still, it leaves me feeling a little uncomfortable. Doing better in cmake introduces lots of extra custom logic though, you really need custom functions and macros to ease the pain :( Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/