Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2017-06-22 10:24:48

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_[hidden]> 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/df7b6888752097e25bfc2333f
>> 6d897ca#file-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>,${_IMP
>> ORT_PREFIX}/lib/boost_system-vc141-mt-gd-1_65.lib,boost_
>> system-vc141-mt-1_65.lib>"
>>   IMPORTED_LOCATION "$<IF:$<CONFIG:release>,${_IMP
>> ORT_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. `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.

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