Re: [RFC PATCH 1/5] add valgrind support in test scripts

[Jeff King <peff@xxxxxxxx>]

On Wed, Oct 22, 2008 at 05:14:52PM -0700, Junio C Hamano wrote:

> > I wonder if it would not be better to scrap the t/valgrind/ directory and 
> > regenerate it everytime you run a test manually; I'd use "ln" instead of 
> > "cp", and also parse command-list.txt to catch really all of them (even if 
> > a dashed form is used for a builtin by mistake).
> 
> Going one step further, I wonder if this approach can also be used to
> catch such a mistake.  Install a dashed form that records the fact that it
> was called when it shouldn't, and by whom.

I think that makes sense, though it is somewhat orthogonal to valgrind.
Do we want to always set up such a fake path? It could actually be even
simpler than a wrapper; just stop adding the build directory to the
PATH, and instead have a pseudo-installation directory with the bin and
exec-path directories set up appropriately. This would more closely
model the actual installation.

I think there are actually several classes of dashed commands we need to
differentiate:

 1. dashed commands which get installed in bin; these should be allowed

 2. dashed commands which don't get installed in bin; these should be
    flagged as an error

 3. dashed commands in exec-path which are stand-alone C programs. These
    should be run under valgrind.

 4. dashed commands in exec-path which are scripts. These do get run,
    but should not be run under valgrind.

 5. dashed commands in exec-path which are builtins. These should never
    get run by our test scripts, since they are "legacy" links for people
    who want to put the exec-path in their PATH

Right now we always point PATH at the build directory, which has
everything. So we can't easily differentiate between '1' and '2'. I used
the $(PROGRAMS) variable in the Makefile to find '3' (as opposed to '4'
and '5').

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html