Re: [boost] Switch to CMake -- Analysis

Subject: Re: [boost] Switch to CMake -- Analysis
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-07-21 15:57:14

On 21.07.2017 10:21, 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.

Mostly, yes. And in addition, people are very polarized (even more so as
a result of this ongoing discussion). So to frame the question as
"should we stay with Boost.Build or should we move to CMake" is
extremely counter-productive.

We need a way to continue to draw from the wealth of expertise encoded
in the existing Boost.Build infrastructure as well as the community
around it, while at the same time being open to change (in general, not
just towards alternative build tools). To invoke a higher authority to
decide to get out of this stalemate is foolish, as it entirely ignores
both how Open Source works in general (you can't coerce people into
doing things they aren't motivated to do to begin with), as well as the
real reason for the stalemate: it's due to an artificial dichotomy:
either Boost.Build or CMake, globally, for everyone at once.

Here is (once again) how I would approach this instead:

* Improve the existing Boost.Build infrastructure to allow libraries to
be built stand-alone. (I remember from discussing with Rene a year ago
that he had some work in progress to achieve this, so I don't think this
is particularly hard, at least not for someone understanding Boost.Build
internals).
* Replace the top-level build logic  to simply iterate over all
libraries, invoking this stand-alone build logic.
* With the above in place, it becomes possible to switch from
Boost.Build to CMake one library at a time, so the original question can
be reframed as "which library wants to switch from Boost.Build to
CMake", which, I'm sure, will be much less disruptive (if at all) and
non-controversial, as the people to decide will be project maintainers
and communities.

Does this process appeal to anyone ?

Regards,
        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...