On Thu, Feb 27, 2020 at 12:40 PM Tadeus Prastowo <0x66726565@xxxxxxxxx> wrote: > Could someone try to checkout the Autoconf git repository at commit > 2ca0d57 (https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=2ca0d57) > and build it, please? > > I would like to know whether it is possible at all to build commit > 2ca0d57 out of the box or the commit is indeed committed in a broken > state. This commit does indeed appear to be broken. I get $ make ... autom4te_perllibdir='..'/lib AUTOM4TE_CFG='lib/autom4te.cfg' ./bin/autom4te -B '.'/lib -B '..'/lib --language M4sh --cache '' \ --melt ../bin/autoconf.as -o bin/autoconf.in Undefined subroutine &main::open_quote called at ./bin/autom4te line 261. make[1]: *** [Makefile:2020: bin/autoconf.in] Error 1 make[1]: Leaving directory '/home/zack/projects/gnu/autoconf/build' make: *** [Makefile:859: all] Error 2 Grepping the source tre21a3ac96e, I see many uses of a Perl function called `open_quote` but no definition. The fix for this appears to be in the very next commit (21a3ac968cef962fe9dadcd7a7058f169e836e36, "Port to new Autom4te::XFile API") which removes all of the uses of `open_quote`. `make` works fine for me as of that commit; there are a bunch of testsuite failures but I think they're unrelated problems. > Please note that the commit in question makes no change to any > ChangeLog file, and therefore, I rely on your kind help to make sense > of the committed change whose commit log is just the terse message: > "make fetch". "make fetch" updates a bunch of files that are maintained as part of other software but are also included into the autoconf source tree. One of those files is lib/Autom4te/FileUtils.pm, which *used* to define open_quote, but stopped doing so at some point in its own development. Commit 2ca0d57 brought in a version of FileUtils.pm that no longer defined open_quote, and then 21a3ac9 fixed up the callers in autoconf's source tree. Re your other thread, I do not know why automake's test suite has problems with autoconf after this point but not before. If you are bisecting, I would recommend you single-step forward in autoconf's version history until its own testsuite is fully green again for you, and then see if that also makes automake's testsuite happy. zw
