Boost logo

Boost :

Subject: [boost] Boost CMake support - Request for Comment
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-10-01 17:07:14


My personal knowledge of build systems is somewhat limited.

a) I don't really understand CMake all that well. I have made
CMakeLists.txt files for both the serialization library and the safe
numerics libraries as an aid to build and maintain IDE and make files
used in running tests and posting results to CDash.

b) I don't really understand our current system, Boost Build, very well
either. I've made jam files for building and running tests for the
serialization and safe numerics libraries.

c) I recently reviewed C++Now 2017: Daniel Pfeifer's excellent video
from C++Now 2017 “Effective CMake" - . I recommend it highly.

Despite my lack of knowledge in this area, or perhaps because of it,
I've volunteered to direct the effort to evolve Boost so that users of
Boost can avail themselves of the benefits of CMake. This effort will
be organized as follows:

a) A discussion on the boost developers mailing list with the goal of
reaching a consensus as to what benefits CMake can and should provide to
users and developers of Boost. This effort will commence with the
posting of this notice. I hope that this discussion can be more or less
resolved within 30 days.

b) I will then synthesize from the above discussion a call for proposals
which lists the requirements and requirements.

c) Those proposing CMake for boost will have approximately 90 days to
prepare their proposals. Their proposal are expected to look similar to
a boost library proposal. That is they are expected to have some
(CMake) code, along with tests, documentation including tutorials and
reference. This is only an expectation. It's conceivable that such a
proposal might only contain conventions and and samples of what boost
library should contain to fulfill the requirements. As with boost
libraries, submissions are not required to totally complete. But they
have to be sufficiently complete to convince reviewers the the
submission fulfills the stated requirements and can be finished in good

d) After the 90 day period, submissions will be reviewed simultaneously.
  Note that this is at a variance from normal boost procedure of
reviewing submissions one at a time. Since we expect to receive a
number of submissions and only one can be accepted, the normal boost
protocol can't really function. Target date for this review is 1
February 2019.

e) After the review period the review manager will prepare a report
which includes the decision of which submission will be accepted into
the official boost distribution. Currently, I, Robert Ramey, expect to
be review manager. However, it's possible that this by the time the
review is undertaken, this coveted position could be assigned to some
more worthy candidate.

Scope, Requirements and Features

We presume that submissions will fulfill the applicable requirements of
any boost submission. In addition we would like to see the following

Library Build
           â€œEffective CMake" -
Recommends that all libraries - including header only libraries have a
CMakeList.txt file. What should this include for Boost Libraries?

Library Test
        Should facilities for "testing" be only done by developers? or should
users who acquire library packages also be able to test libraries.
        Should CMake testing results posting be used - CDASH?
        Should we just skip the issue of Library Testing and continue to depend
on Boost Build.

Library Packaging
        Is the library packaging facility provide by CMake - CPACK - useful to
boost. Should boost libraries be updated to support it?

        If the above is implemented, can we depend upon CMake to handle library
dependencies? Or does some special functionality
        Do circular dependencies constitute a problem?

        Currently boost is organized as a tightly integrated group of
libraries. This organization manifests itself in a number of ways.
                We have a Boost "super project" in github. Boost libraries are "sub
projects" of this super project. This known structure is exploited by
and depended upon by boost tools. Should CMake support continue this
                We distribute boost as "super project". Should we continue to do this
or distribute libraries on a library by library basis. Does CMake/CPACK
etc. make this "simple"?

        What support should be require for uses of Boost CMake implementation.
Documentation, examples, templates for helping library developers. How
should the CMake design/implementation be tested?

Other considerations
add your requirement/features here.

Useful Resources
        â€œEffective CMake" -

Please try to keep this discussion on this list.

I know that there has been a lot going on on slack. But having it in two
places makes it harder for me to review and summarize. Also slack
doesn't conveniently maintain comment hierarchy. So please try to keep
this discussion on this list.

Robert Ramey

Boost list run by bdawes at, gregod at, cpdaniel at, john at