bug#81285: automake 1.18.1 test status on NetBSD 11.99.6/x86-64

Hi Thomas,

    instead of /usr/pkg/bin/gm4

I noticed that gm4 was getting called, but I didn't investigate much.

    Reading t/README made me try

Good sleuthing. There is also some info about running tests in the
top-level ./HACKING file.

Anyway, I'm not sure why runtest is failing for you. Have to look into
that separately. Meanwhile:

    # env TESTS="t/aclocal-autoconf-version-check.sh" make -e -k check

Yes, I've always run single tests through make. I can't explain why it
succeeded when running directly but failed as part of the general make
check. Sigh. Maybe try more of the failing tests and see if they also
succeed when run individually? I wonder about that "make -e". What if
you leave out the -e? That is, could something in the environment be
affecting things? Shouldn't, but ...

But, I have always used GNU make. Are you using BSD make (not
surprisingly :)?  I wonder if that explains all the bugs. Can you easily
try running the whole thing (starting with configure) with GNU make?

What I typically do is this (with GNU make):

  tst=aclocal-autoconf-version-check # or whatever t/*.sh
  keep=keep_testdirs=yes
  unsilence="AM_V_GEN= AM_V_at= V=1"
  noprintdir=--no-print-dir
  make VERBOSE=1 $noprintdir check TESTS=t/$tst.sh $keep $unsilence

The verbosity stuff makes automake be a bit more loquacious about what's
going on. The keep_testdirs makes it possible to
  cd t/$tst.dir
afterwards to see what's there. --no-print-dir (gmake only) is just
because I get tired of looking at the long chain of directory changes,
which do nothing for me.

When a test is failing in one circumstances and succeeding in another,
another trick I've sometimes used is to put an "exit 33" (or whatever)
at the end of the test, so that then the successful one will also dump
out the whole shell expansion and they can be compared.

Another idea, along completely different lines, is to point
claude/codex/whatever to your original report
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=81285) and ask if it can
give any clues as to what caused the failures. I've never done it
myself, but from what I've seen friends do, it seems like this is the
sort of thing LLMs might be good for.

I hope this is enough to make some progress ... --thanks, karl.