bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: valgrind-tests.m4


From: Ralf Wildenhues
Subject: Re: valgrind-tests.m4
Date: Mon, 17 May 2010 20:48:16 +0200
User-agent: Mutt/1.5.20 (2009-10-28)

* Simon Josefsson wrote on Mon, May 17, 2010 at 08:34:49PM CEST:
> Ralf Wildenhues writes:
> > * Simon Josefsson wrote on Mon, May 17, 2010 at 12:15:51PM CEST:
> >> I'm running self-tests under valgrind in several projects, and it seems
> >> like a general useful thing, so how about putting the macro for this in
> >> gnulib?
> >
> > Nice idea.  However, in general, tests might be executable programs, or
> > they might be shell or other scripts.  In the latter cases, putting
> > valgrind in TESTS_ENVIRONMENT would be at least a waste (you don't want
> > to check bash or perl).
> 
> It is a waste, but I've found that it is a small price to pay for
> valgrind test coverage.  Most of my projects doesn't mix too many shell
> scripts with too many C files in the same test directory, too, so it has
> been a marginal problem for me.

Good points.

> > With Automake 1.11's parallel-tests option, you have the possibility
> > to specify per-extension "compilers" for tests.
> >
> > Example:
> >   # .sh and .pl files are processed to .log files.
> >   TEST_EXTENSIONS = .sh .pl
> >   SH_LOG_COMPILER = bash -vx
> >   PL_LOG_COMPILER = perl -w -m strict
> >   TESTS = foo.sh bar.pl baz.sh
> 
> I don't see how to use this for running valgrind only on compiled .c
> files though.  Or are you suggesting inventing some "virtual" extension
> like .valgrind?  I'm not sure how to use that with the intended
> behaviour.

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.

> > Besides, TESTS_ENVIRONMENT really is meant as a variable for the
> > end-user rather than for the developer.
> 
> That isn't clear from the Automake documentation.  I suspect it is will
> be an uphill battle to try and fix that now.

Yes, indeed.  I should have made this clearer myself, sorry for not
thinking until the end: it would be nice to have a variable for the
end-user for this kind of thing.

Cheers,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]