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