diff options
Diffstat (limited to 'gnulib/doc/valgrind-tests.texi')
| m--------- | gnulib | 0 | ||||
| -rw-r--r-- | gnulib/doc/valgrind-tests.texi | 38 |
2 files changed, 38 insertions, 0 deletions
diff --git a/gnulib b/gnulib deleted file mode 160000 -Subproject 443bc5ffcf7429e557f4a371b0661abe98ddbc1 diff --git a/gnulib/doc/valgrind-tests.texi b/gnulib/doc/valgrind-tests.texi new file mode 100644 index 0000000..ec37202 --- /dev/null +++ b/gnulib/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}. |