On 10/18/17 8:10 AM, Rene Rivera via Boost wrote:
Nah.. Programmers have a long history of accepting edicts about the tools and methods that others proclaim. And I doubt this will be any different from that history.
Let's keep muddling on ;-)
Right.. Lets accept what is given without any say on it.
and Carry On Coding :-)
Sure.. We'll rowing to the drum beat.
I fear that you've fallen into the same trap that the steering committee has - that what they say makes a lot of difference. They can do a lot of things: spend some money, make proclamations, pass a code of conduct, stuff like that - but nothing really of substance. If you want proof just look at the last attempt to impose CMake. What they can do is to try to recognize, and build concensus. That is, buy the time the issue has ripened to the point that there is a consensus, they can climb on board to give the impression that they actually did something. Witness the successful transition to git from svn - which was much simpler by the way. So they can make a difference at the margin. But the rest is just a facade. Of course this is not a phenomenon unique to boost - its the general way of doing things in civilized society. Hence we see boards of directors filled with prestigious names who spend only a couple of days a year "working" to give give "guidance and direction" to the organization. (The boost steering committee is an exception of course) Don't think of this as a negative thing - imagine what the world would be like if these people actually did run things. Actually you don't have to imagine, consider the soviet politburo for obvious example. I've been a regular complainer about a number of aspects of boost build over the years, but I have huge respect for the developers of the current boost build setup. They have been reliable maintainers of the system and it's something we have been able to depend upon. But it has problematic aspects which have never been addressed. So here we are. Anyway, there are good reasons for Boost to support those who want/need to use CMake. I DO think there is a consensus about this. The problem is that it's not clear what this would really mean and require. CMake has facets for building IDE, a GUI vs Command line interface, Building libraries, Setting up and running tests, Posting tests results to a dashboard, and deployment of packages. Understanding these different facets currently requires one to spend a lot of time googling CMake explanations - none of which is particularly clear and comprehensive. There are open questions regarding how this would work in the context of Boost. E.G what this means for users vs developers, what facilities from CMake we might want to use and how it would provide facilities which we currently depend upon. It's stunning to me that in spite of a widely held view that that boost should support CMake, no one has posted a real proposal about what parts we should use, how we should use them to support development, maintenance, testing, deployment of the federation of libraries which currently constitute boost. Until such a proposal is presented, no progress can be made. Robert Ramey