Should we encourage or require ports to use autoreconf?

[Fred Wright]

On Fri, 21 Mar 2025, Ryan Carsten Schmidt wrote:

> 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.

I think doing this unnecessarily is a mistake.  See below.

> 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.

That still doesn't make it globally desirable.

> 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/

Yes, it may avoid that one particular form of malware, but in general, 
unnecessary rebuilding expands the attack surface to include more 
potential toolchain attacks.  This isn't purely theoretical:

 	https://wiki.c2.com/?TheKenThompsonHack
 	https://irreal.org/blog/?p=11754

> 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.

Another reason is that auto[re]conf is one of the worst tools on the 
planet when it comes to reproducibility.  In principle, rerunning autoconf 
on the same input *should* produce an *equivalent* 'configure', but in 
practice the result is usually so diff-proof that it's impractical to 
easily verify that.  So unless you're confident that you have good enough 
test coverage to catch unwanted 'configure' changes, it's safest just to 
leave the provided 'configure' alone (if it works).

Sometimes issues arise that require changing something in 'configure', 
which leads to the question of how best to handle that.  There are several 
options:

1) Patch 'configure' and avoid rerunning autoconf.  This is the simplest 
approach, but it's fragile, since anything that causes autoconf to rerun 
will wipe out the patches.

2) Patch the sources of 'configure' and rerun autoconf.  This is the 
conceptually cleanest approach, but it not only adds unnecessary build 
time but also adds the reproducibility/verifiability issue noted above.

3) Patch both and don't rerun autoconf.  This is in principle a reasonable 
belt-'n-suspenders approach, and may work fine for some projects, but some 
projects include a Makefile rule that reruns autoconf whenever 'configure' 
is considered to be outdated, thereby possibly being like #2 (perhaps 
opportunistically).

4) Patch both in separate patchfiles, and ensure that they run in the 
correct order so that 'configure' has a later mtime than its sources. 
This is in principle a good fix for #3, but only if mtimes have 
sufficiently high resolution on all relevant systems to ensure that the 
mtime of 'configure' is strictly greater than those of its sources. 
Since many systems only have one-second resolution on mtimes, this may not 
be reliable.

5) Patch both in separate patchfiles, ensure that they run in the correct 
order, and bump the mtime of 'configure' by one second.  This is a version 
of #4 which works reliably on any system whose mtime resolution is one 
second or better.  It's a bit kludgy in that the mtime of 'configure' may 
be in the future for up to one second, but it's doubtful that anything 
cares about that.  It's also questionable that any MacPorts build could 
progress from the patch phase to any build phase within one second as long 
as it remains written in Tcl. :-)

Approach #5 is what I currently use in the Ruby ports that need 
'configure' patches.

Fred Wright