Re: [boost] cmake target and binary name mangling

Subject: Re: [boost] cmake target and binary name mangling
From: paul (pfultz2_at_[hidden])
Date: 2017-07-26 23:20:11

On Wed, 2017-07-26 at 23:29 +0100, 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*.

The point in "modern cmake 3" if you will, is that I write:

find_package(boost_foo)
target_link_libraries(myLib boost::foo)

And this will work whether boost_foo is header-only or compiled static or
shared. Not only that, but if boost_foo or one of its dependents change from
being header-only to being compiled(or vice versa), build scripts to boost_foo
or any downstream libraries do not need to change. 

This is the usefulness of exporting usage requirements with build systems, and
why it is important in cmake 3. What you are proposing does not provide this
usefulness and is a major step backwards.