Boost logo

Boost :

Subject: [boost] [cmake] Pull request announcement
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-09-17 10:19:23

Hello everyone,

I feel the need to clarify a few things, as this thread grew well
beyond what I originally intended. Essentially I wrote the initial
mail to inform you of pull request intentions [1], to prevent any
impression that I wanted to sneak cmake into boost behind the back
of the community.

So, first to the WHY:
The desire to have native support for cmake in boost does NOT stem
from any (real or perceived) shortcoming of b2. It is about adding
support for the de-facto standard build tool for cross-platform c++
library projects[2] instead of requiring users and contributors to
deal with a proprietary one that is rarely used outside of boost.
I'm explicitly mentioning this, because there were some voices asking for
a comparison of b2 and cmake. While it would certainly be useful to
have such a comparison documented in the wiki, I don't think it is
particularly relevant to the discussion at hand.

As to the WHAT: I applaud any effort to make Cmake a first level
citizen in addition of or as a replacement for b2. If I have a vote,
Robert absolutely gets my vote for his proposed process and
for him as a review manager.

HOWEVER, that is NOT the goal of the PRs I announced in this thread.
And I WON'T submit any proposal to that end, because I think what
I'm offering there is far too narrow in scope to be considered an
"alternative" to BCM or the like.
All I'm trying to achieve is to get a minimal support for cmake into
as many boost libraries as possible, in a simple enough manner that
any library maintainer feels comfortable in having the file as an
official part of his library (although I'd be happy to provide support
for them myself). The primary goal is to make project local compilation
and consummation of boost easier, as well as lowering the bar for
contributors. If one is just interested in consuming system installed
boost libraries, the cmake developers have already

HOW is this then related to BCM or other proposed full-fledged cmake
solutions for boost?


At least no more than the CMakeList.txt files that already exist
in some of the libraries (e.g. hof, serialization, beast, hana, yap,
gil, signals2, compute are some examples I'm aware of).
The only thing I want to make sure is that any common, publicly visible
practices my PRs introduce (E.g. naming convention) don't conflict with
a future full-fledged solution.
This is (I believe) achieved in two ways:

 a) There are very few such practices in the first place
   (naming convention is the only real one that is difficult to
    change after the fact)
 b) I'm sticking to well established practices in the Cmake world
    and hope that any other future solution isn't going against them
    (e.g. the name Boost::filesystem is the alias by which cmake
    user can express their dependency on boost.filesystem right now.
    Also, placing the root CMakeLists.txt file into the project root
    folder is default practice for cmake and used by almost any
    project I am aware of.



PS.: As a final note: Considering the shit storm Boost Steering Committee
received after their initial announcement, I'm not surprised that they
don't want to push the issue further.

[1] Here are a few examples of my PRs (so far I've only submitted a
handful anyway):

[2] Just as a related data point: Jetbrains makes a regular market
survey "The State of Developer Ecosystem Survey" You can find the
latest numbers related to c++ here (based on ~1000 c++ developers):

CMake is used by 36% of the participants, next comes visual studio
with 32%. In comparison, boost.Build ranges around 3%.

Also, lookup a handful of your favorite non-boost OSS c++ libraries
on GitHub. I bet most (probably even all) will support cmake at least
as one alternative. For my team, boost is actually the only
cross-platform dependency in any of our projects that doesn't
support Cmake.

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