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 20:22:59

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!

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

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