On 10/18/18 7:18 PM, Robert Ramey via Boost wrote:
On 10/18/18 4:05 PM, Stefan Seefeld via Boost wrote:
On 10/18/18 6:14 PM, Robert Ramey via Boost wrote:
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
But that's my point: You should not require library authors to "easily add these facilities", as it comes with an additional maintenance burden. It should be up to them to decide what they add.
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.
Ah. Well, I'm certainly willing to consider any CMake-based solution, and adopt it if I feel comfortable with it. So as long as we make it clear that adoption is optional rather than mandatory (and that consequently any submission needs to account for such a heterogeneous state of affairs), we are fine. But again, that needs to be spelled out loud and clear in the RFP.
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.
Well, there is no point not to talk about Boost.Build, as that is the current build infrastructure. And frankly, with all the eyes on CMake these days, you can avoid naming it as much you like, everyone sees the elephant in the room. But most importantly: change the subject line / the title of your Call for Submissions if you want to avoid naming the One-Who-Must-Not-Be-Named ! :-)
How about, "Adding CMake support to any library shouldn't conflict with any other facilities that Boost offers, such as Boost Build."
That sounds very much out of context, if it's the only mention of CMake in the whole document. Frankly, I don't find that statement very clear, and think that my proposed requirement above is a lot more precise and constructive (and would remain so even if we substituted "Boost.Build" and "CMake" by "the existing build system" and "another build system"). Stefan -- ...ich hab' noch einen Koffer in Berlin...