[boost] [cmake] Pull request announcement

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? 

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.