[kazinator]

It's a bad practice commonly found in GNU projects, which results in an overcomplicated, inconvenient and unstable build system that will discourage future collaboration. Many of these projects are very old, two decades or more; they are living with ancient decisions made in a world of dozens of incompatible Unix forks.

One thing to do instead is to just write a ./configure script which detects what you need. In other words, be compatible at the invocation level. Make sure this is checked into the repo Anyone checking out any commit runs that, and that's it.

Someone who makes a tarball using git, out of a tagged release commit, should have a "release tarball".

A recent HN submission shows a ./configure system made from scratch using makefiles, which parallelizes the tests. That could be a good starting point for a C on Linux project today.

[amszmidt]

> A recent HN submission shows a ./configure system made from scratch using makefiles, which parallelizes the tests. That could be a good starting point for a C on Linux project today.

Not everything is C, or GNU/Linux. The example also misses much of the basic functionality that makes GNU autotools amazing.

The major benefit of GNU autotools is that it works well, specially for new platforms and cross compilation. If all you care about is your own system, a simple Makefile will do just fine. And with GNU autotools you can also pick to just use GNU autoconf .. or just GNU automake.

Having generated files in the release tarball is a good practise, why should users have to install a bunch of extra tools just to get PDF of the manual or other non-system specific files? It is not just build scripts all over the place, installing TeX Live just to get a PDF manual of something is super annoying.

Writing your own ./configure that works remotely as something users would expect is non-trivial, and complicated -- we did that 30 years ago before GNU autoconf. There is a reason why we stopped doing that ...

I'd go so far to think that GNU autotools is the most sensible build system out there...

[kazinator]

> Not everything is C,

AutoTools are squarely oriented toward C, though.

If you're not using C or C++, you're probably not using AutoTools.

(I think I might have seen someone's purely Python or shell script project using Autoconf, but that was just ridiculously unnecessary.)

> Having generated files in the release tarball is a good practise

Without a doubt, it is a good idea to ship certain generated files in a source code distribution. For instance, if we ship a generated y.tab.c file, the user doesn't have to have a Yacc program (let alone the exact version of the one we would like them to use).

What's not good practice is that anything is different in the release tarball compared to the git commit it was made from.

"Release tarball" itself a configuration management antipattern. We are a good two decades past tarballs now. A tarball should only be a convenience for people who don't need a git clone.

Every generated thing that a downstream user might need should be in version control, and updated whenever its prerequisites change. This is a special exception to the general rule that only primary objects should be in version control. Secondary objects for which downstream users don't have generation tools should also be in version control.