People often complain that autotools is complicated. But the alternatives generally involve a learning curve, require large changes to existing projects, and don’t provide the features or the command-line interface that we’ve become used to with autotools, making life difficult for people building tarballs, and for distros’ packaging tools.
One of the biggest annoyances with traditional autotools has been the need for a Makefile.am file in each sub-directory, and the need to create (and link) non-installed convenience libraries in each one. That leads to lots of repetitive Makefile.am code. More code means more errors, less clarity, and difficult refactoring. I had forgotten how much I hated that about autotools when I first learned it.
One of the advantages often mentioned for alternatives such as cmake is the ability to define the build in just one text file. However, automake has supported the non-recursive way for a while. Now you can have just one top-level Makefile.am. The configure.ac is still separate, but that’s fine with me.
Daniel Elstner changed Glom to use a single Makefile.am, removing 47 annoying little Makefile.am files while preserving our special stuff for client-only, Maemo, and Windows builds, with no disruption for developers using the source from git or for people building from the tarball. It’s a great improvement that shows how attractive non-recursive automake can be. OK, so Daniel is an autotools expert, but I’d still rather move from autotools to non-recursive autotools than take the leap of faith needed to move from autotools to something completely different.
Apparently this is also more efficient, leading to faster build times, particularly when building in parallel with the -j option, with more correct dependencies. And there’s no need to mention those convenience libraries repeatedly to work around linker errors.
Together with autoreconf (replacing hand-built autogen.sh files), autotools can be much nicer these days.