Should we encourage or require ports to use autoreconf?

[Ryan Carsten Schmidt]

Software that uses an autotools build system typically ships with a generated configure script in the release tarball. For software releases that do not include this file, or if we want to extensively patch or modernize the configure script, we have the port use autoreconf to generated an up-to-date configure script. But for others, we typically have the port use the existing configure script. Should we perhaps change that practice and start using autoreconf even when the project provides a configure script? I think this might help us in the long run.

For example, with the release of Xcode 12 a few years ago we had to patch a zillion configure scripts to fix implicit function declaration errors. Many of these were not project-specific tests; they were standard tests that came from autoconf and which autoconf had already fixed years ago; these projects just hadn’t released new versions with configure scripts built with the fixed version of autoconf yet. Then, with the release of Apple Silicon Macs, we had to update a zillion config.guess files to identify those machines properly. More recently, we’ve had to patch a zillion configure scripts again to address implicit int errors. If we had switched to using autoreconf at the first sign of trouble, we would have saved ourselves the work of re-fixing many of the same ports over and over (in the case of tests that came from autoconf). Who knows what previously acceptable programming practice next year’s compilers will consider to be an error. If ports are already being autoreconf’d, all we have to do to fix all ports is to update the autoconf port to a version that fixes those built-in tests. Unique tests specific to one project might still need individual fixes of course.

One additional benefit to always using autoreconf is that we avoid the possibility that a pre-made configure script contains malware. This is an unlikely scenario, requiring the compromise of a project developer, but it did occur in xz-utils: https://tukaani.org/xz-backdoor/

One reason why we have typically avoided using autoreconf where possible is to save time. But on today’s computers the added time to run autoreconf is much less than it used to be.

Ancient projects may have build systems that cannot be processed correctly by modern autoconf. I’m fine with taking those on a case by case basis either trying to fix the build system so modern autoreconf can run, or using an older autoconf (we have ports for several versions), or using the old generated configure script.

If we do this, we must be careful not to introduce dependency cycles. Anything that is a recursive dependency of autoconf, automake, or libtool can’t be autoreconf’d. Bear in mind older systems sometimes have more dependencies (e.g. newer compilers).