> > > I wonder why the script doesn't use the "libtool --mode execute
> > > valgrind ..." approach
And also because when there is a bug, and the developer wants to debug
it using gdb, it's so much easier to run
gdb testcase
than
../libtool --mode=execute gdb testcase
> > Because we don't know where 'libtool' is. It could be in "..",
> > or in "../..", or in "../../..", and so on. It depends on the
> > package's directory structure.
>
> Thank you for the explanation. What about adding an option to run-test
> that tells it whether and where libtool is available?
That's extra complexity for the user — no thanks.
If you can find a way to make this work without adding complexity for
the user, and so that it's still reasonable reliable, that would be
fine with me. I mean, this will require
- finding the 'libtool' script (in one of the ancestor directories
of the build dir),
- detecting whether the test program to be run is a libtool wrapper
or not. (Also on Windows, where the libtool wrappers are executables,
not shell scripts.)
Feel free to propose a patch along these lines.
Bruno
