It has been eight years since the release of autoconf 2.69, there’s
been substantial improvements checked into the development trunk since
then, and the mailing list regularly gets requests for a new release.
It is my understanding that the most important roadblock to a new
release is a lack of developer time to do pre-release testing.
I have secured partial funding for my time to do this testing (thanks
to Keith Bostic). I’d like to discuss a plan; once we have developed
a concrete plan it will be easier for me to secure the rest of the
funding.
As a first step, I have cloned Git trunk and run the bundled testsuite
on my personal workstation, which runs Debian unstable. I find only a
few problems. I already patched two failures in ‘make -k syntax-check’.
More seriously, I see two failures in the primary testsuite when run
from within ‘make distcheck’ with /bin/sh being dash:
77: Forced re-exec with CONFIG_SHELL FAILED (m4sh.at:68)
78: Configure re-execs self with CONFIG_SHELL FAILED (m4sh.at:132)
These don’t happen when /bin/sh is bash, or when I just run ‘make check’,
and it’s not a matter of whether the source and build directory are
the same. I’m still investigating this, but I expect it’s something
relatively minor.
Now, obviously running the bundled testsuite on an up-to-date Debian
unstable box is not enough. I propose to do the following set of
tests:
- Run the bundled testsuite (plain ‘make check’ only, not ‘make
distcheck’) on the following OS and CPU combinations, all of which
are readily accessible to me:
aarch64-unknown-linux-gnu
armhf-unknown-linux-gnu
mips64-unknown-linux-gnu
powerpc-ibm-aix7.1.3.0
powerpc64-unknown-linux-gnu
sparc-sun-solaris2.11
x86_64-unknown-linux-gnu
- Debian unstable
- CentOS 5 (about the oldest Linux anyone still uses AFAIK).
x86_64-unknown-netbsd8.1
…
This list is shorter than I would like, particularly in the OS
department. I was hoping to get access to more “exotic”
environments via the GCC Compile Farm, but all of their more
interesting hosts are down as I write this. :-(
I will cheerfully add to the above anything that someone is willing
to give me an unprivileged ssh account on. (Please make sure
autoconf’s build dependencies are present and there’s plenty of
scratch space.) I don’t think setting up VMs or scrounging
physical hardware for more different OSes is a good use of my time
for this project, though.
- On the same set of computers, run the configure script that was
shipped in the tarball for the following list of packages, then
regenerate that script using autoconf development trunk, run it
again, and compare the new and old ‘config.status’. Investigate
any differences in the probe results.
coreutils-8.31
emacs-26.3
gcc-9.2 (specifically gcc/configure)
glib-2.63.6
python-3.8.2
I happen to know that these have particularly complicated configure
scripts. I will also cheerfully take suggestions for additional
packages to test in this manner.
I also have plans to go through the Debian, Fedora, SUSE, and Arch
Linux packages of autoconf and see if they apply any patches that
should really be upstreamed before a new release happens, and to go
through the relatively short list of bugs at
https://savannah.gnu.org/support/?group=autoconf and check for
critical issues.
I’ve seen people suggest that there is a backlog of patches that have
been submitted to this mailing list but not reviewed, but considering
that there’s already more git commits in between 2.69 and now than
there were between 2.68 and 2.69, I think it would be reasonable to
call 2.70 feature-complete at this point. That backlog can become the
meat of 2.71. :-)
I’d like to ask whether the community thinks there are any important
holes in this test plan, and whether there’s anything else that ought
to happen before we could proceed to make a release of 2.70. I think
this covers everything in the testing part of the release checklist in
$srcdir/HACKING, but I don’t know when that was last updated; there
could be something missing?
I need to get back to the people with the funding in the near future
with a detailed plan, so I would appreciate responses within the next
two weeks.
zw
