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? IT ISN'T! 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. Best Mike 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): https://github.com/boostorg/boost/pull/193 https://github.com/boostorg/predef/pull/86 https://github.com/boostorg/assert/pull/10 [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): https://www.jetbrains.com/research/devecosystem-2018/cpp/ 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.