Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-17 10:23:53

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

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

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.

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

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.

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/