Re: [boost] [cmake] Pull request announcement

Am So., 16. Sep. 2018 um 21:46 Uhr schrieb Mateusz Loskot via Boost < boost@lists.boost.org>:

On Sun, 16 Sep 2018 at 20:20, Niall Douglas via Boost 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