Subject: Re: [boost] cmake target and binary name mangling
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-07-27 01:06:49
> The point in "modern cmake 3" if you will, is that I write:
> 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.
Where are you getting the notion that end users want to not care whether
their dependencies are in header only, or static, or shared form?
They're the ones suffering the build times. Of course they take strong
opinions on it, they'll choose exactly one and contract into it
permanently. They do not want you the library dev messing with that.
That's why your proposed cmake 2-ish "directory per build config" system
makes zero sense to me. Nobody in end user space wants to be mucking
around on the command line with twenty lines of -Dvariable=setting and
dealing with binaries being named weird things the library dev chose, in
weird paths the library dev chose. They want to bring in the cmake for
the library they're adding, and specifying *exactly* what presentation
of that added dependency they are *contracting* into at the point of
import, not separately on a command line with some voodoo magic list -D
*That's* cmake 3. It's reusable, it's a generic driver for external
third party unknown cmake. Your proposal is exactly opposite that: you
the library dev enforces what you think the end user wants by serving
them a rigid menu of what you think is right for them. Regressive.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/