Ralf Wildenhues wrote: > * Stefano Lattarini wrote on Mon, Jun 20, 2011 at 10:22:28AM CEST: >> [Adding bug-grep, dropping bug-coreutils and automake-patches] > > re-adding the latter. > >> I've noticed that grep uses a definition of TESTS_ENVIRONMENT very similar >> to that of coreutils (the one we've just fixed), so it will break with >> oncoming automake too.
It can be simplified there, since none of grep's tests start with #!/usr/bin/perl. > That may be a sign that you may not want to actually break this code > with your proposed changes to Automake. I suspect that I am the only culprit ;-) That usage (putting such a shell function in TESTS_ENVIRONMENT) was admittedly rather twisted. > Put another way: it's a good idea to estimate the level of breakage > you're going to burden upon others (a couple of projects, dozens, > hundreds), the amount of work needed on their side to fix it, and the > amount of work (or possibility) it would take to change your code so > they are not broken in the first place. > > Also, of course, NEWS entries (and probably automake.texi entries) for > such changes are a good idea. > > One thing I've regularly done with new code that is not 100% backward > compatible is have a new Automake option for them. That is exactly why > there is a 'parallel-tests': it is not fully compatible with the simple > test driver, and requires work on behalf of developers using Automake. Your call, but don't do it for me. For things I maintain it'll be quick and easy to fix.
