As always, thanks for all your effort Zack! I wanted to share some of my thoughts on Autoconf and friends. Maybe I wrote too much. For me the most important requirement of the GNU build system is that it must be as straightforward as possible for novice users to build free software packages from source code, with or without local modification. This is what empowers users with the benefits of free software. If users are unable to build or modify the software that they use, they are unable to take advantage of those benefits. For me, every other consideration is secondary. The interface consistency prescribed by the GNU coding standards goes a long way: you learn the steps for one package and can apply that knowledge to almost any other package. The trend towards requiring everyone to build from VCS snapshots and requiring zillions of specific versions of various build tools is concerning. Unfortunately I think many developers don't really care about the user experience when it comes to building their software releases from source. This brings me to another important strength of the GNU Build System: if I prepare a package today I want to be confident that people will still be able to build it 5, 10, 20 or more years from now. Now obviously we can't predict the future but we can look to past experience: just today, I unpacked GNU Bison 1.25 (ca. 1996) on a modern GNU/Linux system, running on a processor architecture and distribution that didn't even exist back then, and it builds *out of the box*. Typical issues encountered with old GNU packages are usually very minor if you have any problems at all. For a more complex example, I tried building glib-1.2.10 (ca. 2001). I had to update config.sub/config.guess to the latest, set CC='gcc -std=gnu89' (because the code does not work with C99 inline) and edit one line of code to disable use of an obsolete GNU C extension (both compilation problems are due to not following the Autoconf philosophy and using version checks instead of feature checks, oops!) My general experience with CMake is that you probably can't build any old packages because whatever version of CMake you have available simply doesn't understand the package's build scripts, and the version which could understand them just doesn't work on your system because you have a newer processor or something. I don't have enough experience with Meson to say. Mainstream free software packages have only very recently started using it. On the GNU side, glib-2.60 (ca. 2019) converted to meson and I am able to build it. If possible, I will have to try again in 2039. I bet the autoconf-based glib-1.2.10 tarball from 2001 will still mostly work, and so will the 1996 version of GNU Bison. Cheers, Nick
