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

Subject: Re: [boost] Boost CMake support - Request for Comment
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2018-10-12 19:04:34

On Fri, Oct 12, 2018 at 12:06 PM Robert Ramey via Boost <
boost_at_[hidden]> wrote:

> On 10/11/18 9:45 PM, Rene Rivera via Boost wrote:
>
> I believe it [CMake] will make boost in someway better.
>

And that's the aspect that I've never seen.

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

Again, I disagree, no build system will take us closer to that goal because
it's not the build system at fault.

> > 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've tried evolution. I spent the past 10 years slowly moving Boost to be
modular. No one cared enough to make the needed changes. People are adverse
to changes that they have to implement (this itself being a prime example
-- in multiple meanings).

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

I don't thin Boost has a visibility problem.

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

Been there, done that, failed.

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

I disagree. They failed because they attempted to make *multiple* ambitious
changes at once. Single, focused, ambitious changes are achievable.

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

So far in this discussion multiple people have mentioned modularity as a
goal. How is that not consensus?

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

True it's not essential. But it would make any build system integration a
magnitude easier (and I'm including b2 reintegration here).

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

Yep, saw that, and was in that argument. And been in that argument multiple
times now :-) I've lived in multiple audiences in this argument as an
author, user, and packager. I hate to break it to you.. But you're going to
keep not convincing anyone ;-)

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

Sounds good.. Just replace "CMake" with "build system".

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

Not entirely out of scope. Colby and others are working to make CMake
directly use such a structure. It would make the CMake effort easier to
accomplish with less work from authors.

> 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've thought about running for office :-) But gave up changing the world
through politics at my last stint with political party involvement.

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

Perhaps.

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net