On 10/18/18 6:14 PM, Robert Ramey via Boost wrote:
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.
Huh ! While what you say might be technically true, you only need to look at the mail's subject line to get a radically different perspective. So in a way you are contradicting yourself here: You prepare a RFP (Request for Proposals) / Call for Submissions titled "CMake for Boost". In the text you say you talk almost exclusively about modularity (i.e. you tell me that the requirements could be met even without changing the build system), but you insist that you don't want to mention modularity because it's such a contentious topic. Sorry, but I don't know how to parse that cleanly.
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.
Well, that last bit requires elaboration. Are you "optionally" requiring that a user be able to build *any* library with CMake ? How would you do that without the library's maintainer's consent ? Or did you mean that *some* library authors may ("optionally") switch to CMake, without imposing any changes on anyone else ?
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.
My suggestion is to add a requirement that
* a solution must allow for a heterogeneous environment, where some Boost libraries are still built with Boost.Build, while others are built with CMake.
Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...