From: greened@obbligato.org (David A. Greene)
To: Thomas Rast <trast@inf.ethz.ch>
Cc: "David A. Greene" <dag@cray.com>, <git@vger.kernel.org>
Subject: Re: [PATCH 2/2] Support Out-Of-Tree Valgrind Tests
Date: Tue, 06 Mar 2012 08:40:42 -0600 [thread overview]
Message-ID: <87mx7tiyhh.fsf@smith.obbligato.org> (raw)
In-Reply-To: <878vje86cy.fsf@thomas.inf.ethz.ch> (Thomas Rast's message of "Tue, 6 Mar 2012 09:46:05 +0100")
Thomas Rast <trast@inf.ethz.ch> writes:
>>> I'm a bit curious: why isn't it enough to spell that path
>>> $GIT_BUILD_DIR/t/valgrind instead of making it fully configurable?
>>
>> For the same reason that TEST_DIRECTORY is different and unrelated from
>> GIT_BUILD_DIR. It's my understanding that GIT_BUILD_DIR could end up
>> being somewhere compeltely unrelated to where TOP_SRC/t/valgrind is.
>> At least that's why I introduced a new parameter.
>
> I'm just worried that for such a fringe use-case, the maintainer of the
> out-of-tree tests will never notice that he missed to customize *this*
> particular parameter. So I'd rather have it spelled in terms of the
> existing two (?).
I understand your concern. Perhaps it could be mitigated with some
"HOWTO" comments at the top of the script. I'm nervous about basing the
value on other variables because that's what limited the script to such
a narrow scope in the first place.
> Don't we, right now, get stuff as follows:
>
> item path
> --------------------------------------------
> test-lib.sh $TEST_DIRECTORY
Right now, yes, but it breaks for out-of-tree tests. In the out-of-tree
case, TEST_DIRECTORY doesn't contain test-lib.sh. For exmaple, in
t7900-subtree.sh, I do this:
. ../../../t/test-lib.sh
because TEST_DIRECTORY is set to some directory under contrib/subtree.
> git $GIT_BUILD_DIR/bin-wrappers
I think so.
> valgrind.sh $TEST_DIRECTORY/valgrind
That's what it is now and it's wrong for out-of-tree tests.
> git (with --valgrind) $TEST_DIRECTORY/valgrind/bin
Yep. This is ok.
> You are saying this must change to an entirely new path
>
> valgrind.sh $GIT_VALGRIND_TOOLS
> git (with --valgrind) $GIT_VALGRIND_TOOLS/bin
The first, yes. The second, no. We can leave that alone.
> but what's wrong with simply
>
> valgrind.sh $GIT_BUILD_DIR/t/valgrind
> git (with --valgrind) $TEST_DIRECTORY/valgrind/bin
These are two separate issues.
GIT_BUILD_DIR may not be anywhere within the source tree, right? If so,
t/valgrind may not have any relation whatsoever to GIT_BUILD_DIR. Hence
GIT_VALGRIND_TOOLS.
The second part is correct. test-lib.sh sets it up that way (~line 983)
and it works fine for out-of-tree tests.
> In the common case of t/, these just map to what we had before. In the
> out-of-tree case, we'd create valgrind/bin in the test directory for the
> *temporary* stuff, and still look for the wrapping valgrind.sh in the
> git tree.
Putting valgrind/bin in the test directory is fine. There's no change
there. It's this looking for the wrapping valgrind.sh that fails in the
current scheme. We cannot rely on GIT_BUILD_DIR to find it as noted
above.
-Dave
next prev parent reply other threads:[~2012-03-06 14:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-04 23:23 [PATCH 1/2] Allow Overriding GIT_BUILD_DIR greened
2012-03-04 23:23 ` [PATCH 2/2] Support Out-Of-Tree Valgrind Tests greened
2012-03-05 7:53 ` Thomas Rast
2012-03-05 18:11 ` David A. Greene
2012-03-06 8:46 ` Thomas Rast
2012-03-06 14:40 ` David A. Greene [this message]
2012-03-06 18:49 ` Junio C Hamano
2012-03-06 22:12 ` David A. Greene
2012-03-06 22:21 ` Junio C Hamano
2012-03-06 22:37 ` Junio C Hamano
2012-03-06 23:00 ` David A. Greene
2012-03-06 23:12 ` Junio C Hamano
2012-03-06 22:54 ` David A. Greene
2012-03-06 18:43 ` Junio C Hamano
2012-03-05 6:33 ` [PATCH 1/2] Allow Overriding GIT_BUILD_DIR Junio C Hamano
2012-03-05 18:10 ` David A. Greene
2012-03-05 20:08 ` Junio C Hamano
2012-03-06 14:21 ` David A. Greene
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mx7tiyhh.fsf@smith.obbligato.org \
--to=greened@obbligato.org \
--cc=dag@cray.com \
--cc=git@vger.kernel.org \
--cc=trast@inf.ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.