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