Hi Branden - returning to your question about serialization of Automake
tests from March 5:
https://lists.gnu.org/archive/html/automake/2026-03/msg00000.html
...
Was I using the documented serialization mechanism incorrectly? Why
didn't it work?
I doubt it can be this simple, but maybe add .sh to TEST_EXTENSIONS?
"Parallel Test Harness" has this (rather buried in the text) sentence:
https://www.gnu.org/software/automake/manual/html_node/Parallel-Test-Harness.html
...
please note that specifying such dependencies currently works only for
tests that end in one of the suffixes listed in @code{TEST_EXTENSIONS}.
When I look at the groff-1.24.1 tarball (what I had at hand), I see
./Makefile.in:2738:TEST_EXTENSIONS = @EXEEXT@ .test
but your tests are using .sh.
If it still fails to serialize correctly (I won't be surprised), can you
please try to make a small reproducible example? Debugging in something
the size of groff is difficult.
FWIW, I see that the two Automake tests t/parallel-tests-basics.sh
and t/parallel-tests-console-output.sh use this serialization technique.
So hopefully that means that it does basically work. --thanks, karl.
P.S. Regarding core dumps, allow me to echo Bob F's comment: on some
systems (at least, every RHEL system I've ever seen), core dumps are
disabled by default. And it's not trivial to enable them. ulimit -c
does not suffice. What happens to core dumps is determined by
/proc/sys/kernel/core_pattern and on RHEL, that is set to
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %d %F
and I gave up on figuring out what happens after that. Core files don't
end up in the current directory, though, that's for sure.
Bottom line, for reliable tests, I think you cannot rely on a core file
being generated.
