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 22:06:05

On 10/18/18 5:29 PM, Robert Ramey via Boost wrote:
> On 10/18/18 2:15 PM, Stefan Seefeld via Boost wrote:
>> Hi Robert,
>>
>> On 10/18/18 4:43 PM, Robert Ramey via Boost wrote:
>>> The following is a draft of the document of I have planned to post on
>>> behalf of Boost on or around 1 November 2018 as the first step in our
>>> next attempt to accommodate CMake in Boost.
>>
>> [...]
>>
>> Quite a number of people (Rene, Edward, myself, ...) have argued in
>> different ways against a wholesale switch from Boost.Build to CMake.
>> While for some the point is more about incrementality of the process,
>> for others it's about autonomy and modularity.
>>
>> I'm surprised, even shocked, to see that your draft doesn't even mention
>> modularity as a goal, but again focusses exclusively on the modalities
>> of an eventual switch. I have said it often, and I'm saying it again:
>> you can't force a Boost maintainer to adopt a CMake-based build system
>> for his project. You can only show by example that it works well (by
>> picking volunteer projects as early adapters), and hope for others to
>> follow voluntarily (incrementally over the course of a couple of
>> releases), given that the maintenance burden of that new environment is
>> entirely on them.
>>
>> 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)

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.

Stefan

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