On Tue, Feb 15, 2022 at 6:01 PM Bob Friesenhahn <bfriesen@xxxxxxxxxxxxxxxxxxx> wrote: > The people who tell me it is more portable are very interested in > targeting Microsoft Windows. Introduce them to mingw-w64.sf.net + msys2 :) I heard good things about those :P > The "Makefiles" that Cmake generates are self-referential in that > almost all rules invoke Cmake to do the work. > I find that the function of Autoconf is quite useful. When compared > with Cmake, it is much more user-friendly since the configure script > responds to --help and the help output is very helpful. The configure > script nicely tells me what it is doing and what it found. Autotools > is very structured and projects work in a common way whereas I find > that Cmake projects are heavily customized with options added by the > project developer. Just doing a build entirely outside of the source > tree is extremely clumsy with Cmake. > > Regardless, I don't think that Autotools developers should waste time > on assuring compatability with systems which are no longer in active > use. It is much better so spend time improving areas where Autotools > is weak. "Portability" is impossible to quantify. It expands to far more than support of ancient, esoteric tools. I would argue that Cmake is less portable, since it requires that Cmake be available for a user to build the software. That can be onerous, especially if the user doesn't have permission to install Cmake. Autoconf requires 'sh', and automake requires 'make'. I would further argue that Cmake is less portable because it's less user friendly. The poor man's distinction is that autotools makes life for the project owner hard so that the life of the user is easy. Cmake does the exact opposite, and makes the user's life a difficult experience so that the developer's life is simpler. I would extrapolate that to the realm of "less portable", since it requires that I have more system requirements in my own brain (skills, knowledge, experience). Whereas I can handle any autotools package trivially with "./configure CFLAGS=-myflag CXX=myC++Compiler --enable-option --with-package=/custom/path", and know very little about the upstream project, I can't do so with a Cmake based build system. For me, this isn't about 32-year old artifacts. This is about the infinitely diverse nature of any modern, still maintained system. In a world of corporate policies, shifting environments, environment modules, embedded devices, cyber security, firewalls, user permissions, and all sorts of other mitigating factors, all of which I personally must deal with when trying to deploy any given package to an environment, I will pick autotools every single time. The workload required for me to deploy an autotools package is exponentially smaller than that required of a Cmake package.
