On 10/18/18 5:29 PM, Robert Ramey via Boost wrote:
On 10/18/18 2:15 PM, Stefan Seefeld via Boost wrote:
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.
I think this is a necessary conclusion given the other conditions. Including, but not limited to:
*j) support of library modularity. This would mean: *1) independence of things outside the library directory structure. To wit - no presumption about any "super project". *2) building out of tree *3) no need for installing libraries not used by the build target
OK, these look good, but they don't imply that a heterogeneous setup needs to be supported. (Read: the above requirements could be met even if all libraries were switching to CMake) More importantly: I don't want anyone to interpret this as if a CMake-based solution that meets the above is implicitly approved and adopted by all maintainers. I expressly want to be able to keep using Boost.Build (or at least, not having to use CMake :-) ), so the requirements for heterogeneity go both ways: Boost.Build needs to become modular in that it needs to be able to accept prerequisite projects being built using CMake, and any CMake-based solution needs to be able to accept prerequisites that are *not* built using CMake. Even if these are implied in your interpretation of the above, I think it's reasonable to spell them out explicitly. Stefan -- ...ich hab' noch einen Koffer in Berlin...