Dear GNU Autohell...
…could you please die?
In all seriousness, I don’t understand why in our age of cross-platform considerations, distribution packages, scripting languages and refactoring, so much Linux software still uses a stone-age build system.
I could list the advantages of CMake over GNU autohell… sorry, autotools for hours. I’ll just list the ones I submitted to the gtkpod developer who argued about its advantages, after I wrote a full CMake replacement for its autotools-based build system in one day.
* autotools only generate makefiles; cmake can generate makefiles, project files for various IDEs, and has (from my experience) better support for hooking into IDEs in the first place.
* There is only one command to learn to generate makefiles, regenerate the build system after making changes, etc. No need for autogen.sh.
* cmake is well-documented and easily extensible. For nearly every dependency, you can either find the way to hook it in the base bundle, or find an existing project that has a .cmake file for it. And it’s easy to write new ones.
* Strict checking of behavior between versions, compared to the constant problems with behavior mismatches depending on which versions of autotools were used to generate the configure script.
* All configuration is in one place (but easily splittable into included files), rather than all throughout the source tree in various .am and .in files.
* No difference in the steps to build from the VCS (which has no configure script) or tarball.
* Includes only the files with relevant configuration and nothing else. autotools installs lots of additional files used in configuration and building, and while it allows one to build without autotools installed, cmake is a single binary available as a package in all major distributions.
* Arguably more concise, intuitive and easy to learn. This is subjective, but compare the new CMakeLists.txt for gtkpod with its own configure.in and tell me which one you consider more concise and intuitive.
* Faster, since it, again, only checks for dependencies directly relevant to the build, and caches the results.
* Supports out-of-source builds. Cleaning up is as simple as deleting the build directory.
The only drawback is that cmake needs to be installed to build the software from the source tarball (autotools don’t even have this advantage for VCS builds). This may have mattered ten years ago, but not in modern desktop systems. Building from source (including installing all dependencies besides cmake) is not a task for the typical end user to begin with – they are expected to use distribution packages. And for package maintainers, cmake is a blessing – very customizable and patchable. I say that as an Ubuntu developer. :)
I had a dev use it for one of the projects I participate in and oh my god what a damn pita. Debugging it is so hard when a certain module isn’t found. It’ll randomly fail on windows or mac or linux and work on windows. Argh.
Not saying that autotools is tons better, but that solution is far from perfect. Personally, I’m slowly getting by with waf…