Jeff King wrote: > Hmm. I don't think that technique gives complete coverage. There are > other scripts (e.g., filter-branch) that call a bare "perl" (not > PERL_PATH), which presumably pass the tests even though they'd break in > a real-world system without perl. In fact, many scripts used to do this > before fcb06a8d54 (use @@PERL@@ in built scripts, 2013-10-28). I don't > think the effects on NO_PERL were really considered there; it was more > about finding the right perl. Oh! Thanks for looking deeper. > 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). Right. PERL_PATH and NO_PERL are more orthogonal than I had thought. So this is Not-Reviewed-by: Jonathan Nieder <jrnieder@xxxxxxxxx> --- the patch shouldn't be applied as is. > 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? Agreed: if we want to follow this approach, we should install stubs in place of those scripts when NO_PERL=YesPlease. Will say more about this in a separate reply. Thanks for catching it, Jonathan
