Re: "./t0001-init.sh --valgrind" is broken

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Duy Nguyen <pclouds@xxxxxxxxx> writes:

> On Thu, Mar 3, 2016 at 7:09 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
>> But it's probably better that we inject valgrind command
>> from inside bin-wrappers script, the same way we inject gdb, I think.
>
> For the best of both worlds, we should recreate bin-wrappers in
> test-lib.sh (i.e. the valgrind way), not in Makefile.
>
> Somewhat
> unrelated, but because topdir is getting really crowded and
> bin-wrappers is used for the test suite only, it should be moved
> inside t/ (i'm going to move all test-* to t/ too, later).

Weren't there people who pointed their bin-wrappers/ with $PATH to
test/use freshly baked Git before they convince themselves that they
want to install it?  Not building it from the top-level Makefile
and moving it to elsewhere would be two breakages for them.

I am not sure if that is a good idea.

Moving test-* sources out of the top-level is a good idea, and
placing test-* binaries somewhere other than the top-level is also a
good idea.  Just like t/lib-*.sh are helpers for tests, these are
also test helpers that happen to be written in C and compiled, so I
don't have a strong objection to make t/ the new location for
them--a different location (e.g. a new "test-helpers/" directory) is
also something I can go with.

Thanks.

In any case, are these two messages objections to J6t's fix, or are
you fine with the fix for 2.8-rc1 and merely raising ideas to redo
it in a different (i.e. your) way after 2.8 final, or are you
planning to do a fix in a different way for 2.8-rc1?
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]