Re: [boost] Boost CMake support - Request for Comment

Subject: Re: [boost] Boost CMake support - Request for Comment
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2018-10-14 01:33:37

Hi Rene, Robert, all,

On 10/12/18 3:04 PM, Rene Rivera via Boost wrote:
>>> With that in mind, what I would like us to do is what I've mentioned many
>>> times in the past.. Move towards a truly modular Boost distribution and
>>> development that: a) supports users no matter what environment they
>> choose
>>> to use Boost Libraries in, b) supports developers to flexibly develop and
>>> test their libraries, c) allows Boost to grow in a way that doesn't
>> cripple
>>> development resources.
>> This is my goal as well.  I believe that a CMake support of boost will
>> take use closer to that goal.
>>
> Again, I disagree, no build system will take us closer to that goal because
> it's not the build system at fault.

+10

>>> I think that without a "fully normalized modular Boost" a CMake, or any
>>> other build system, effort is a waste of time.
>> Of course we differ.  I don't believe it a grand (intelligent?) design.
>> I believe in evolution.  It is my intention that CMake support of boost
>> will bring us close to the goal of a modular boost - which I've referred
>> to in the past as Boost 2.0.

I'm a big fan of incremental progress (which is my attempt at
paraphrasing your use of the term "evolution"), and it is precisely for
that reason that I think "modularity" must include organizational /
administrative aspects (e.g. the ability to take certain decisions per
project rather than monolithically for the whole organization) rather
than only technical ones (e.g. the ability to build individual projects).

Not only would a solution that involves some projects using CMake and
some using Boost.Build be a much more convincing demonstration of
modularity, it would also address a range of concerns voiced by others
(including Edward Diener in
https://lists.boost.org/Archives/boost/2018/10/243620.php and myself in
https://lists.boost.org/Archives/boost/2018/09/243293.php et al.)

>> This is a key feature of my proposal and strategy. Other more
>> ambitious and grandiose initiatives have failed in the past because they
>> were too ambitious and grandiose.

This seems to be a question of perspective. To me a proposal to "switch
from Boost.Build to CMake for the entirety of Boost" is a way more
ambitious goal than to "change the Boost infrastructure to support
individual projects to switch to CMake".

>> This makes it impossible to reach
>> consensus which is the bedrock of Boost.

Consensus would be great, but we (the community) have demonstrated that
it has its limits, i.e. it doesn't scale well.

And of course, to state the obvious: This isn't a democracy. It's the
developers and maintainers who put in the effort to develop and maintain
individual projects who should have the ultimate power to decide.

>>> 1) Fully normalized library file structure that can be introspected.
>> This would be nice - but I don't think it's essential to making a CMake
>> Boost integration.
>>
> True it's not essential. But it would make any build system integration a
> magnitude easier (and I'm including b2 reintegration here).

"Provide the following integration points: ..." would be a much simpler
set of requirements. But I agree of course with the general idea:
establish fewer points to be standardized, to improve the ability to
encapsulate and insulate "implementation details".

>>> 2) Clear inter-library, and non-cyclic, dependency arrangement and
>>> information.

+10

>>> 3) Abandon the super-project structure as a development and distribution
>>> vehicle.

+10

>> I agree with this.  It's my current intention that the "scope and
>> requirements" include the statement like:
>>
>> "Any CMake support of Boost should not presume any super project or
>> similar directory structure outside of any particular library"
>>
> Sounds good.. Just replace "CMake" with "build system".

Yes !!

Stefan

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