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 21:29:35

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

> 
> Anything less than that is not going to fly.

Modularity has been a goal of mine for many years - see Boost 2.0 
presentation at C++Now in 2010.  I think that modularity is implied by 
the other requirements. I don't think one could fulfill the requirements 
without being consistent with "Modularity".  Maybe you should read the 
document more closely.

I refrained from explicitly mentioning "Modularity" because I don't and 
didn't want this to be a debate about "Modularity".

Robert Ramey

> 
> 
> Stefan
>