Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: P F (pfultz2_at_[hidden])
Date: 2017-06-22 09:58:13

> 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] <mailto:boost_at_[hidden]>> wrote:
> 
> > On Jun 21, 2017, at 8:48 PM, Peter Dimov via Boost <boost_at_[hidden] <mailto: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/df7b6888752097e25bfc2333f6d897ca#file-minimal-handwritten-config-static-cmake <https://gist.github.com/ldionne/df7b6888752097e25bfc2333f6d897ca#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>,${_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. 

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.