Bruno Haible <br...@clisp.org> writes: > 5) Possibly it makes also sense to allow GNULIB_TOOL_IMPL to be set to > 'sh+py'. In this case the script will make a full copy of the destination > dir, run the shell implementation and the Python implementation on the > two destination dirs, separately, and compare the results (again, both > in terms of effects on the file system, as well as standard output). > And err out if they are different.
Generally I'm happy to hear about speedupds of gnulib-tool! The plan sounds fine. I think this step 5) is an important part to get maintainers try the new implementation, and report failures that needs to be looked into. If there was a small recipe I can follow to get a diff that can be reported back, I would run it for a bunch of projects that I contribute to. While a self-test suite for gnulib-tool would be nice, some real regression testing by attempting to build a bunch of real-world projects that rely on gnulib-tool may be simpler to realize. If there is a CI/CD that builds ~30 different real-world projects (perhaps at known-good commits) and compares the output against an earlier known-good build, for each modification to gnulib-tool in gnulib, that would give good confidence to any change to gnulib-tool. /Simon
signature.asc
Description: PGP signature
