Johannes Sixt wrote:
> In other tests, we check for prerequisite PERL, i.e., we are prepared
> that perl is not available. Shouldn't we do that here, too?
I think the tests assume there's a perl present even when the PERL
prereq isn't present already. E.g.:
nul_to_q () {
"$PERL_PATH" -pe 'y/\000/Q/'
}
So in practice the PERL prereq just means "NO_PERL wasn't set", or
in other words, "commands that use perl work". Maybe something
like the following would help?
Signed-off-by: Jonathan Nieder <jrnieder@xxxxxxxxx>
diff --git i/t/README w/t/README
index 2167125..54cd064 100644
--- i/t/README
+++ w/t/README
@@ -629,11 +629,20 @@ See the prereq argument to the test_* functions in the "Test harness
library" section above and the "test_have_prereq" function for how to
use these, and "test_set_prereq" for how to define your own.
- - PERL & PYTHON
+ - PYTHON
- Git wasn't compiled with NO_PERL=YesPlease or
- NO_PYTHON=YesPlease. Wrap any tests that need Perl or Python in
- these.
+ Git wasn't compiled with NO_PYTHON=YesPlease. Wrap any tests that
+ need Python with this.
+
+ - PERL
+
+ Git wasn't compiled with NO_PERL=YesPlease.
+
+ Even without the PERL prerequisite, tests can assume there is a
+ usable perl interpreter at $PERL_PATH, though it need not be
+ particularly modern.
+
+ Wrap tests for commands implemented in Perl with this.
- POSIXPERM
--
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