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-26 20:51:47

On 7/26/2017 4:22 PM, Niall Douglas via Boost wrote:
> On 25/07/2017 23:16, Peter Dimov via Boost wrote:
>> Niall Douglas wrote:
>>>> The implication is that when a library changes from header-only to >
>>> static/shared, all dependent libraries need to change themselves to >
>>> static/shared too.
>>>
>>> I'm not sure if this is a question or a statement. But in either case,
>>> yes it does.
>>
>> My point was that under my overcomplicated scheme, this doesn't happen.
>> Your dependency may change from header-only to static/shared, or from
>> static/shared to header-only, and you don't need to do anything.
>>
>> And when I say "change" here, I mean that version 1 was header-only,
>> version 2 becomes static/shared, version 3 becomes header-only again,
>> and dependents don't need to make corresponding changes each time this
>> occurs.
> 
> 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.

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.

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 big reason I keep advocating in favour of specific cmake targets for
> header-only libraries is because it solves auto-linking for all
> platforms without using linker magic. I think that a nice win for end
> users. It also could be extended easily to transparently use C++ Modules
> in the future, another nice win for end users.
> 
> Can you suggest where, in the case of Boost, it would be important to
> support dependent libraries changing their header only usability?
> 
> Niall
>