Re: [boost] cmake target and binary name mangling

Subject: Re: [boost] cmake target and binary name mangling
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-07-27 02:13:57

On 7/26/2017 6:29 PM, Niall Douglas via Boost wrote:
>>> 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.

I assume you are talking about header only libraries with static/shared 
dependencies in CMake terms. Clearly in pure C++ terms a header only 
library which has static/shared library dependencies is still a header 
only library, which means that it itself does not have to be built even 
if its static/shared library dependency has to be built for the header 
only library to work properly.

Since I do not know how CMake works and you do, I will defer to your 
assertion that a header only library with static/shared dependency 
should be treated as a STATIC or SHARED library and that CMake will work 
properly and know that the header only library itself has no build but 
that the STATIC or SHARED library dependency has to be built in order 
for the header only library to be "built" properly. That still sounds 
really odd to me but if it pragmatically works in CMake, that is what is 
important.

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