Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2017-07-19 14:47:41

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Raffi Enficiaud via Boost
> Sent: 19 July 2017 14:15
> To: boost_at_[hidden]
> Cc: Raffi Enficiaud
> Subject: Re: [boost] CMake Announcement from Boost Steering Committee
> 
> Le 19.07.17 à 14:27, Rene Rivera via Boost a écrit :
> > I hate getting into these kinds of arguments.. But this email is a bit too
> > far for me to not respond.
> >
> > On Wed, Jul 19, 2017 at 6:05 AM, David Sankel via Boost <
> > boost_at_[hidden]> wrote:
> >
> >>
> >> Boost needs a steering committee to break stalemates and that is why it was
> >> created and exists today.
> >
> >
> > There was no stalemate. Almost every time cmake has been brought up there's
> > been a discussion as to the merits of the build system and the impact on
> > switching. Until now the SC never got involved.
> >
> >
> >> The CMake issue has been around for years and
> >> hasn't been able to progress primarily because "obviously biased" vocal
> >> minorities were holding it back with threats.
> >
> >
> > No. There where never any threats. Only statements of what would happen.
> > And you are obviously aware of this since you considered those
> > repercussions when making the decision. So please apologize for the
> > mischaracterization and close to slander of that statement.
> >
> >
> >> Rarely has there been an
> >> anti-CMake argument that suggested CMake would hurt Boost's mission.
> >
> >
> > There has been that argument. As Boost's mission is impacted by the people
> > that volunteer considerable resources to make it survive. Until now the
> > argument has fallen to not move to cmake. Please search the archives for
> > such evidence.
> 
> @Rene: I am fully backing you on this, Rene.
> 
> My understanding of the cmake topic so far can be summarized like this:
> 1. Someone says: "cmake is cool, let's move to cmake! (smiley smiley)"
> 2. "ok, what do we need?"
> 3. "we need those features: [very ... very long list]"
> 4. "ok, who is doing what?"
> 5. Someone says: "I can pick the first two of that list" ... optionally
> later says, "we do not need the other features".
> 6. (some random time oblivion)
> 7. (void or close to it)
> 8. go back to 1.
> 
> And I started subscribing to the list only in 2014. So now that there is
> an official statement from the Steering Committee, that is not only on
> which folder should receive the CMakeLists.txt, I am really wondering
> who will do what, and I am eager to see the final code.
> 
> The cmake track has been enabled, now we need doers.

+1   -  CMake is voodoo to me ;-)  And, like Homer, my brain is full - of bjam/b2.

One or two CMake knowledgeable people have poked their heads above the parapet but so far we only have a good proof-of-concept
example by Peter Dimov - but one trivially simple by comparison with many libraries.

So we are going to need people who have skills in both bjam *and* CMake in order to make the transition.

(So PLEASE don't take your bat home Rene - we need you more than ever!  Keep up the sterling service.)

To progress beyond statements of desire and intent, we need to have quite a lot of doers to convert some existing libraries to build
using CMake.  The subset including at least system, chrono and Boost.Test (used by nearly all libraries) for starters, and then at
least a couple of BIG libraries.  Only once we get to that point can we be serious about making a change, whatever the Boost
Steering Committee may say now.

Doers?  

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]