Re: [Boost-users] CMake Announcement from Boost Steering Committee

Subject: Re: [Boost-users] CMake Announcement from Boost Steering Committee
From: Roger Leigh (rleigh_at_[hidden])
Date: 2017-07-18 18:01:25

On 18/07/17 14:12, Jon Kalb via Boost-users wrote:
> Therefore, we, the Steering Committee, announce to the Boost community 
> our desire and intent to move Boost’s build system to CMake for users 
> and developers alike.

This is great news to hear.

> The members of the Steering Committee have been encouraged by the 
> discussions and activity surrounding CMake on the mailing lists over the 
> years and know that many people have voiced visions. We hope that each 
> of you rejoins the discussion to support this initiative and contributes 
> to the common goal of improving Boost’s integration into the broader C++ 
> ecosystem.

I'm one of the maintainers of the CMake Boost support 
(https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindBoost.cmake)

Currently we hardcode all the inter-module library and header dependency 
information back to Boost 1.33 so that it's possible to call

     find_package(Boost COMPONENT filesystem thread)

and have it find the libraries and tell CMake what the dependencies are 
so it can compile and link with the correct includes and libraries.

With Boost using CMake itself, it would be nice if this information 
could be provided directly by Boost, so that the dependency information 
doesn't need to be hardcoded--it can be supplied directly with the build 
in the form of a ${libdir}/cmake/BoostConfig.cmake script.  This would 
mean we could retire FindBoost.cmake and cease the hardcoding of 
dependency information for new releases from this point onward.  We 
would need to keep it around for backward compatibility for some time, 
but users could switch over to the provided configuration pretty seamlessly.

Over the years, FindBoost has accumulated a number of tweakable settings 
and variables and which report various information about Boost features 
(e.g. enabling autolinking).  While some of these might no longer be 
needed, it would be nice if you could consider preserving the existing 
option and target names used in the above linked FindBoost.cmake script 
for backward compatibility so that users can switch to the new config 
script with ease.

I'd be happy to work with you on making any needed changes to 
FindBoost.cmake for forward compatibility with exported Boost cmake 
configuration.  Likewise I'd be happy to provide any assistance with 
CMake support in Boost itself, e.g. to get the configuration export 
working (if it's not been done already).

Kind regards,
Roger