From e85c3f8fb0807bed4ce05f5b410d1e4d3929bc6e Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Thu, 20 May 2010 08:29:56 +0200 Subject: Add new module valgrind-tests. --- doc/valgrind-tests.texi | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 doc/valgrind-tests.texi (limited to 'doc/valgrind-tests.texi') diff --git a/doc/valgrind-tests.texi b/doc/valgrind-tests.texi new file mode 100644 index 0000000000..ec3720214a --- /dev/null +++ b/doc/valgrind-tests.texi @@ -0,0 +1,38 @@ +@node Running self-tests under valgrind +@section Running self-tests under valgrind + +For projects written in C or similar languages, running the self-tests +under Valgrind can reveal hard to find memory issues. The +@code{valgrind-tests} module searches for Valgrind and declares the +@code{VALGRIND} automake variable for use with automake's +@code{TESTS_ENVIRONMENT}. + +After importing the @code{valgrind-tests} module to your project, you +use it by adding the following to the @code{Makefile.am} that runs the +self-tests: + +@smallexample +TESTS_ENVIRONMENT = $(VALGRIND) +@end smallexample + +This will run all self-checks under valgrind. This can be wasteful if +you have many shell scripts or other non-binaries. Using the Automake +parallel-tests feature, this can be avoided by using the following +instead: + +@smallexample +AUTOMAKE_OPTIONS = parallel-tests +TEST_EXTENSIONS = .pl .sh +LOG_COMPILER = $(VALGRIND) +@end smallexample + +Then valgrind will only be used for the non-.sh and non-.pl tests. +However, this means that binaries invoked through scripts will not be +invoked under valgrind, which could be solved by adding the following: + +@smallexample +TESTS_ENVIRONMENT = VALGRIND='$(VALGRIND)' +@end smallexample + +And then modify the shell scripts to invoke the binary prefixed with +@code{$VALGRIND}. -- cgit v1.2.1