Re: Support for options in valgrind-tests

[Bernd Becker]

Am 16.03.2011 22:52, schrieb Reuben Thomas:
> On 16 March 2011 21:22, Bernd Becker <address@hidden> 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