On Tue, 2022-02-15 at 15:37 -0600, Bob Friesenhahn wrote: > I have been told by several people (who have much more self-esteem > than me) that a build tool called 'cmake' is far more portable than > Autotools so maybe we should make support for 32 year old systems > cmake's responsibility? That is not accurate. Or at least, cmake uses a much different definition of "portable" than autoconf / automake. Certainly cmake cannot possibly support 32-year old systems (if that's needed). cmake is a tool that, given an input definition of build dependencies, can generate build control files for multiple different types of build tools. It can generate makefiles, Ninja files, Xcode project files, and Visual Studio project files. Maybe others, I'm not sure. So in that sense it's "more portable" because given a single input definition you can build the project with both make-based systems and Visual Studio-based systems (etc.) without extra maintenance work. However, of course because the definition files must be able to generate all these different outputs they are necessarily "least common denominator" definitions; you can't just define a new make rule to do something obscure like you can with automake. Cmake works great for simple projects but you will absolutely struggle to encode more complex build requirements. And, cmake has really not much comparable to autoconf. It does provide some very minimal support for choosing some compiler options and some facilities sort of like pkg-config but nothing even approaching the kinds of checks and configuration that autoconf supports. The main idea of autoconf is that it allows configuring the package for systems that the author never even heard of, much less has access to (as long as it has a POSIX interface). cmake only tries to generate output files for systems it has been developed for (for example, each new version of Visual Studio often requires a new release of cmake to support it). Of course maybe autoconf is not necessary anymore: I don't know about that. I do know that even though GNU make itself is relatively simple, people still build and use it on older, and non-GNU/Linux, systems, and that they want to use cross-compilers (cmake can do this, kind of, but it's much more difficult than autotools support) and other more advanced operations.
