[boost] Proposal for moving Boost to CMake

Subject: [boost] Proposal for moving Boost to CMake
From: David Sankel (camior_at_[hidden])
Date: 2017-06-16 23:44:17

Howdy all,

This is a request for comments on a possible path for migrating Boost's
build
system to CMake. I am not speaking for the Boost Program Committee here,
but I
plan on bringing this up with them after getting feedback.

The motivation is simple. CMake is currently the dominant player in the
area of
open-source, cross-platform, C++ build-systems. I make this claim based on
Google trends graphs and discussions with others at the conferences I attend
(CppCon, C++Now, and ISO C++ meetings). If we make Boost buildable and
usable
out-of-the-box with CMake, we would significantly lower the barriers to
entry
for both Boost users and new Boost developers. Boost serves the greater C++
community and making Boost more accessible would be of great utility.

* To ease the migration path, both Boost.Build (the current jam-based build
  system) and CMake will be supported for a time.
* Boost sources would provide a compatible, drop-in replacement for the
  'FindBoost' module that is distributed with CMake. A CMake-based
application
  could point to it and, instead of using the system Boost libraries, Boost
  targets would be built from source as part of the user build.
* The built Boost **binaries** would also provide a compatible, drop-in
  replacement for the 'FindBoost' module distributed with CMake. The
behavior
  is similar to the previous bullet, except the built binaries would be used
  instead of the source code.
* The style of the 'CMakeLists.txt' files would follow current best
practice.
  We'd resist the temptation to write macros which replace the core CMake
  functions. There would be repetition in the files, to be sure, but I
think we
  should avoid attempting to innovate CMake. I've seen this fail on many
  occasions and would like to keep our goal focused, at this point, on
  migrating Boost to CMake. In the future we could revisit this.
* There would be a list of CMake guidelines that we'd use.
* Boost libraries should be buildable in isolation and use
  'find_package(Boost...)' to discover their Boost dependencies.
* We would work with CMake towards eventually taking over maintenance of the
  FindBoost module distributed with CMake.

I see this progressing with several milestones.

1. Release of a CMake-buildable Boost and the CMake conventions. In this
stage
   each Boost library can be built in isolation or with the entire
distribution
   and all the 'FindBoost' functionality mentioned above would be
incorporated.
2. The unit tests for all Boost libraries are incorporated into CTest (the
   CMake unit test orchestration tools).
3. The Boost infrastructure is modified to use CTest for unit testing.
4. Unit testing functionality is removed from Boost.Build.
5. Boost.Build is removed.

Although there are many other great ideas floating around (e.g.
modularization
of Boost, Boost-Classic, and Boost2), I'd like to keep this focused on
CMakification of Boost because I think it is something that would have big
impact and is small enough to be doable.

One question that is going to come up is "who is going to do all this
work?".
Once we decide on a direction, I don't foresee a problem making this happen.
Between volunteers, the importance this project has for companies, and the
Steering Committee reserves, we should have the resources necessary.

Another concern is that some authors may resist. Authors have a lot of
leeway
when it comes to how they maintain their libraries, what conventions they
use,
and backwards compatibility concerns. However, there are some things that
authors need to conform to, such as our current Boost.Build build and
testing
infrastructure. I liken this to the development of a city: building
developers
can make their buildings however they want, but the streets, which control
transit between buildings, are centrally regulated.

Thanks for your consideration.

-- David Sankel