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
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk