I'm having a very frustrating conversation with the author of Chicken Scheme:<br><br>> > > What objective metrics does the CMake build have to fulfill?<br>> > <br>> > Popularity is one important point. The CMake build is fine. It's great. I love it.
<br>> > I don't love CMake bugs, though. I WANT CHICKEN TO BE AVAILABLE TO AS MANY USERS AS<br>> > POSSIBLE. Period. I don't want to make anybody learn something new, if he/she just<br>> > wants to get chicken running.
<br>> <br>> I don't understand why you think a person energetic enough to even bother with Chicken, is lazy<br>> enough that they won't bother with CMake. I also wonder what objective adoption metrics it would
<br>> take to dissuade you of this religion.<br><br>Is there a way that we can prove to scared project leads that they're not going to lose a bunch of users by dumping Autoconf? Do we have any objective evidence from projects that have made or are making the leap?
<br><br>I mean, this "people won't use CMake because it's not Autoconf" stuff is driving me NUTS. I am utterly irritated to see community energy split between 2 build systems, when I have provided a feature complete system that works on all platforms, it has been field tested for months, it is all but bug free, and the Autoconf build only handles the Unix-y systems. The Chicken author is far more concerned about popularity than build maintenance burdens, probably because both builds are stable right now and he's not doing any work on either of them.
<br><br>How can we put an end to this kind of foot dragging?<br><br><br>Cheers,<br>Brandon Van Every<br><br>