[boost] CMake in Boost

-----Original Message----- From: Boost 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