Last week I’ve migrated the build system of LaTeXila from CMake to the Autotools. Here are the reasons.
The GNU Coding Standards
With CMake, some important make’s targets are missing, for example make uninstall. The main problem is that CMake doesn’t follow the GNU Coding Standards (GCS). The purposes of the GCS, with regard to a build system, is to make a program portable, easy to install, and consistent with the way other pieces of software are built and installed.
The GCS has several decades of experience, the standards are well established, and we can trust the GNU hackers for having well conceived them. Those that don’t follow them are devoted to reinvent the wheel: they will be faced sooner or later by the same problems already solved by the GCS and the Autotools…
Following standards is important both for users and packagers. If every software uses a different build system, with different options etc, it is a nightmare.
Available macros for GNOME applications
Another reason to use the Autotools, for a GNOME application, is to use the available macros: for the translations (intltool, ITS Tool), the documentation (yelp), the settings (gsettings), …
Creating a tarball
With the Autotools it is as simple as running make distcheck, and putting some files in EXTRA_DIST or prefixing Automake variables with the dist modifier.
It is more complicated with CMake. CPack can be used, but it is far from automatic. When reading the CPack documentation, I changed my mind and wrote a shell script instead.
Learning the Autotools
The Autotools are not as Autopain as people generally say. The learning curve is maybe steeper, but with a good book (“Autotools” by John Calcote), there is no reasons to be afraid.
That said, there are certainly problems in LaTeXila, so some tests before the stable release would be more than welcome 😉
You talk about portability, but most projects switch _from_ autotools because of portability. For example VLC is still stuck having to cross-compile to Windows because of autotools (and it’s not very easy to maintain and build). How exactly is autotools more portable than CMake?
As for the lack of support in Gnome for CMake that is really a Gnome problem, not a problem with CMake at all. And if the Gnome tools are in any way sane they should be dead easy to integrate with CMake.
For creating tarballs I’ve never used neither “make dist” or CPack, I prefer to use git-archive (creating tarballs isn’t really something that I expect my build system to do).
I’ve also found that the extremely steep learning curve of autotools sometimes turns developers away from projects (I know that I at least tend to think twice before contributing to a project using autotools, and I’ve seen others giving up during that early step as well). The build system is not something you should need to invest a lot of time to learn; it’s there to help you, not make things more complicated, IMHO.
The portability is more for UNIX variants. Building an Autotools project on Windows often requires Cygwin or MinGW. To build programs on Windows, the best is to use the Microsoft tools.
The aim of the Autotools is to be as simple as possible for the users of the software, at the expense of a bit more complexity for the maintainers (and thus a steeper learning curve).
In the Makefile.am files, the files that must be distributed in tarballs are (implicitly or explicitly) specified. When doing a “make distcheck” for creating a tarball, the Autotools also checks that the tarball is OK to release. It generates the script that the users need (configure, …), etc. For compiling a software from a tarball, the Autotools are not required!
With CMake it’s different, because users need CMake to compile from a tarball. And the contents of the git repository is almost the same as the contents of the tarball.