Re: [boost] Switch to CMake -- Analysis

Subject: Re: [boost] Switch to CMake -- Analysis
From: paul (pfultz2_at_[hidden])
Date: 2017-07-21 14:55:25

On Fri, 2017-07-21 at 16:21 +0200, Thomas Heller via Boost wrote:
> 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).

pkg-config is build-indenpendent so can be consumed by meson and bazel.