Mercurial > gnulib
changeset 33049:0549e2f83dc6
Add new module valgrind-tests.
| author | Simon Josefsson <simon@josefsson.org> |
|---|---|
| date | Thu, 20 May 2010 08:29:56 +0200 |
| parents | a97622e4b28b |
| children | e9eed8932052 |
| files | ChangeLog doc/gnulib.texi doc/valgrind-tests.texi m4/valgrind-tests.m4 modules/valgrind-tests |
| diffstat | 5 files changed, 94 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- a/ChangeLog Wed May 19 23:30:18 2010 +0200 +++ b/ChangeLog Thu May 20 08:29:56 2010 +0200 @@ -1,3 +1,11 @@ +2010-05-17 Simon Josefsson <simon@josefsson.org> + + * modules/valgrind-tests: New file. + * m4/valgrind-tests.m4: New file. + * doc/valgrind-tests.texi: New file. + * doc/gnulib.texi (Running self-tests under valgrind): New + section. + 2010-05-19 Bruno Haible <bruno@clisp.org> Clean up dead code in recent commit.
--- a/doc/gnulib.texi Wed May 19 23:30:18 2010 +0200 +++ b/doc/gnulib.texi Thu May 20 08:29:56 2010 +0200 @@ -6416,6 +6416,7 @@ * func:: * warnings:: * manywarnings:: +* Running self-tests under valgrind:: @end menu @node alloca @@ -6514,6 +6515,8 @@ @include manywarnings.texi +@include valgrind-tests.texi + @node GNU Free Documentation License @appendix GNU Free Documentation License
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/valgrind-tests.texi Thu May 20 08:29:56 2010 +0200 @@ -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}.
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/m4/valgrind-tests.m4 Thu May 20 08:29:56 2010 +0200 @@ -0,0 +1,34 @@ +# valgrind-tests.m4 serial 1 +dnl Copyright (C) 2008, 2009, 2010 Free Software Foundation, Inc. +dnl This file is free software; the Free Software Foundation +dnl gives unlimited permission to copy and/or distribute it, +dnl with or without modifications, as long as this notice is preserved. + +dnl From Simon Josefsson + +# gl_VALGRIND_TESTS() +# ------------------- +# Check if valgrind is available, and set VALGRIND to it if available. +AC_DEFUN([gl_VALGRIND_TESTS], +[ + AC_ARG_ENABLE(valgrind-tests, + AS_HELP_STRING([--enable-valgrind-tests], + [run self tests under valgrind]), + [opt_valgrind_tests=$enableval], [opt_valgrind_tests=yes]) + + # Run self-tests under valgrind? + if test "$opt_valgrind_tests" = "yes" && test "$cross_compiling" = no; then + AC_CHECK_PROGS(VALGRIND, valgrind) + fi + + if test -n "$VALGRIND" && $VALGRIND -q true > /dev/null 2>&1; then + opt_valgrind_tests=yes + VALGRIND="$VALGRIND -q" + else + opt_valgrind_tests=no + VALGRIND= + fi + + AC_MSG_CHECKING([whether self tests are run under valgrind]) + AC_MSG_RESULT($opt_valgrind_tests) +])