Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: paul (pfultz2_at_[hidden])
Date: 2017-06-22 16:47:50

On Thu, 2017-06-22 at 12:24 +0200, Thomas Heller wrote:
> 
> 
> On Thu, Jun 22, 2017 at 11:58 AM, P F <pfultz2_at_[hidden]> wrote:
> > 
> > > On Jun 22, 2017, at 4:36 AM, Thomas Heller <thom.heller_at_[hidden]>
> > > wrote:
> > > 
> > > 
> > > 
> > > On Thu, Jun 22, 2017 at 11:30 AM, P F via Boost <boost_at_[hidden]> 
> > > wrote:
> > > > 
> > > > > On Jun 21, 2017, at 8:48 PM, Peter Dimov via Boost <boost_at_lists.boos
> > > > t.org> wrote:
> > > > >
> > > > > Louis Dionne wrote:
> > > > >
> > > > >> And here's a minimal XYZConfig.cmake file for a library with
> > > > compiled sources (I added source files to Hana and turned it into a
> > > > static library to check this):
> > > > >>
> > > > >>Â https://gist.github.com/ldionne/df7b6888752097e25bfc2333f6d897ca#fi
> > > > le-minimal-handwritten-config-static-cmake
> > > > >
> > > > > To get back to this... it ain't so easy. On Linux, where the default
> > > > is --layout=system, you indeed can only have libhana.a and libhana.so
> > > > (a link to libhana.so.1.65.0 or something like that).
> > > > >
> > > > > But on Windows, `b2 --build-type=complete --with-system
> > > > toolset=msvc-14.1` gives you this:
> > > > >
> > > > > boost_system-vc141-mt-1_65.dll
> > > > > boost_system-vc141-mt-1_65.lib
> > > > > boost_system-vc141-mt-gd-1_65.dll
> > > > > boost_system-vc141-mt-gd-1_65.lib
> > > > > libboost_system-vc141-mt-1_65.lib
> > > > > libboost_system-vc141-mt-gd-1_65.lib
> > > > > libboost_system-vc141-mt-s-1_65.lib
> > > > > libboost_system-vc141-mt-sgd-1_65.lib
> > > > > libboost_system-vc141-s-1_65.lib
> > > > > libboost_system-vc141-sgd-1_65.lib
> > > > >
> > > > > and of course compiling with a different toolset would give you the
> > > > appropriate, different, names. You can have all of these installed
> > > > simultaneously.
> > > > >
> > > > > So boost_system-config.cmake needs to be slightly more elaborate.
> > > > 
> > > > Yes. For debug and release variants, I believe you can use the
> > > > `$<CONFIG>` generator expression:
> > > > 
> > > > set_target_properties(boost::system PROPERTIES
> > > > Â Â IMPORTED_IMPLIB
> > > > "$<IF:$<CONFIG:release>,${_IMPORT_PREFIX}/lib/boost_system-vc141-mt-
> > > > gd-1_65.lib,boost_system-vc141-mt-1_65.lib>"
> > > > Â Â IMPORTED_LOCATION
> > > > "$<IF:$<CONFIG:release>,${_IMPORT_PREFIX}/lib/boost_system-vc141-mt-
> > > > gd-1_65.dll,boost_system-vc141-mt-1_65.dll>"
> > > > )
> > > There are use cases when I want to get the release build of boost even
> > > though my own build type is set to Debug. The build type in addition is
> > > also completely customizable (see for example the MSVC CMake
> > > integration). What should happen when my build type is RelWithDebInfo or
> > > MinSizeRel? There should always be a way for users to bail out of the
> > > guessing game.
> > This isn’t based on the `CMAKE_BUILD_TYPE`(which is a configuration
> > variable). Its based on the configuration set at build time:
> > 
> > cmake --build . --config debug
> > 
> > Which `debug` and `release`, I believe, are the only valid options. 
> > 
> They are not. As said, they can be arbitrary. 

Thats true. We have to use the `DEBUG_CONFIGURATIONS` propery to know which
configurations are for debug.

> `cmake --build . --config debug` is just another way of kicking of the build
> for a given build type. That is, setting `CMAKE_BUILD_TYPE` (and calling
> make directly after) and the aforementioned command are equivalent.

This is not true at all. It never changes the `CMAKE_BUILD_TYPE`. The
`CMAKE_BUILD_TYPE` is for single configuration buildsystems(like make), but is
ignored for multi-configuration build systems(like MSVC and XCode). At the
same time, `--config` is ignored on single configuration buildsystems. 

> Â 
> > 
> > Of course, the choice between the debug/release is only when user has
> > chosen to build both variants in the same build tree/installation. If you
> > want to use release versions of boost during a debug build, then its best
> > to build only the release version of boost, so the config.cmake would just
> > be this:
> > 
> > set_target_properties(boost::system PROPERTIES
> > Â  IMPORTED_IMPLIB "${_IMPORT_PREFIX}/lib/boost_system-vc141-mt-1_65.lib>"
> > Â  IMPORTED_LOCATION "${_IMPORT_PREFIX}/lib/boost_system-vc141-mt-
> > 1_65.dll>"
> > )
> > 
> > Then its just a matter of adjusting your `CMAKE_PREFIX_PATH` to point to
> > different variants.
> > 
> The problem here is that, at the time of a b2 invocation, you don't know if
> the user doesn't build more variants. Meaning, even though, the libraries
> are perfectly fine with living next to each other, the CMake Configs would
> not. This would IMHO create a disparity between the features of Boost.Build
> and what's being offered by the CMake integration.

Yes, and if boost was to move to cmake, the result might be different as well.
It might be better to only generate the configs when building for a single
variant, although that would make `b2 variant=debug,release` different from
`b2 variant=debug && b2 variant=release`.