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

Subject: Re: [boost] Draft copy - Call for Submissions - CMake for Boost
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2018-10-18 23:45:40

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...