On 2011-09-07 13:22:09 +0200, Simon Josefsson wrote:
> Vincent, Bruno, if you can think of ways of making the situation better
> even for projects that use libtool wrappers of self-tests, then let's do
> that too -- I'm just mentioning that -no-install may be a solution.
Yes, I think this should b
Another solution is to put
AM_LDFLAGS = -no-install
in the Makefile.am of your self-test directory, so libtool will not
build wrappers for them.
I have not seen any negative effects of doing this, and it helps
significantly with issues like this (especially for running gdb).
Vincent, Bruno, if
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 s
Hi Ben,
* Ben Pfaff wrote on Thu, May 20, 2010 at 09:11:58PM CEST:
> Ralf Wildenhues writes:
>
> > That's quite bad. Maybe libtool should have a way to use valgrind only
> > on the "interesting" executable, not the rest of any wrappers, or the
> > libtool script, for efficiency reasons.
>
> To
Ralf Wildenhues writes:
> That's quite bad. Maybe libtool should have a way to use valgrind only
> on the "interesting" executable, not the rest of any wrappers, or the
> libtool script, for efficiency reasons.
To run valgrind on a program that might use libtool, I just use
libtool --mo
[ adding bug-libtool ]
* Bruno Haible wrote on Wed, May 19, 2010 at 11:12:08AM CEST:
> Simon Josefsson wrote:
> > my patch invokes valgrind with -q so that it does not
> > output anything, unless there are errors, of course
>
> Oh, I see. Indeed.
>
> But it spends a lot of time in "make check",
Ralf Wildenhues writes:
> Hi Simon,
>
> I like this patch, with one small nit:
>
> * Simon Josefsson wrote on Wed, May 19, 2010 at 08:41:29AM CEST:
>> +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
I pushed a small followup-patch to make things work.
/Simon
>From 5c9bee128e78e2513fef8955c4c0cd27fcff4c54 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Thu, 20 May 2010 08:37:18 +0200
Subject: [PATCH] modules/valgrind-tests (configure.ac): Invoke
gl_VALGRIND_TESTS.
---
ChangeLog
Bruno Haible writes:
> The approach I use in GNU gettext is similar: Makefile.am has this:
>
> # For debugging memory leaks and memory allocation bugs.
> # You should build with --disable-shared when using valgrind.
> CHECKER =
> #CHECKER = valgrind --tool=memcheck
> --suppressions=$(srcdir)/../
Hi Simon,
I like this patch, with one small nit:
* Simon Josefsson wrote on Wed, May 19, 2010 at 08:41:29AM CEST:
> +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
Simon Josefsson wrote:
> my patch invokes valgrind with -q so that it does not
> output anything, unless there are errors, of course
Oh, I see. Indeed.
But it spends a lot of time in "make check", and does not exploit the full
information that valgrind could provide. For a test, I ran "make check
Ralf Wildenhues writes:
> * Simon Josefsson wrote on Tue, May 18, 2010 at 09:36:44AM CEST:
>> Ralf Wildenhues writes:
>> > Well, one could prepend LOG_COMPILER (the default variable that doesn't
>> > go with any specified extension) or have the developer specify some
>> > other extension. Your m
* Simon Josefsson wrote on Tue, May 18, 2010 at 09:36:44AM CEST:
> Ralf Wildenhues writes:
> > Well, one could prepend LOG_COMPILER (the default variable that doesn't
> > go with any specified extension) or have the developer specify some
> > other extension. Your macro could just set some variabl
Bruno Haible writes:
> The approach I use in GNU gettext is similar: Makefile.am has this:
>
> # For debugging memory leaks and memory allocation bugs.
> # You should build with --disable-shared when using valgrind.
> CHECKER =
> #CHECKER = valgrind --tool=memcheck
> --suppressions=$(srcdir)/../
Bruno Haible writes:
> Ralf Wildenhues wrote:
>> > However, in general, tests might be executable programs, or
>> > they might be shell or other scripts. In the latter cases, putting
>> > valgrind in TESTS_ENVIRONMENT would be at least a waste (you don't want
>> > to check bash or perl).
>
> Not
Ralf Wildenhues wrote:
> > However, in general, tests might be executable programs, or
> > they might be shell or other scripts. In the latter cases, putting
> > valgrind in TESTS_ENVIRONMENT would be at least a waste (you don't want
> > to check bash or perl).
Not only it's a waste. It also prod
Ben Pfaff wrote:
> * In GNU PSPP, which mostly uses the built-in Automake
> test framework, the invocations of the test programs
> are all through shell scripts. Each invocation of a
> test program is preceded by $SUPERVISOR,
> e.g. "$SUPERVISOR pspp
Ralf Wildenhues writes:
>> > With Automake 1.11's parallel-tests option, you have the possibility
>> > to specify per-extension "compilers" for tests.
>> >
>> > Example:
>> > # .sh and .pl files are processed to .log files.
>> > TEST_EXTENSIONS = .sh .pl
>> > SH_LOG_COMPILER = bash -vx
>> >
Ben Pfaff writes:
> Simon Josefsson writes:
>
>> Ben Pfaff writes:
>>
>>> Simon Josefsson writes:
>>>
I'm running self-tests under valgrind in several projects, and it seems
like a general useful thing, so how about putting the macro for this in
gnulib?
>>>
>>> It looks like thi
Simon Josefsson writes:
> Ben Pfaff writes:
>
>> Simon Josefsson writes:
>>
>>> I'm running self-tests under valgrind in several projects, and it seems
>>> like a general useful thing, so how about putting the macro for this in
>>> gnulib?
>>
>> It looks like this implementation requires rerunn
* Simon Josefsson wrote on Mon, May 17, 2010 at 08:34:49PM CEST:
> Ralf Wildenhues writes:
> > * Simon Josefsson wrote on Mon, May 17, 2010 at 12:15:51PM CEST:
> >> I'm running self-tests under valgrind in several projects, and it seems
> >> like a general useful thing, so how about putting the mac
Ralf Wildenhues writes:
> Hi Simon,
>
> * Simon Josefsson wrote on Mon, May 17, 2010 at 12:15:51PM CEST:
>> I'm running self-tests under valgrind in several projects, and it seems
>> like a general useful thing, so how about putting the macro for this in
>> gnulib?
>
> Nice idea. However, in gen
Ben Pfaff writes:
> Simon Josefsson writes:
>
>> I'm running self-tests under valgrind in several projects, and it seems
>> like a general useful thing, so how about putting the macro for this in
>> gnulib?
>
> It looks like this implementation requires rerunning "configure"
> to run tests under
Hi Simon,
* Simon Josefsson wrote on Mon, May 17, 2010 at 12:15:51PM CEST:
> I'm running self-tests under valgrind in several projects, and it seems
> like a general useful thing, so how about putting the macro for this in
> gnulib?
Nice idea. However, in general, tests might be executable progr
Simon Josefsson writes:
> I'm running self-tests under valgrind in several projects, and it seems
> like a general useful thing, so how about putting the macro for this in
> gnulib?
It looks like this implementation requires rerunning "configure"
to run tests under valgrind. If that's right, it
25 matches
Mail list logo
