* Simon Josefsson wrote on Tue, May 18, 2010 at 09:36:44AM CEST: > Ralf Wildenhues writes: > > Well, one could prepend LOG_COMPILER (the default variable that doesn't > > go with any specified extension) or have the developer specify some > > other extension. Your macro could just set some variable that the > > package author prepends to the needed variables: one of the > > *LOG_COMPILER ones if parallel-tests is used, and TESTS_ENVIRONMENT > > otherwise. That would leave the most flexibility, but of course require > > a bit more work for the package author. > > How would this solve the problem of running valgrind on scripts? I'm > not familiar with the new parallel-tests stuff, but isn't LOG_COMPILER > applied for all extensions?
LOG_COMPILER is used for all tests which do not match any of the extensions given in TEST_EXTENSIONS. > I don't think I see what advantage your model would give compare to my > proposal. It gives efficiency, as already mentioned elsewhere; and also there is no need for a different proposal, it works with your proposed patch: You would be using something like TESTS_ENVIRONMENT = $(VALGRIND) and I would be using something like AUTOMAKE_OPTIONS = parallel-tests TEST_EXTENSIONS = .pl .sh LOG_COMPILER = $(VALGRIND) and maybe also use TESTS_ENVIRONMENT = VALGRIND='$(VALGRIND)' and then, in my shell script tests, prepend $VALGRIND to executables that are interesting. Cheers, Ralf
