Re: [boost] [cmake] Minimum viable cmakeification for Boost

Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-21 12:13:41

>> 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/