t/Makefile: introduce TEST_SHELL_PATH
commit3f824e91c8480f7a236331096d2c4d969f013a83
authorJeff King <peff@peff.net>
Fri, 8 Dec 2017 10:47:22 +0000 (8 05:47 -0500)
committerJunio C Hamano <gitster@pobox.com>
Fri, 8 Dec 2017 17:03:38 +0000 (8 09:03 -0800)
tree0bd595a7d63978c0e6241069545480799d4dd1c7
parentf5ba2de6bc67082d01742ee6ce892fbcff7b97af
t/Makefile: introduce TEST_SHELL_PATH

You may want to run the test suite with a different shell
than you use to build Git. For instance, you may build with
SHELL_PATH=/bin/sh (because it's faster, or it's what you
expect to exist on systems where the build will be used) but
want to run the test suite with bash (e.g., since that
allows using "-x" reliably across the whole test suite).
There's currently no good way to do this.

You might think that doing two separate make invocations,
like:

  make &&
  make -C t SHELL_PATH=/bin/bash

would work. And it _almost_ does. The second make will see
our bash SHELL_PATH, and we'll use that to run the
individual test scripts (or tell prove to use it to do so).
So far so good.

But this breaks down when "--tee" or "--verbose-log" is
used. Those options cause the test script to actually
re-exec itself using $SHELL_PATH. But wait, wouldn't our
second make invocation have set SHELL_PATH correctly in the
environment?

Yes, but test-lib.sh sources GIT-BUILD-OPTIONS, which we
built during the first "make". And that overrides the
environment, giving us the original SHELL_PATH again.

Let's introduce a new variable that lets you specify a
specific shell to be run for the test scripts. Note that we
have to touch both the main and t/ Makefiles, since we have
to record it in GIT-BUILD-OPTIONS in one, and use it in the
latter.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makefile
t/Makefile
t/test-lib.sh