Murray's Blog

Non-Recursive Automake is the Best Alternative to Automake

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 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 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 The is still separate, but that’s fine with me.

Daniel Elstner changed Glom to use a single, removing 47 annoying little 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 files), autotools can be much nicer these days.

Exit mobile version