Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-06-17 01:01:30

On 6/16/17 4:44 PM, David Sankel via Boost wrote:

> The motivation is simple. CMake is currently the dominant player in the
> area of open-source, cross-platform, C++ build-systems. 

no dispute here

> * To ease the migration path, both Boost.Build (the current jam-based build
>    system) and CMake will be supported for a time.

> * Boost sources would provide a compatible, drop-in replacement for the
>    'FindBoost' module that is distributed with CMake. A CMake-based
> application
>    could point to it and, instead of using the system Boost libraries, Boost
>    targets would be built from source as part of the user build.

Hmmm would this be a FindBoost for the whole of Boost or for each 
particular library?  Who would re-write and maintain this FindBoost as 
the current one is not up the task.  Getting this right - or even better 
is not a trivial task.

> * The built Boost **binaries** would also provide a compatible, drop-in
>    replacement for the 'FindBoost' module distributed with CMake. The
> behavior
>    is similar to the previous bullet, except the built binaries would be used
>    instead of the source code.

Another layer of work for "someone" to do and maintain.

> * The style of the 'CMakeLists.txt' files would follow current best
> practice.

LOL - good luck on finding a concensus here.  Every body and his brother 
has his own agenda to make his library "perfect" and to anticipate what 
he is sure of are "what users need".

>    We'd resist the temptation to write macros which replace the core CMake
>    functions. There would be repetition in the files, to be sure, but I
> think we
>    should avoid attempting to innovate CMake. I've seen this fail on many
>    occasions and would like to keep our goal focused, at this point, on
>    migrating Boost to CMake. In the future we could revisit this.

Your correct on all of the above, but CMake isn't really good enough to 
use out of the box.  I had to make a bunch of macros to get to work at 
all on my environment - it's not an uncommon environment.

> * There would be a list of CMake guidelines that we'd use.

ahhh - another great mailing list topic.

> * Boost libraries should be buildable in isolation and use
>    'find_package(Boost...)' to discover their Boost dependencies

> * We would work with CMake towards eventually taking over maintenance of the
>    FindBoost module distributed with CMake.

A much bigger job that it would appear.
> 
> I see this progressing with several milestones.
> 
> 1. Release of a CMake-buildable Boost and the CMake conventions. In this
> stage
>     each Boost library can be built in isolation or with the entire
> distribution
>     and all the 'FindBoost' functionality mentioned above would be
> incorporated.

> 2. The unit tests for all Boost libraries are incorporated into CTest (the
>     CMake unit test orchestration tools).

My experience is that many boost tests cannot be run with cmake.  For 
example, I cannot make a CTest test which will be successful on 
compile-fail. - Correction I can, but involves some gymnastics about 
re-invoking CMake and capturing the result and inverting it and ...

> 3. The Boost infrastructure is modified to use CTest for unit testing.

I don't think this would be necessary.

> 4. Unit testing functionality is removed from Boost.Build.

I don't think this is necessary either.

> 5. Boost.Build is removed.

If CMake is successful, boost build would die on it's own.  If you have 
to forcibly remove it, you've failed.

> Although there are many other great ideas floating around (e.g.
> modularization
> of Boost, Boost-Classic, and Boost2), I'd like to keep this focused on
> CMakification of Boost because I think it is something that would have big
> impact and is small enough to be doable.

The problem is that we have problems migrating to CMake BECAUSE we've 
got with the other stuff mentioned.

Actually, I believe the real problem is the monolithic build/test design 
of boost libraries which inhibits evolution.  Boost Build developers 
have been very accommodating about adjusting to the particular features 
of different libraries.  This demonstrates good will, but has given use 
with a testing/deployment setup which is very complex.

> One question that is going to come up is "who is going to do all this
> work?".
> Once we decide on a direction, I don't foresee a problem making this happen.
> Between volunteers, the importance this project has for companies, and the
> Steering Committee reserves, we should have the resources necessary.

LOL - promote this guy to management !!!!

> Another concern is that some authors may resist. Authors have a lot of
> leeway
> when it comes to how they maintain their libraries, what conventions they
> use,
> and backwards compatibility concerns. However, there are some things that
> authors need to conform to, such as our current Boost.Build build and
> testing
> infrastructure. I liken this to the development of a city: building
> developers
> can make their buildings however they want, but the streets, which control
> transit between buildings, are centrally regulated.

LOL - as someone who has actually built a house, I see the analogy.  But 
I've alse seen that it doesn't create all the benefits it's expected to 
deliver.  More central control sounds like a good idea, but it results 
in decisions driven more by politics, particular conflicting interests, 
excessive conservatism but bureacrats and other entrenched interests.

How is the C++ standard committee working out.  Concepts have been in 
development for 12 years and only 3 years to go.  If Boost went in that 
direction we'd still be .... nowhere

I've ridiculed your proposal more than I meant to.  (Of course that's 
what makes the mailing list fun.)  But I realize that it is a sincere 
effort attempt to address a real problem.  Rather then making this post 
boring, I'll follow on with a counter proposal which I think will 
address some of your concerns and incorporate your suggestions in a way 
which I think is more practical.

Robert Ramey