Subject: Re: Automake patches for custom test drivers' support break coreutils testsuite

From: Stefano Lattarini <[email-masked]>
Date: Sat, 18 Jun 2011 10:23:42 +0200

On Saturday 18 June 2011, Jim Meyering wrote:
> Stefano Lattarini wrote:
> > [Adding bug-coreutils]
> >
> > Reference:
> >  <http://lists.gnu.org/archive/html/automake-patches/2011-06/msg00093.html>
> >
> > On Friday 17 June 2011, Ralf Wildenhues wrote:
> >> I generally like the direction this is taking.  The point of best
> >> separation between which code goes into Makefile.in and which into
> >> the driver scripts can be fine-tuned when we have more than one such
> >> script.
> >>
> >> Actually, yes, before deciding on this for real I really do want to see
> >> a nontrivial other driver script.  There is no point in hardcoding
> >> too much in several driver scripts if it all needs to be the same
> >> anyway.
> >>
> >> Please measure the time overhead your changes introduce into the current
> >> code, for a trivial testsuite (say, 50 tests running 'true'), and a
> >> nontrivial one like Automake's and one with faster tests.
> >>
> > I've tried the coreutils testsuite and ... Ouch!  That gets broken
> > by my patches :-(
> 
> Thank you for trying with coreutils before committing them.
>
Note that they'll be commmited to a dedicated branch before being merged
into master, so even if you're using the developement version of automake
with coreutils you should be safe even in case of other breakage (that
is, until the merge to master takes place).

> > That's due to the overly complex TESTS_ENVIRONMENT employed by
> > conreutils' tests/Makefile.am:
> >
> >  TESTS_ENVIRONMENT = \
> >   . $(srcdir)/lang-default;                     \
> >   tmp__=$${TMPDIR-/tmp};                        \
> >   test -d "$$tmp__" && test -w "$$tmp__" || tmp__=.;    \
> >   . $(srcdir)/envvar-check;                     \
> >   TMPDIR=$$tmp__; export TMPDIR;                \
> >   shell_or_perl_() {                            \
> >     if grep '^\#!/usr/bin/perl' "$$1" > /dev/null; then                 \
> >       if $(PERL) -e 'use warnings' > /dev/null 2>&1; then               \
> >         grep '^\#!/usr/bin/perl -T' "$$1" > /dev/null && T_=T || T_=;   \
> >         $(PERL) -w$$T_ -I$(srcdir) -MCoreutils -MCuSkip                 \
> >               -M"CuTmpdir qw($$f)" -- "$$1";    \
> >       else                                      \
> >         echo 1>&2 "$$tst: configure did not find a usable version of Perl," \
> ...
> >
> > In order to work with the upcoming new Automake testsuite harness, coreutils
> > have two possibilities:
> >  1. move the `shell_or_perl_' subroutine's functionality into a real acript,
> >     and define the LOG_COMPILER to point to it; or
> >  2. add a `.pl' extension to the perl test scripts, and define PL_LOG_COMPILER
> >     appropriately (might be a little tricky, considering the hops that the
> >     `shell_or_perl_' subroutine goes through in order to get the flags and
> >     imports right).
> 
> 1) sounds preferable.
>
But it has a serious drawback: the redirection `9>&2' placed at the end
of TESTS_ENVIRONMENT will be rendered useless by the final exec done
in the new `shell_or_perl' script (at least for with shells using the
`cloexec' flag on fds > 2); this will bring back the problems fixed by
commit `v8.12-82-g6b68745' :-(

So I now think we should go with solution (2).

> > I should have have an FSF copyright assignement in place for coreutils too,
> 
> Confirmed.
> 
> > so I can volounteer to write a fix for this situation, if no one wants to
> > beat me.
> 
> I  won't say "no" ;-)
> Thanks for volunteering.
> 

Regards,
  Stefano