On 10/18/18 4:05 PM, Stefan Seefeld via Boost wrote:
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 ?
I meant that a submission should provide a set of facilities for authors and users. Authors should be able to easily add these facilities to their libraries and Users should be able to use these facilities to make their usage of Boost even more pleasant than it already is. Of course this latter would only apply to those libraries elected to support CMake for users. But I believe that if the submission accomplishes it's goals (simple implementation for authors, high utility for authors and users, etc.) it would be adopted by boost authors over a relatively short time frame. Of course I can't know this, but it would be my hope.
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.
That is not my intention. 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.
Hmmm - I intentionally avoided any explicit mention of boost build, b2, etc. as I didn't want to foment a CMake vs Boost Build discussion which could easily take a lot of time and be off topic. How about, "Adding CMake support to any library shouldn't conflict with any other facilities that Boost offers, such as Boost Build."
Thanks,
Stefan