Hi Karl, At 2026-06-22T08:25:43-0600, Karl Berry wrote: > 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.
Yes. I inherited the the test framework from the previous groff maintainer, Bertrand Garrigues. > 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. I've resolved the problem by other means, per the below. > 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. I've since removed all tests for core files. That in turn eliminates the need to impose an ordering on the test scripts. https://savannah.gnu.org/bugs/?68204 Regards, Branden
signature.asc
Description: PGP signature
