Hi,
David wrote:
If we're going to look at additional requirements imposed on
developers, I would suggest that imposition would bring far more
bang for the buck if it were a proper scripting language we can
write the tests in.
And it could probably handle at least some of what's in the accessory
test programs. On the other hand, using an LCD of POSIX has
advantages of portability and minimizing dependencies.
I think two things are being mixed by some. The tools imposed on a
developer, e.g. bison, is one thing. Perl used to require byacc(1)
IIRC. But as Ken says, to build nmh doesn't require that as the
parser's C source is shipped alongside the parser's yacc source.
But the tests are intended to be run by everyone that builds, whether a
developer or not, and it would be a shame to have nmh probably build and
appear to work on some unusual platform, but not be testable because it
doesn't have ready access to Python 3, say, plus some particular Python
packages.
So I'd be happy to stick with POSIX sh and friends with the odd small
C program to mop up the missing functionality, like we do now.
What's a bit tedious for all users of the tests, especially those like
developers who should run it a lot, are their serial nature. I see
Automake supports parallelising tests these days. That presumably would
help ‘make -sj check’ go more like the clappers.
https://www.gnu.org/software/automake/manual/html_node/Parallel-Test-Harness.html
--
Cheers, Ralph.