[boost] CMake in Boost

Subject: [boost] CMake in Boost
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-09-27 18:23:13

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Robert Ramey via Boost
> Sent: Friday, September 14, 2018 10:27 PM
>
>
> Many have expressed the desire that Boost support CMake. The Boost Board
> of Directors has emitted some sort of resolution to this effect - it's
> been a year.
> 
> I would like to see progress in this direction.  To this end I propose
> the following:
> 
> a) Boost announce that a review of proposals to incorporate CMake into
> boost will be held in January 2019.  This will follow customary Boost
> practices.

Sounds good

> 
> b) Those who are willing and able to submit code/documentation and
> whatever else in necessary should do so before this date. I would
> anticipate at least two such submissions.  As is the case with other
> reviews, I would not exist such submissions to be totally complete. But
> I would expect that they include enough for reviewers to test and
> practice with the proposed system.
> 
> c) Prior to this discussions can be held on the list regarding the scope
> of such an effort.  The review manager will distill these discussions to
> a statement of scope.  This will be posted around 30 October 2018.

Not a lot of time till then, so here are my 2cents:

First of all, I don't think the whole thing is worth it if the goal isn't 
to completely replace b2 as a top level build system. Now, that doesn't 
mean that individual libraries can't use whatever build system they want 
internally (cmake can call any build command you want), but if there isn't 
at least one common way to run the build and test and to communicate 
dependencies, you can essentially say goodbye to a common release management 
etc. As I said previously, cmake is by far the most common cross-platform 
(meta-) build system out there, which has the nice side-effect that most 
other build systems, IDEs and package managers have support for it.  

Now, a submission should have two parts:
1) A description on a plain/native cmake level what the interface to a 
   c++library (on a build system level) should look like: 
   How can the build of a library be triggered? How can the tests be run? 
   What naming scheme should be used? What are common configuration variables 
   that should be respected? How should boost internal dependencies be found / 
   searched? ...
   If that interface is specified, everyone can implement it the way he/she prefers
2) A library that simplifies the implementation of the aforementioned 
   interface as much as possible

I'm not saying that the first part can't be a byproduct of the second, they 
should be documented and evaluated separately instead of saying "your c++ 
library's build process has to be compatible to whatever "my cmake library" 
does. As was mentioned multiple times, individual boost libraries need to 
become more independent of each other, so forcing everyone to depend on a 
common cmake library is a step in the wrong direction.

> 
> I nominate myself (Robert Ramey) as review manager in this instance.

You have my vote

Best

Mike