Hi Robert, On 10/18/18 4:43 PM, Robert Ramey via Boost wrote:
The following is a draft of the document of I have planned to post on behalf of Boost on or around 1 November 2018 as the first step in our next attempt to accommodate CMake in Boost.
[...] Quite a number of people (Rene, Edward, myself, ...) have argued in different ways against a wholesale switch from Boost.Build to CMake. While for some the point is more about incrementality of the process, for others it's about autonomy and modularity. I'm surprised, even shocked, to see that your draft doesn't even mention modularity as a goal, but again focusses exclusively on the modalities of an eventual switch. I have said it often, and I'm saying it again: you can't force a Boost maintainer to adopt a CMake-based build system for his project. You can only show by example that it works well (by picking volunteer projects as early adapters), and hope for others to follow voluntarily (incrementally over the course of a couple of releases), given that the maintenance burden of that new environment is entirely on them. So, I would expect in a RFP to find requirements such as: * a solution must allow for a heterogeneous environment, where some Boost libraries are still built with Boost.Build, while others are built with CMake. Anything less than that is not going to fly. Stefan -- ...ich hab' noch einen Koffer in Berlin...