[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Making Autoconf 2.70 happen in the near future
From: |
Nicholas Clark |
Subject: |
Re: Making Autoconf 2.70 happen in the near future |
Date: |
Mon, 9 Mar 2020 14:35:38 -0600 |
Thanks for tackling this! Autoconf definitely needs a new release.
On Mon, Mar 9, 2020 at 2:23 PM Zack Weinberg <address@hidden> wrote:
> 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
>
>