Re: [PATCH 1/2] tests: make test runner a script, not a shell function

[Stefano Lattarini]

On Monday 20 June 2011, 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.
> 
> That may be a sign that you may not want to actually break this code
> with your proposed changes to Automake.
>
In fact I don't mind breaking it, because the problem stemmed from an
unidiomatic (and bordering on uncorrect) usage of the TESTS_ENVIRONMENT
variable.  This is not to blame Jim or other coreutils maintainers,
because such an usage was there since before 'parallel-tests' and
LOG_COMPILER were available, so that "twisted usage" was truly required
in order to work around the Automake limiations.  But now that those
limitations have been lifted, I think the correct thing to do is just
go for a more idiomatic setup (and most importantly, Jim agreed with me
on this).

> 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.
>
I agree with this, and in fact I've posted a NEWS entry this afternoon;
the documentation, maybe with an example or two, can go in a follow-up
patch.
 
> 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.
>
This easily might become a maintainance nightmare though.  In this
case, I say we should help the users make a transition by adding good
explanations and examples to the manual, and stop there.

If you disagree, we can revisit the issue before the merge to master,
and add a compatibility layer, but I'd keep that for later.  This series
have already undergone too many respins IMHO.

> > Unfortunately, I don't have an FSF assignment
> > for grep, so someone else should fix that issue :-(
> 
> You can do minor fixes without assignments.
> (Of course, I don't maintain grep, so it's up to them.)
> 
> Cheers,
> Ralf
>