Weekly Padgett

No. 0411 min read

Autotools in 2026: don't delete the damned build

Corkscrew's build machinery looks like clutter until somebody needs it. What's source, what ships, and why deleting generated files isn't a packaging plan.

A person holds a chain above a cardboard box containing a wooden workbench and metal vise.
File photoDramatization. No corkscrew was harmed.

You look at corkscrew[1]Ref. 1corkscrew en.wikipedia.org's build files in 2026 and wonder why one little C[2]Ref. 2C en.wikipedia.org program needs all this shit.

Corkscrew began in 2000. That's 26 years of accommodating other people's machines, which is a looooong time to assume everybody's computer looks like yours. The program is small, but it comes with configure.ac, configure, Makefile.am, Makefile.in, aclocal.m4, configuration templates, helper scripts.

Generated files can belong in a release tarball without having to live in Git[3]Ref. 3Git git-scm.com. A source checkout can reasonably require autoreconf and documented maintainer dependencies. The release tarball should normally bring the generated configure script and Makefile templates with it, along with the required helper files. That way configure-and-make doesn't require Autoconf[4]Ref. 4Autoconf gnu.org and Automake[5]Ref. 5Automake gnu.org on the user's machine. They came to build corkscrew, and I'd rather they didn't have to reconstruct my fucking laptop to do it.

Packagers need control over installation paths and compiler flags, too. I'd preserve prefix and DESTDIR, and respect the toolchain's flags instead of hardcoding my local installation. Cross-compilation needs actual testing, even with configure sitting right there.

If object files, binaries, config.log, configured Makefiles are tracked, I'd remove those machine-specific products from version control. I'd still check what belongs in the release archive before taking a broom to everything that looks generated.

The audit directly compiled ordinary and sanitizer binaries with GCC[6]Ref. 6GCC gcc.gnu.org. Its report also says the audit environment's process guard blocked the normal configure route. We hit an environment limitation there, so I can't use that result to say the repository's Autotools build is broken.

I can't say the build works from that result either. Native Autotools and other operating systems are explicitly unverified. We still have tests to run before I'd make those claims.

References

  1. corkscrew en.wikipedia.org ↩
  2. C en.wikipedia.org ↩
  3. Git git-scm.com ↩
  4. Autoconf gnu.org ↩
  5. Automake gnu.org ↩
  6. GCC gcc.gnu.org ↩
corkscrewautotoolscpackaging

More on this beat