Re: [boost] cmake target and binary name mangling

Subject: Re: [boost] cmake target and binary name mangling
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-07-26 22:29:38

>> This seems highly unlikely to be desirable in practice. A header only
>> library guaranteeing header only usage suddenly requiring something to
>> be linked is a *major* change. You'd *want* libraries dependent on it to
>> stop compiling!
> 
> I disagree here. There is nothing unusual in theory for creating a
> header only library which needs to link to a non-header only library,
> whether that non-header only library is a static library or a shared
> library. The choice of a header only or non-header only library should
> not be predicated on whether or not any other library on which it
> depends is header only or non-header only.

I think this the crux of the misunderstanding.

cmake doesn't implement header only library support as you and Peter
appear to understand it. It implements INTERFACE targets. These are,
quite literally, targets wholly composed of nothing. They cannot contain
sources. They can inject paths to search for headers, compile and link
flags into things which consume them. That's it.

So when I've been speaking of implementing header only library support
into cmake, I really mean targets consisting solely of how to find
interface files, and how the final binary ought to be compiled and
linked to keep the header only library happy. No
non-wholly-interface-file dependencies permitted, though you can inject
linking to arbitrary system or other libraries. The target dependency
graph is *pure*.

> Furthermore, and most obviously, a non-header only library may have a
> great portion of its code as header only and just a small portion of its
> code as being built into a static or shared library. So another header
> only library might depend on a non-header only library, but could depend
> on only the code in the non-header only library which is header-only, or
> conversely could depend on the code which is part of a static or shared
> build of the non-header only library. And those dependencies could
> change as the design of a header only library evolves.

All of which is fine if you adhere to the rule that header-only
libraries with static or shared components or dependencies do not claim
to be header-only. They claim themselves to be static or shared, as
appropriate.

There are quite a few libraries in Boost which are pure header only and
with no dependencies on anything but other header only code. It is to
these I refer only.

> Given all these very real possibilities, none of which should be
> important in forcing an actual design of a header only library, I find
> it absurd to "stop compiling" simply because the design of a build
> system is too simplistic to deal with the variations.

The whole point of a decent build system is to refuse to build when
requirements and/or guarantees have been broken.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/