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
