[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More problems with `make -n' in automake-generated rules.
From: |
Stefano Lattarini |
Subject: |
Re: More problems with `make -n' in automake-generated rules. |
Date: |
Thu, 4 Nov 2010 21:50:08 +0100 |
User-agent: |
KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) |
On Thursday 04 November 2010, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Wed, Nov 03, 2010 at 06:48:16PM CET:
> > Hello Ralf. Again, just a couple of nits w.r.t. the test cases...
>
> Thanks; but I didn't mean to actually commit the second patch
> (just in case that wasn't clear).
I didn't get that, sorry. Anyway, why you don't want to commit this second
patch? While its usefulness is admittedly limited, being a little bit more
correct (even if only theoretically) wouldn't hurt IMHO. That said, please
notice that I have no strong opionion in this matter, so if you still prefer
not to commit the patch, by any means don't do that.
> That said, I'll reply to your comments inline.
>
> > On Monday 01 November 2010, Ralf Wildenhues wrote:
> > > --- /dev/null
> > > +++ b/tests/remakedry.test
> > > @@ -0,0 +1,82 @@
>
> > > +# Make sure GNU `make -n' doesn't trigger file updates when Makefile
> > > +# is out of date.
> > > +
> > > +# The subdir rebuilding rules rely on GNU make automatically updating
> > > +# the makefile and its prerequisites (through am--refresh).
> > > +required=GNUmake
> > Why requiring GNU make here? After all, if a make implementation does not
> > implement automatic Makefile-rebuild rules, it should trivially pass this
> > test, and if implements them, it makes sense to run this test on it too.
>
> But that requires me to think about the test again: was this really
> meant to test portable code? The rebuilding rules, esp. the am--refresh
> trick, rely on GNU make-specifics, and special-casing some test of it
> just because it may or may not happen to trigger the specifics doesn't
> seem robust. I don't want the next small patch to this test cause a
> failure for non-GNU make, a failure I'm really not interested in in this
> test.
>
> Does that make sense?
Yes. I'd still prefer to leave the GNU make requirement out, and add it
back when (and if) the necessity arise, but I can see your point too.
It's mostly a matter of tastes here, and since I have no strong opinion
on the issue, I'm OK with keeping GNU make in $required.
> > > +cat > Makefile.am <<'END'
> > > +SUBDIRS = sub
> > > +END
> > > +mkdir sub
> > > +: > sub/Makefile.am
> > > +
> > > +$ACLOCAL
> > > +$AUTOMAKE
> > > +$AUTOCONF
> > > +./configure
> > > +$MAKE
> > > +
> > > +# The toplevel rule is not problematic, as it is not recursive.
> > > +$sleep
> > > +touch Makefile.in
> > > +$sleep
> > Is this second sleep really needed? More instances below.
>
> Definitely is. I want Makefile to be strictly newer so that ls -1t
> is guaranteed to work not because of locale ordering but because of
> different time stamps.
Ah, right, I didn't think of that. Sorry.
> > > +$MAKE -n Makefile
> > > +test `ls -1t Makefile Makefile.in | sed 1q` = Makefile.in
> > Waht about using here the `is_newest' function provided by `tests/defs'?
>
> That would be a viable alternative that would also allow to ditch the
> second sleep, I guess (untested).
Nice.
> > > +# Go through contortions to avoid GNU make's first, internal "rebuild
> > > Makefile
> > > +# even in dry mode" cycle in the recursive (am--refresh) part.
> > > +(cd sub && $MAKE -n Makefile AM_MAKEFLAGS="-n Makefile")
> > I'd add a "|| Exit 1" here, just to be sure w.r.t. shells with buggy `set
> > -e'.
>
> What bug would you be trying to work around with it?
Not a specific bug, just a "potential" one (we already know how problematic
`set -e' can be). Also, notice that I've written "I would add", not "We
should add" ;-) so feel free to ignore the comment if it seems irrelevant
or overly paranoid to you.
> > One more intance below.
> > > +test `ls -1t sub/Makefile config.status | sed 1q` = config.status
> > > +(cd sub && $MAKE Makefile)
> > > +test `ls -1t sub/Makefile config.status | sed 1q` = sub/Makefile
> > > +
> > > +:
>
> Cheers,
> Ralf
>
Thanks,
Stefano
Re: More problems with `make -n' in automake-generated rules., Stefano Lattarini, 2010/11/03
Re: More problems with `make -n' in automake-generated rules., Stefano Lattarini, 2010/11/06