GNU Automake 1.19 is out, the first release since 1.18.1 fifteen months ago. One new feature and a set of fixes, one of which closes a bug report filed in 2012.

The fix that matters most

make dist now fails when tar fails.

Previously it could succeed while producing a truncated archive. That is the worst possible behaviour for a release tool: your build reports success, you upload the tarball, and users discover the problem when it does not extract.

It is the same failure shape as the kernel data loss bug patched this month and the decompression bugs fixed in Gzip 1.15. A tool that fails loudly costs you an afternoon. A tool that fails quietly costs you a release.

The 14-year-old one

make dist-bzip2 dist-xz did not work. The uncompressed tarball was deleted after the first target completed, so the second had nothing to compress.

Anyone wanting two archive formats hit it, worked around it by running the targets separately, and moved on. The bug report has been open since 2012. 1.19 makes the intermediate tarball shared between goals so both compressions run against it.

That gap is a fair illustration of autotools’ position: still under every GNU project, still maintained, and no longer where attention goes.

The new feature

AM_OPTIONAL_AUTOMAKE, an autoconf macro that takes a list of distribution targets such as dist-xz, dist-zstd and dist-bzip3, and builds each archive only if the required compression tool is present, skipping the rest without failing.

This solves a genuine packaging irritation. Requesting dist-zstd on a build machine without zstd previously broke the build. Now the format is produced where possible and quietly omitted where not, which is what you want from a release target that lists several formats for convenience.

Smaller items

• COPYINGv2, COPYINGv3 and similar names are now recognised and distributed like a conventional COPYING file, which helps projects such as GNU GMP that ship multiple licence texts
• Better BusyBox tar detection, relevant on Alpine and embedded build environments where BusyBox provides the userland

Does this reach you

If you build from source tarballs, yes, indirectly. Autotools is the machinery behind ./configure && make && make install, and the make dist fix means fewer broken release archives arriving from upstream projects.

If you maintain an autotools project, take it for the make dist behaviour alone.

automake --version | head -1
autoconf --version | head -1

New projects overwhelmingly choose Meson or CMake, and that is a reasonable choice. Automake’s continued relevance is that a very large body of existing software uses it and will not be migrating, which makes a maintained release rather more valuable than the version number suggests.