At Sunday 25 April 2010, Ralf Wildenhues <ralf.wildenh...@gmx.de>
wrote:
> > > > 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.
Agreed.
> > 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).
Regards,
Stefano
