On 10/18/18 4:45 PM, Stefan Seefeld via Boost wrote:
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.
The language doesn't say library authors are required to add the facilities. It says they should be able to easily add these facilities. What do you think it should say instead?
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.
OK - It seems pretty clear to me. Feel free to suggest other language.
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.
Right - that's why I didn't want to mention it explicitly.
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.
Right - but have patience, someone will inject the topic. I've been hoping, perhaps in vain, to avoid that.
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 ! :-)
The current title is: Call for Submissions - CMake for Boost. I'm not seeing where that mentions Boost Build. I actually carefully thought about the title just to avoid this criticism. What do you think the title should be? I've referred to CMake for Boost, CMake facilities for boost libraries, etc. Seems pretty clear to me. But anyone who thinks this is confusing is free to suggest a change in wording.
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").
To summarize, you're in agreement with the content, we're just talking about the phrasing to make it less subject to mis-interpretation, Right? I'd be happy to hear what others says about this. I'm also interested in hearing comments about the actual substance of the proposal. Robert Ramey
Stefan