Am 16.03.2011 22:52, schrieb Reuben Thomas: > On 16 March 2011 21:22, Bernd Becker <[email protected]> wrote: >> Hi Thomas, >> >> Am 12.03.2011 18:41, schrieb Reuben Thomas: >>> Another day, another nice surprise from gnulib: it supports valgrind, >>> so I can remove my own code for that...only, no I can't, because I add >>> options (I add --error-exitcode=1 --leak-check=full). >>> >>> So, two alternative suggestions: >>> >>> 1. Agree that these options are must-haves (rationale: one's code >>> shouldn't leak memory, so turn on full leak checking to make sure; >>> tests that cause valgrind errors should count as failures). >> I would like the possibility to switch off "--error-exitcode=1" option >> such that it's possible to run a whole test suite during lunch-break >> checking the log-file afterwards. > But you can do this anyway: when a test fails it doesn't stop the test > run. (At least, not with automake's built in test rules, which report > the number of successes and failures at the end.) > yes, that's true if all tests are in one directory. Having a project with multiple sub-dirs holding tests the test run will stop after the first subdir with a failed test. But then make -i seems to be good.
>> I would suggest an influencing variable, which would result in a changed >> configure-run like: >> >> VALGRIND_OPTIONS=<options for this test run> ./configure ... > That's fine for influencing an entire test suite. I was thinking of > the case where you always want to alter valgrind's behavior for a > particular test case. > > Sounds like what's needed is a pair of variables that works like > CPPFLAGS/AM_CPPFLAGS. > how about an approach passing a variable into make like test_a_VALGRIND_OPTIONS=foo make check then you save the re-configure run + Makefile.am editing
