Re: [boost] Draft copy - Call for Submissions - CMake for Boost

Subject: Re: [boost] Draft copy - Call for Submissions - CMake for Boost
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-10-19 00:12:17

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
>