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-24 12:27:06

>>> The target graphs are REGEXable via the pattern
>>> "<lib>_<hl|sl|dl>-<special>-<binary>" where:
>>>
>>> * hl = header only library
>>> * sl = static library
>>> * dl = shared library
>> There is no need for `hl` as it doesn’t produce binaries.
> 
> "hl" is necessary as a CMake logical target, not at as a build output.

Indeed. Paul seems to have a mental block regarding header only cmake
targeting.

> The problem I have with all those targets, is that they add a lot of
> overload to IDE solutions who will scan sources for every configuration
> and for people whose workflow is to build "all" or the whole solution
> for MSVC, which will build way too many versions.

You are correct - if the end user loads the base .vcxproj file.

But be aware that consuming cmake projects will link against only the
dependent targets that they use, and if you load those .vcxprojs they
consist exactly of the minimum subset of targets used.

So consider the base library level .vcxproj as a "database". For
example, if I open a .vcxproj for an individual unit test, I will get
only the minimum target set for that unit test to compile.

You'd do the same thing for a release building project. It would bring
in only the targets for doing a release distro. Users ought to open that
one instead, and we can hide the base "database" .vcxproj file inside a
subdirectory.

You might now say why bother with a master "database" .vcxproj file
then? A single file eases much of the remaining build scripting without
needed to use custom cmake function logic, which I strongly recommend
against, but am absolutely sure we will see proliferate with all the
usual bad consequences in the Boost conversion (c.f. Paul's library of
custom cmake function logic he's pushing). But it is true that as the
database gets bigger, cmake takes longer to generate it, and eventually
a tradeoff needs to be made.

That said, cmake 3.9 got a lot faster at generating huge lists of target
permutations into a single solution, and I expect that trend will
continue as big cmake users like Google push harder on that.

Niall

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