Subject: [boost] Strawman proposals for CMake support
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2017-07-19 01:09:08
I'd like to expose two strawman proposals for adding CMake support
to Boost. Both proposals would solve the following problems, with
different advantages and disadvantages:
(1) Users have a hard time integrating Boost into their build system,
which is CMake more often than not.
(2) Prospective Boost developers are sometimes driven away from
submitting because they would have to learn Boost.Build, which
is not widely used and has a limited knowledge base.
The first proposal is to move completely to CMake and to render
Boost.Build support optional. The possible rollout plan would
look something like:
1. We start requiring that new libraries support both Boost.Build
2. We start adding CMake support to existing libraries.
This will take time.
2.1 We start moving our infrastructure to be CMake-based.
3. We release Boost with dual support for a while, letting time
for things to bake.
4. We remove the requirement that Boot libraries can be built
with B2. Libraries (existing and new ones) are free to provide
such support, but they are not required to.
This would bring CMake to the status of "primary" build system
for Boost. This could be based on Paul Fultz's work in progress
at . This has the following advantages (in the long term):
- Less technical debt because we only have one "official" build
system to maintain.
- The build system is uniform across all of Boost, which means
it's easier for folks to maintain it and understand it.
- It gives maximal flexibility to CMake-based users.
However, it has the following drawbacks:
- We'll need to do a wholesale migration to build system XYZ when
CMake is not cool anymore.
- It's harder to get buy-in from some developers that love
The second proposal is to make Boost into an almost build-system
agnostic collection of libraries. Basically,
1. Provide CMake package config files for all Boost libraries so that
they can be used from CMake (either automatically, manually, or a
mixture of both). This could be based on Peter Dimov's work at 
(or , not sure which one is most current).
2. Make it possible to build CMake-based projects from Boost.Build, or
the other way around, or provide a build system agnostic script to
build all of Boost. This way, Boost libraries can decide whether
they want to support B2 or CMake.
This has the following advantages:
- Possibly easier to implement
- We could possibly support other build systems too (e.g. if a
Boost author really wants to use scons for his/her library)
- We don't have to do a wholesale move to XYZ when CMake is not
I see the following disadvantages:
- Boost's infrastructure could grow more complex as a result
- Our build system would be less uniform
- We would have to depend on all theÂ build systems that we want
Boost libraries to be usable with
My personal preference is towards the first option, since I
think it would be simpler in the long term. I could certainly
be convinced otherwise.
There are probably other ways we can solve problems (1) and (2)
exposed above. There are also certainly advantages and
disadvantages that I forgot to mention above. I'd love to get
some feedback on those two approaches and see whether one of
them (or something else completely) can get some consensus on
-- View this message in context: http://boost.2283326.n4.nabble.com/Strawman-proposals-for-CMake-support-tp4696989.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk