Re: [boost] Cmake

On Jun 24, 2017, at 3:59 AM, Peter Dimov via Boost wrote:

There is considerable interest in Boost supporting CMake, but it seems that everyone has different ideas as to what this support will entail. After deliberation and discussions, I have identified the following (separate) scenarios:

1. The user installs a Boost release as usual with `b2 install`, which makes the installation visible to CMake and usable via find_package(boost_libname).

2. The user brings several Boost libraries as git submodules into his CMake-based project and uses add_subdirectory in his CMakeLists.txt to link to them.

3. The user uses CMake to install an individual Boost library, which is then available for find_package.

4. The user uses CTest to run the tests of an individual Boost library.

5. CMake is supported as a way to build and install the entire Boost, in place of b2.

6. CTest is supported as a way to run the tests for the entire Boost, in place of b2.

At the moment, I think that we should concentrate on (1) and (2) as providing most bang for the buck. 5-6 in particular require that all Jamfiles are ported at once, which is a serious undertaking for a questionable benefit as what we have already works.

I've done a proof of concept for (2), which can be seen here:

https://github.com/pdimov/boost-cmake-demo-2

This repository uses git submodules in ext/ to bring in Boost.System (our guinea pig) and its dependencies, then uses them via add_subdirectory in

https://github.com/pdimov/boost-cmake-demo-2/blob/master/CMakeLists.txt

The required CMake infrastructure is on branch feature/cmake in those six libraries (assert, config, core, predef, system, winapi.) It consists of CMakeLists.txt in the root:

https://github.com/boostorg/system/blob/c306d479e8326a68d07ee7f058a415fe8b67...

and supporting .cmake files in cmake/ :

https://github.com/boostorg/system/tree/c306d479e8326a68d07ee7f058a415fe8b67...

The goal here is for Boost library developers to be able to remain ignorant of CMake if they so choose; so of those files, only sources.cmake requires their input (it's empty for header-only, so those require nothing at all.)

I think it would be better for us to use cmake modules for this instead of copying a bunch of cmake files everywhere. I setup a demo using cmake modules here: https://github.com/pfultz2/boost-cmake-demo/tree/bcm-demo The library for Boost.System is just: bcm_boost_package(system VERSION 1.64 SOURCES src/error_code.cpp DEPENDS assert config core predef ) And this works for both `add_subdirectory` build and standalone builds. This will build the library and install -config.cmake files and is simple enough for those who want to remain ignorant of cmake. I think this is also better for maintenance as well, because if we need to make changes in the future, we need to coordinate across several repos. Also, for authors who would prefer more vanilla cmake, they can write the vanilla cmake. It would be interesting to setup an automated testing infrastructure for cmake to test whether the libraries support these scenarios correctly.