Re: [boost] [cmake] Pull request announcement

Subject: Re: [boost] [cmake] Pull request announcement
From: Cem Bassoy (cem.bassoy_at_[hidden])
Date: 2018-09-16 20:22:03

Am So., 16. Sep. 2018 um 21:46 Uhr schrieb Mateusz Loskot via Boost <
boost_at_[hidden]>:

> On Sun, 16 Sep 2018 at 20:20, Niall Douglas via Boost
> <boost_at_[hidden]> wrote:
> > > Instead of reposting pros/cons here again to make it into yet another
> > > forgotten post,
> > > those who care and need it should create a table on wiki with clear
> > > structured comparison.
> >
> > It seems to me that the putative review manager (Robert) should canvass
> > for solutions (there appear to be at least three now), do a quick check
> > of them to see what tradeoffs each has, and make that table summarising
> > their different approaches. He then could take a quick straw poll of
> > here to see which set of tradeoffs the community dislikes least, and
> > encourage that author to get their solution ready for review by an
> > agreed date.
>
> Sure, why not, or just decide if all proposals are ready for review, then
> all could be reviewed (straw poll the order which one goes first, etc.)
>
> > Some have argued that all this is too confusing. It is in my opinion no
> > different to any other Boost library. Somebody becomes willing to invest
> > the time and effort to get a solution to a problem past review.
> > Whichever successfully passes muster here is what we adopt. It's exactly
> > the same as any other Boost library, and calling on the Steering
> > Committee to declare a design by decree is the wrong way of doing this.
>
> I see one aspect that makes CMake for Boost different and this resembles
> (or respects) voices like Stefan Seefeld's.
> That is, one of the critical questions to CMake submitters should be:
> Are you ready and willing to maintain CMake across Boost and help
> library maintainers interested to learn CMake for some extended period of
> time.
>
> Although such situation would be hard to deal with or even not
> sensible to consider,
> I can see it plausible, that if maintainer of CMake solution disappears,
> the whole solution may stale and be voted for complete removal, or
> replacment
> with new version that has active maintainer.
> That also makes CMake for Boost different than a library acceptance.
>

True. I am very sure that Stefan and others are willing to invest their
time to learn/use CMake if the solution has major advantages compared to
the current solution.

So the critical point here might be to present the CMake solution in a
clean and clear fashion including advantages and disadvantes for the
(normal) user, contributer, maintainer, community.

As far as I see, Paul, James and others have invested so much time for a
good CMake solution.
Maybe they could prepare sth? Don't know.

Cheers
C

>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>