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

Subject: Re: [boost] Boost CMake support - Request for Comment
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-10-12 17:06:15

On 10/11/18 9:45 PM, Rene Rivera via Boost wrote:

> Second, I think the scope and goals of supporting CMake, even though well
> intentioned, fall short of what Boost needs to do to resolve the varied
> afflictions that plague us.

Well, the scope, goals and requirements of CMake as it relates to Boost 
aren't decided yet.  That is the current discussion.

I don't believe that CMake will address all the afflictions that plague 
us.  I believe it will make boost in someway better.  That is my aspiration.

> In what follows when I refer to: "users" I mean those programmers that
> obtain Boost and use the libraries in their projects, and "authors" as the
> programmers that develop and support the Boost Libraries and tools.
> 
> 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.

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

> As it doesn't address the long term viability of Boost. 

Not explicitly. But I believe it will contribute to the long term 
visibility of Boost.

> And hence if we are going to spend considerable effort it should be towards modularity. 

By keeping the scope relatively narrow, I hope to be able to make actual 
progress.  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 makes it impossible to reach 
consensus which is the bedrock of Boost.  We've tried the marxist 
approach to move to Boost 2.0 and it's failed us.  Now we're going to 
try capitalism - which accepts and embraces failure is an inevitable 
cost of moving forward.

> In addition to the standard requirements that Robert
> mentioned here's what I think is required for a modular Boost:
> 
> 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.

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

LOL - the hole grail!  It's never going to happen.  The advocates of 
this view have totally misunderstood the meaning and role of dependency 
in this context.  Like the knights of old, they will continue to pursue 
this holy grail - always getting closer - but never capturing the prize. 
I've recently described my views on this in detail (for the Nth time!) 
on slack in a thread with Peter Dimov.  And for the Nth time I've failed 
to convince anyone!  LOL If he's sir galahad, maybe I'm don quijote - 
both pure of heart but totally misguided in different ways.  (I'm just 
being entertaining here - I know I'm right and have proven it many times.)

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

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"

> To telegraph my intent for when it's time for proposals.. I think that for
> #1 above I think we should be forward looking and follow the Pitchfork
> structure proposal <http://bit.ly/2Edy4pC>.

Interesting - but as I said before - out of scope.

> As for build system.. I think I only have one additional requirement given
> the above:
> 
> 1) We should support generating multiple build system files for
> distribution and development from the introspection of the modular Boost
> libraries to support the varied user and developer needs.

LOL - that could mean anything - maybe you should run for office!  I 
think I get the idea but would phrase it differently:

"A CMake integration should not conflict with the current build system 
or other boost tools"

Robert Ramey