[Top][All Lists]

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

Re: [PATCH 5/5] Improved test silent5.test.

From: Stefano Lattarini
Subject: Re: [PATCH 5/5] Improved test silent5.test.
Date: Sun, 25 Apr 2010 17:13:11 +0200
User-agent: KMail/1.12.1 (Linux/2.6.30-2-686; KDE/4.3.4; i686; ; )

At Sunday 25 April 2010, Ralf Wildenhues <address@hidden> 
> > > >  grep mv stdout && Exit 1
> >
> > On the contrary, this seems too much strict, since it would fail
> > (with GNU make at least) if the automake source tree is placed in
> > a directory whose name contains the `mv' substring.
> Indeed.  Grepping for '^mv ' and ' mv ' should work though.
Or better again, we could strip off the `Entering/Leaving directory' 
lines outputted by GNU make.  WDYT?

> > The other silent*.test tests might have a similar problem too.
> > This should IMHO be addressed in a different patch series.  WDYT?
> Well, fix this first then have the new patches be correct right
> away. There is no point adding new code with known bugs.

> > Yes, more sanity checks wouldn't hurt I guess.
> > Should I amend the patch, or are you going to do that yourself?
> Feel free to amend.
Thanks.  My question is now moot anyway, as I have to amend all the 
patches for the GNU make "problem".

> > > > +  # Ensure a clean reconfiguration/rebuild.
> > > >    $MAKE clean
> > > >    $MAKE maintainer-clean
> > > > +  rm -f foo5.c foo6.[ch] sub/baz5.c sub/baz6.[ch]
> > >
> > > Wait, maintainer-clean should have removed all these files at
> > > this point (and some of the other lex/yacc tests should have
> > > this tested, too).  Does that not work for you?
> >
> > No, it works just fine; but in the (unlikely) case of a failure,
> > it could cause false positives (or even false negatives!) in
> > silent5.test.
> Well, but failure in case of a bug is a good thing, even if it is
> drive-by failure.  At least for semantics that are known to work.
OK, then I'll turn that `rm -f' into sanity checks with `test ! -f'.

> > Also, silent5.test is not supposed to test `maintainer-clean'
> > w.r.t. Lex/Yacc;
> No; but one general idea is that if you have a test for some
> specific semantic X, then in tests where you don't check for X,
> you may assume that generally, X just works.  OK?
OK.  But I'd feel safer to add a small sanity check, at least (in this 
case, the `test ! -f' cited above).


reply via email to

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