forked from coreutils/gnulib
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathvalgrind-tests.texi
38 lines (30 loc) · 1.27 KB
/
valgrind-tests.texi
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
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}.