[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: valgrind-tests.m4 is not compatible with libtool
From: |
Bruno Haible |
Subject: |
Re: valgrind-tests.m4 is not compatible with libtool |
Date: |
Tue, 30 Aug 2011 23:33:09 +0200 |
User-agent: |
KMail/1.13.6 (Linux/2.6.37.6-0.5-desktop; KDE/4.6.0; x86_64; ; ) |
Hi Vincent,
> valgrind-tests.texi says:
>
> 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}.
>
> but the libtool scripts cannot be modified that way.
I think this advice was written for those packages that install programs and
where the tests are shell scripts.
For example, if we have a test script that contains the lines
: ${HELLO=hello}
${HELLO} | tr -d '\r' >hello-test1.out
the advice is to modify it to:
: ${HELLO=$VALGRIND hello}
${HELLO} | tr -d '\r' >hello-test1.out
What I do in gettext is slightly different: I leave the test code unchanged
and instead augment TESTS_ENVIRONMENT:
TESTS_ENVIRONMENT = HELLO="$(VALGRIND) hello" EXEEXT='@EXEEXT@' ...
> ... do something to invoke
>
> libtool --mode=execute valgrind ...
Yes [1]. Here, if 'hello' is a libtool wrapper script, you can write
: ${HELLO=$LTVALGRIND hello}
in the script, or
TESTS_ENVIRONMENT = HELLO="$(LTVALGRIND) hello"
in the Makefile, with
LTVALGRIND = $(top_srcdir)/libtool --execute $(VALGRIND)
In packages that install libraries, and where the test programs are
simple executables, you can do two things:
a) Add a trivial launcher script around every test program, like
#!/bin/sh
exec ./test-foo
which by the previous explanations gets transformed into
#!/bin/sh
exec $(LTVALGRIND) ./test-foo
Or
b) Create a script 'valgrind-if-not-script' and set
TESTS_ENVIRONMENT = ... $(SHELL) $(srcdir)/valgrind-if-not-script
The script valgrind-if-not-script can do this: It extracts the first
non-option argument, which indicates the program to execute. If it's
a shell script and not a libtool wrapper, it is executed directly.
If it's a libtool wrapper, "$top_srcdir/libtool --execute valgrind"
is prepended and the resulting command line is executed. If it's not
a shell script, it's likely an executable, then prepend "valgrind"
and execute the resulting command.
Bruno
[1] http://lists.gnu.org/archive/html/bug-libtool/2010-05/msg00017.html
--
In memoriam Eberhard Finckh <http://en.wikipedia.org/wiki/Eberhard_Finckh>