Re: [boost] cmake target and binary name mangling

Subject: Re: [boost] cmake target and binary name mangling
From: Florent Castelli (florent.castelli_at_[hidden])
Date: 2017-07-24 13:04:02

On 24/07/2017 14:27, Niall Douglas via Boost wrote:
>>>> 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.

Well, that's true for people who don't rely on the CMake-generated 
solution files, those will include all the vcxproj files that exist. 
Then, you could argue that they can use the new fast solution loading, 
but I don't think it is quite production ready right now (and also, only 
available in VS2017).
For the build times, you could say that people should not build the full 
solution too and build the right target they actually intend to build, 
and I would totally agree with that statement.
Unfortunately, most people don't work like this and this would be 
shifting too much of a burden on users.

>
> 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.

This is kind of tree in a superbuild configuration, but even in this 
situation, I wouldn't mix my sanitizer enabled binaries with others.
It is semantically wrong to mix and match those and you will end up with 
false positives just like I did at my company when we mixed ASan tests 
with non-ASan Boost.Test. False positives shown up in the code that 
built the string holding the name of the test, even though most of 
people think this is safe to do.

Because of those issues, why would just make ASan, TSan, MSan (and 
others) targets available to link with the rest of the regular targets? 
Either everything is instrumented (with the same options) or nothing is.

To have sanitizer enabled binaries, the traditional solution is just to 
rebuild it just like another platform, using either a dedicated 
toolchain file or some light CMake options for the toolchain or 
eventually main project, which would limit the number of toolchain files 
to manage.

Don't get me wrong, I'm not against having necessarily multiple flavors 
of libraries like hl/sl/dl even though I think this is superfluous 
(there should be an option to get whole Boost preferred dynamic, static 
or header only with only one target name), I'm against the extensive 
list of targets with all flavors. Those are probably better handled with 
various CMake configurations, you could have Debug, Release and ASan. 
Unfortunately, it just clashes with how people use them in general and 
would make it impractical for lots of users.

> 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.

Sure, CMake is faster, but do you think the actual build tools will keep 
up with this change? They are the ones actually checking for all the 
source files and other intermediate files. A combinatory proliferation 
of targets, is not a good thing for them.

>
> Niall
>
Florent