On Sun, 16 Sep 2018 at 20:20, Niall Douglas via Boost
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. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net