All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org, Lars Schneider <larsxschneider@gmail.com>,
	Stefan Beller <sbeller@google.com>
Subject: Re: [PATCH v2 4/4] t/Makefile: introduce TEST_SHELL_PATH
Date: Sun, 10 Dec 2017 09:23:09 -0500	[thread overview]
Message-ID: <20171210142309.GA19453@sigill.intra.peff.net> (raw)
In-Reply-To: <alpine.DEB.2.21.1.1712091443560.4318@virtualbox>

On Sat, Dec 09, 2017 at 02:44:44PM +0100, Johannes Schindelin wrote:

> > > ... and we could simply see whether the environment variable
> > > TEST_SHELL_PATH (which we would set in t/Makefile from the passed-in
> > > SHELL_PATH) is set, and override it again.
> > > 
> > > I still think we can do without recording test-phase details in the
> > > build-phase (which may, or may not, know what the test-phase wants to do).
> > > 
> > > In other words, I believe that we can make the invocation you mentioned
> > > above work, by touching only t/Makefile (to pass SHELL_PATH as
> > > TEST_SHELL_PATH) and t/test-lib.sh (to override the SHELL_PATH from
> > > GIT-BUILD-OPTIONS with TEST_SHELL_PATH, if set).
> > 
> > We could do that, but it makes TEST_SHELL_PATH inconsistent with all of
> > the other config.mak variables.
> 
> It is already inconsistent with the other variables because its scope is
> the "test" phase, not the "build" phase.

I'm not sure that's true. Look at what already goes into
GIT-BUILD-OPTIONS: TEST_OUTPUT_DIRECTORY, GIT_TEST_CMP, GIT_PERF_*, etc.

Interestingly, many of those do something like this in the Makefile:

  ifdef GIT_TEST_CMP
	@echo GIT_TEST_OPTS=... >>$@+
  endif

which seems utterly confusing to me. Because it means that if you build
with those options set, then they will override anything in the
environment. But if you don't, then you _may_ override them in the
environment. In other words:

  make
  cd t
  GIT_TEST_CMP=foo ./t0000-*

will respect that variable. But:

  make GIT_TEST_CMP=foo
  cd t
  GIT_TEST_CMP=bar ./t0000-*

will not. Which seems weird.  But I guess we could follow that pattern
with TEST_SHELL_PATH.

-Peff

  reply	other threads:[~2017-12-10 14:23 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-19 21:01 [PATCH 0/3] making test-suite tracing more useful Jeff King
2017-10-19 21:03 ` [PATCH 1/3] test-lib: silence "-x" cleanup under bash Jeff King
2017-10-19 21:07 ` [PATCH 2/3] t5615: avoid re-using descriptor 4 Jeff King
2017-10-19 21:46   ` Stefan Beller
2017-10-19 23:23     ` Jeff King
2017-10-20  5:50       ` Jeff King
2017-10-20 21:27         ` Stefan Beller
2017-10-20 22:46           ` Jeff King
2017-10-21  0:19             ` Simon Ruderich
2017-10-21  2:02               ` Junio C Hamano
2017-10-21  3:23               ` Jeff King
2017-10-19 21:08 ` [PATCH 3/3] test-lib: make "-x" work with "--verbose-log" Jeff King
2017-10-23 10:56   ` Johannes Schindelin
2017-10-20 22:53 ` [PATCH 4/3] t/Makefile: introduce TEST_SHELL_PATH Jeff King
2017-10-20 23:50   ` SZEDER Gábor
2017-10-21  3:12     ` Jeff King
2017-10-23 11:01   ` Johannes Schindelin
2017-10-24  1:31     ` Jeff King
2017-10-25 21:35       ` Johannes Schindelin
2017-10-25 21:50         ` Jeff King
2017-10-27 14:26           ` Johannes Schindelin
2017-10-23 11:04 ` [PATCH 0/3] making test-suite tracing more useful Johannes Schindelin
2017-10-24  1:32   ` Jeff King
2017-12-08 10:46 ` [PATCH v2 0/4] " Jeff King
2017-12-08 10:47   ` [PATCH v2 1/4] test-lib: silence "-x" cleanup under bash Jeff King
2017-12-08 10:47   ` [PATCH v2 2/4] t5615: avoid re-using descriptor 4 Jeff King
2017-12-08 10:47   ` [PATCH v2 3/4] test-lib: make "-x" work with "--verbose-log" Jeff King
2017-12-08 10:47   ` [PATCH v2 4/4] t/Makefile: introduce TEST_SHELL_PATH Jeff King
2017-12-08 15:08     ` Johannes Schindelin
2017-12-08 22:00       ` Jeff King
2017-12-09 13:44         ` Johannes Schindelin
2017-12-10 14:23           ` Jeff King [this message]
2017-12-11 20:37             ` Junio C Hamano
2017-12-15 10:41               ` Jeff King
2017-12-15 16:58                 ` Junio C Hamano
2017-12-21  9:47                   ` Jeff King

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=20171210142309.GA19453@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=larsxschneider@gmail.com \
    --cc=sbeller@google.com \
    /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.