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:05:39

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 ?

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

Thanks,

Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...