bst should not run autogen or autoreconf for autotools tarballs
autotools.yaml contains the following code:
autogen: |
export NOCONFIGURE=1;
if [ -e autogen ]; then ./autogen;
elif [ -e autogen.sh ]; then ./autogen.sh;
elif [ -e bootstrap ]; then ./bootstrap;
elif [ -e bootstrap.sh ]; then ./bootstrap.sh;
else autoreconf -ivf;
fi
This is good for builds from git, but it is broken for builds from tarballs. Running autogen/autoreconf blows away the generated files that are distributed with the tarball, which means we have no way to know whether the recommended workflow ./configure; make; sudo make install
actually works or not.
It caused two spurious failures for the GNOME 3.27.90 release, both of which were partially BuildStream's fault:
- gnome-documents's autogen.sh performs a git submodule update, which immediately fails when run outside of a git repo. autogen.sh really should not be in the dist at all, but it shouldn't matter, because BuildStream should not be executing it in the first place.
- gedit experienced a much more subtle build failure caused by BuildStream running autoreconf instead of gedit's autogen.sh script. If a module contains autogen.sh, then only autogen.sh should run autoreconf: build failures are to be expected if it is run automatically. gedit properly does not dist autogen.sh, because autogen.sh is only expected to be run from git, so BuildStream went ahead and ran autoreconf anyway, which broke the build.
The fix is for BuildStream to skip running autogen/bootstrap/autoreconf if configure already exists.
Lastly, note that GNOME could care less whether autoreconf runs successfully on the tarball. I know Debian has started to build all its packages that way, to make sure they build cleanly with the newest autofoo. But that's not interesting for GNOME. We want to know that the tarballs build together as released by GNOME, generated with whatever different versions of the autotools that happened to be installed on the maintainers' computers.