automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [BIKESHEDDING PATCH] Generated tests are now just a thin layer aroun


From: Stefano Lattarini
Subject: Re: [BIKESHEDDING PATCH] Generated tests are now just a thin layer around other tests.
Date: Sun, 23 May 2010 17:29:05 +0200
User-agent: KMail/1.12.1 (Linux/2.6.30-2-686; KDE/4.3.4; i686; ; )

At Sunday 23 May 2010, Ralf Wildenhues <address@hidden> wrote:
> > Good catch.  Note that my patch on the sepration of instspc.test
> > has this same problem too.
> 
> OK, good to know.  I haven't looked at the instspc patches yet.
Then I'll amend it after this problem will have been solved.

> > However, I think that a better way to resolve this problem would
> > be to make @abs_srcdir@ substituted in defs.in (dropping the
> > computation of $srcdir), and make defs.in robust w.r.t. multiple
> > inclusion; then the generated test files could do simply:
> >
> > #!/bin/sh
> > parallel_tests=yes
> > . ./defs.in
> > . $testsrcdir/INPUT.test
> 
> Hmm, yes, maybe.  This needs quoting for spaces in abs_srcdir.
Yes.  I'm writing a patch now, it should take care of all the details.
> Also, doesn't it remove the automatic 'set -x' when we detect
> scripts run manually?
I don't understand.  What is that removes 'set -x'?

> > > diff --git a/tests/Makefile.am b/tests/Makefile.am
> > > index cff34c5..bbeb2cb 100644
> > > --- a/tests/Makefile.am
> > > +++ b/tests/Makefile.am
> > > @@ -34,7 +34,11 @@ $(parallel_tests): Makefile.am
> > >   { echo '#!/bin/sh'; \
> > >     echo '# DO NOT EDIT! GENERATED AUTOMATICALLY!'; \
> > >     echo 'parallel_tests=yes'; \
> > > -   echo ". '$(srcdir)/$$input'"; \
> > > +   echo "if test -f ./$$input; then"; \
> > > +   echo "  . ./$$input"; \
> > > +   echo 'else'; \
> > > +   echo "  . \$$srcdir/$$input"; \
> >
> > ... this prevent the test script from working when run from the
> > command line in a VPATH build -- with an error like:
> >   ./check-p.test: line 7: /check.test: No such file or directory
> 
> Yeah, that's bad.  One alternative would be to generate *-p.test in
>  the source tree right away;
But that wouldn't solve our problem in a VPATH build... or am I 
missing something?
>  after all, 'make dist' will have them end up there in an
>  extracted tarball anyway.
On the other hand, this is a good reason to put the generated tests in 
the $srcdir (after all, they are distributed); however, this issue is 
ortoghonal to the one we are discussing.

Regards,
   Stefano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]