Hi, Ruud van Asseldonk wrote: > Jeff King wrote: >> I think NO_PERL has historically mostly meant "do not build or install >> perl scripts", and not "everything ought to run fine without perl". >> We've generally assumed you can run vanilla perl snippets from the >> command line the same way you'd run awk or sed (and the tests use this >> extensively, which is why you have to set PERL_PATH again to run them) We've definitely held the stance that NO_PERL doesn't mean to disable perl in tests. For casual use of perl in installed shell scripts, on the other hand, I suspect it was more that we forgot about them than that we had decided one way or another. :) [...] >> That said, most of those casual uses of perl in actual built scripts >> have gone away because the shell scripts have gone away. It looks like >> filter-branch, request-pull, and instaweb are the last holdouts. So >> maybe we should be treating NO_PERL as disabling those scripts, too. >> >> But then, should we be doing more to make it clear that those scripts >> are broken in a NO_PERL build? Who knows what happens if you run >> filter-branch without any perl available? > > My understanding was that NO_PERL controlled the runtime dependencies of > Git, and that the tests require Perl either way. Of course, without Perl any > scripts that depend on it can't be used, but like you say, there are few of > them left. I think it would make sense to not install those scripts when > NO_PERL=1. Should I make a patch to change that in the makefile? Yes, that sounds good to me. (The status quo also seems fine to me, but I like that this proposed approach would simplify things a little.) Thanks for working on this, and sorry for the earlier noise. Sincerely, Jonathan
