Re: [boost] Switch to CMake -- Analysis

Subject: Re: [boost] Switch to CMake -- Analysis
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-07-21 17:16:59

On 7/21/17 8:57 AM, Stefan Seefeld via Boost wrote:
> 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).

This is already in place.  I all the time.  Here is what I do:
a) I make a change to some library
b) I cd to the test directory of the library
c) I invoke b2 to build and run the tests (I do this through the 
library_test macro in boost/tools, but that's not essential).
d) the b2 build any dependent libraries and runs the tests of the 
library I'm working on.

> * Replace the top-level build logic  to simply iterate over all
> libraries, invoking this stand-alone build logic.

This is what the top level build logic does.  I once posted a simple 
shell script which would do exactly that.  I turned out that this didn't 
work because the top level system had some library specific logic in it 
to accomodate some libraries which "do their own thing".  I noted at the 
time that it was a mistake to do this and that library authors should 
have committed to boost requirements rather than the other way around.

> * 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.

This is indeed possible.  In fact its quite easy.  I created CMake 
CMakeList.txt files for the serialization libary - which has a very 
complex testing regimen.  It's also not header only and supports a lot 
of variants, static, debug, the works.  The safe numerics version even 
supports the CDash functionality which would be very useful to boost.  I 
didn't like the way CMake implemented though.  I did this because I 
wanted to be able to create an IDE for editing, testing and debugging 
the library.

It's very easy for anyone who is interested to invoke CMake in the 
serialization directory, build and IDE and open it up and see what you 
get.  So far as I know - only one person has actually done this.

> Does this process appeal to anyone ?

Makes total sense to me.

There are a couple of I haven't addressed because I haven't need them.

a) The CDash functionality - needs a much better solution
c) The CPack - packager - I have never figured out the utility of this
c) FindBoostSerialization library.  THis might be interesting to users 
or maybe not.  When I use Boost in a CMake project I use FindBoost. 
This doesn't really work, but with some horsing around it can be made to 
work.

There are lots of opinions on this thread amounting to saying "Here is 
what needs to be done - Developers (or someone else) should be forced to 
do it".  This has gone nowhere and is not going anywhere.  The SC can 
make any pronouncement it wants, but that's all its going to be until 
someone actually DOES something.  The closed I've seen are my pages on 
CMake in the incubator and Peter Dimovs CMake proposal (which I haven't 
had time to study).  Other than that ... nothing of substance.

Robert Ramey