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-18 23:18:25

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
>