[boost] Switch to CMake -- Analysis

Subject: [boost] Switch to CMake -- Analysis
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2017-07-21 14:21:18

Hi list,

After there has been a heated debated over the last three days over the
switch to CMake, I'd like to share my observations...

First of all, a general observation: In this discussion, there generally
seems to two camps: Those who know Boost.Build and those who know CMake.
Unfortunately, there doesn't seem to be any overlap between those
groups, which generally made the discussions about a potential switch to
CMake unfruitful, often leading to misunderstandings due to a lack of
knowledge about the other tool. There is no doubt, that the group of
people knowing CMake is larger and that projects using CMake far
outnumber the ones using Boost.Build. A thousand flies can't be wrong,
right? Is the popularity of CMake really the only benefit?

Here is the thing, from my point of view: Apart from the different
philosophy (Build System vs. Build System generator), in the end, you
get a executable/library out of the system. From a pragmatic point of
view, the only thing that changes to develop/build/test/use a library is
the work flow. Leaving aside the disruptive and its effects of such.

Now, on to the motivation for switching, as presented in the announcement:
On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote:
> [...] our build system has become an impediment for many developers
> and users, existing and prospective.

Let's look at users first. Yes, FindBoost.cmake has its problems, but it
works in 90% of the cases (from my own experience). This can, and should
certainly be improved. Providing the necessary XXX-config.cmake files is
what fixes this. There has been movement in that direction, with code,
which could be just improved upon. This will fix those cases. The other
group of library consumers, expressed the urge to build boost directly
as part of their build process. That hasn't been done yet, but I am
pretty certain, there are no road blocks to actually write such a CMake
Module, which invokes b2 instead of the compiler directly inside of the
superproject. Together with the generated XXX-config.cmake files, this
use case is covered. From my recollection of the various discussions,
this approach was not contentious at all, it wouldn't even require
interaction with all library maintainers, and all CMake users (existing
or prospective) would immediately benefit.

Now on to developers. There is obviously a lot of resistance from
existing developers (for various reasons, which are not really relevant
for the discussion at hand). In my opinion, maintaining two build
systems is a no-go. Either make a clear cut, or don't. Please don't
waste resources on maintaining and supporting both. With this line of
thought as the background, this will create massive disruption.
Switching the whole of boost (including infrastructure, documentation
etc.) to be built and tested with CMake is not easy and take a lot of
time, leaving a void for both maintainers and prospective boost library
authors.

Now, the argument that has been brought up very often in favor for the
switch is that it will attract more contributors, but will it really?
I am reluctant to the idea that people don't contribute new libraries to
boost just because of the build system. Despite a switch to cmake, you'd
still have to conform to Boost.CMake guidelines and somehow make your
library buildable and testable within and outside of the Boost Tree
(there might be a straight forward solution to this).
Furthermore, I often hear something like "in the presence of GitHub and
CMake people don't think about submitting to boost anymore". This is
exactly the point. But it has nothing to do with the "and CMake" suffix.
It's is just far more easier and convenient to drop you library to
GitHub, advertise it on various channels and call it a day. I hear you
say: "Sure, but libraries will only be adopted if they come with CMake."
That might very well be true, but what has this to do with Boost?
Compare the lengthy and exhausting review process you have to go through
with the click of a few buttons and hammering something onto a keyboard.
And no, Robert, while the incubator was a nice idea, it doesn't
compensate that either ;)

All in all, I am pretty confident that a disruptive switch will hurt
Boost more than it brings benefit. This already happened. To come to an
end and summarize: Provide proper CMake integration, such that Boost is
consumable by those (while you are at it, don't forget meson, bazel and
pkg-config). While your add it, improve Boost.Build, maybe it can rise
again from its ashes (why did it "fail" in the first place?).

Regards,
Thomas