Jeff King <peff@xxxxxxxx> writes:
> Do we want to also skip those? Do we want to place the burden on
> authors of the test suite to always check for NO_PERL whenever they use
> perl?
>
> The other option would be saying "we support building with NO_PERL, but
> not running the test suite".
>
> Thoughts?
Yes, no, and probably not.
Let me clarify the last "probably not" first, because it will be the
reason behind the first "Yes".
Saying "We support building but not testing" is like saying "we don't
support it", and honestly, we'd be better off leaving this patch out of
tree if that is what we are going to do. Even though I am not personally
very enthused about NO_PERL, the Makefile patch itself does not look too
bad, and if we can finish this with very limited injury to the overall
codebase, I wouldn't mind carrying the option in-tree.
Side note: by the way, what did you or Robin's patch do to
Documentation/cmd-list.perl and other bits of build infrastructure
that rely on Perl?
To solve the second "no" cleanly, I am wondering if we can do something
clever by defining $PERL to be used in t/t*.sh scripts. They should be
using configured PERL_PATH for running the tests _anyway_, even though I
see many hits from "git grep -e perl t/" right now.
But even if there isn't a room for doing something clever there, I think
the test prerequisite framework J6t did recently should be usable without
cluttering the test suite too much. That forces test authors to be aware
of NO_PERL, which is slightly yucky, but if it cannot be helped, I think
we can survive. We do the same for UTF8 and SYMLINKS already.
--
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
