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".
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk