[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Making Autoconf 2.70 happen in the near future

From: Zack Weinberg
Subject: Making Autoconf 2.70 happen in the near future
Date: Mon, 9 Mar 2020 16:22:49 -0400

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

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 (
 78: Configure re-execs self with CONFIG_SHELL       FAILED (

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

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

     - Debian unstable
     - CentOS 5 (about the oldest Linux anyone still uses AFAIK).

   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.

   gcc-9.2 (specifically gcc/configure)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]