Re: [boost] Proposal for moving Boost to CMake

On Jun 17, 2017, at 5:23 AM, Niall Douglas via Boost wrote:

...

...

It is a very important property to have in a build system for large-scale development.

It is very important for boost to be able to support `add_subdirectory` builds. However, hijacking `find_package` to call `add_subdirectory` is the wrong approach and goes against cmake’s workflow. The approach I outlined is what is presented in Daniel Pfeifer’s Effective Cmake talk(although I was aware of this before Daniel’s talk).

I'm mostly in agreement with Paul here.

You may however also be in agreement too David. Here are some cmake use cases:

1. I want a library from a Boost release, so find_package(boost 1.60 MODULE COMPONENTS asio REQUIRED), link to boost::asio

We will need to update cmake so that it finds boost config packages. Or the user can say `find_package(boost_asio)`.

2. I am making a new Boost library or I am using Boost trunk source tree. So add_subdirectory(boost/libs/asio EXCLUDE_FROM_ALL), link to boost::asio

No, the `add_subdirectory` is for a superproject. A library will just call `find_package`(which the superproject will override) to get the targets.

3. There is a third use case pre-C++11 Boost libraries can't do which is to mix some release Boost libraries from find_package with some brought in by add_subdirectory() from a source tree. You may wish to rule out supporting that, but equally, a correct cmake implementation should implement that just fine.

There is no reason why that can’t be supported. You only setup `find_package` to ignore the packages that are part of the build and then call `find_package` as you normally would for libraries that aren’t being built.

I do agree David that cmake innovation is to be avoided right now. I have a superb cmake innovation at the library formerly known as boost-lite and now called quickcpplib because it lets you write state of the art C++ libraries super-quick by eliminating needing to think about build or test or tooling or documentation or CI scripting, just supply the config file and go, the cmake inspects its environment and automates everything thereafter. It's really amazing. But it also is very experimental, and insufficiently tested. And it has several serious bugs I haven't got to fixing yet.

So don't innovate cmake. Just use 100% standard cmake 3.5, and make sure it is a *good neighbour* to other cmake and is not *anti-social* like most cmake currently written today. Design the cmake to be usable as build and discovery drivers by other cmake. This is the key improvement in cmake 3 - being nice to **any** other cmake.

I'd recommend a minimum of cmake 3.5.

I agree we should use cmake 3.5 as a baseline, as that is what comes with ubuntu 16.04.

You can create header only library targets and >= 3.5 those work right without bugs. You can create static and dynamic library targets for those libraries which implement those.

We need to generate the cmake config package. And that includes the dependencies. Libraries like Hana can “cheat” and export the targets directly to the cmake config package because it has no dependencies. However, for a library like Boost.Fusion the dependencies will need to be listed a third time in the cmake config.

I would personally suggest a Python script which parses Jamfile.v2 and spits out a CMakeLists.txt. You'd get 80% of Boost.Build easily enough using just this.

We can generate the code with python, which will help with libraries that have lots of dependencies. Although some libraries like Boost.Config is not so simple.

You just then need to feed everything to the cmake package tooling, again all 100% cmake 3. And you should be done, no cmake innovation needed

The BCM modules aren’t trying to work or redefine the cmake workflow, rather it is tool to help reduce the boilerplate needed to provide cmake support in libraries like boost. Otherwise we will have authors create their own set of functions to make the build scripts more maintainable, and then we will lose consistency among boost libraries.

As Edward pointed out, not everything Boost.Build can do will work in cmake without cmake innovation. But worry about that after, for end users of Boost they almost certainly have no need nor want for any of the stuff beyond already described. Indeed one argument could be "don't move Boost to cmake, *package* Boost releases with auto-generated cmake build support". That would make for happy end users.

It would be nice to not just support cmake, but pkgconfig as well. There are many times I need to use boost in non-cmake projects, so having pkgconfig would be helpful as well.