On 10/18/18 3:06 PM, Stefan Seefeld via Boost wrote:
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)
True - and could be met if not libraries switched to CMake. Not that there is not even a suggestion that boost build be replaced. Only that the (optionally) the user be able to build any library with CMake. this is all intentional. I didn't want to impose any more than the minimal conditions.
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.
OK - I'll add in a sentence to make it clearer. Feel free to suggest your own wording. Robert Ramey
Stefan