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.