On Friday 01 April 2011, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Thu, Mar 31, 2011 at 02:54:36PM CEST:
> > At this point I'm not anymore sure this is just a testsuite-related issue
> > -- it seems like a genuine bug in Automake-generated remake rules.  WDYT?
> 
> No.  You were right originally.
>
I'll have to partly disagree with myself then...  The fact is that
the remake rules are quite unpredictable in this situation, and
what's worse, they might end up leaving the tree in an inconsistent
state (Makefile.in corresponds to both Makefile.am and configure.ac,
configure corresponds to configure.ac, but config.status doens't
correspond to configure and Makefile doesn't correspond to
Makefile.in; i.e., something gets updated in spite of the too-near
timestamp modification, but something else doesn't, all subject to
a race -- nasty!).  So this can be seen like an automake bug, or
at least a "limitation".

OTOH, such a bug is veeery unlikely to happen in real life, and
basically impossible to happen when make is being run by hand by
the developer (which I think is the only legitimate use case for
remake rules).  Also, I tried to fix the issue by modifiying
`lib/am/configure.am', but I realized that doing so would require
convoluted hacks with "touch" and "ls -t"/find" -- something IMHO
not worth doing to fix such a theoretical-only issue.

> The tests do need to $sleep.
> Please commit your patch with all the sleeps in it (to maint),
> but please also fix the wrong comments.
>
In the end, I'm OK with your proposal of adding a sleep to the
failing tests, but I'd also like to add an (xfailing) testcase
to expose the issue we have dig up with big efforts.  This is
what I've done in the attached patch.  OK for maint?

> My thinko was the following: given targets A -> B -> C, and A is out of
> date, after make updates A, it checks the time stamp again, even iff it
> knows it has decided to update A.  When that time stamp is the same as
> B, it won't update B.  This sequence shows the issue with high
> probability, the second 'make' often won't update B nor A again:
> 
> cat > Makefile <<EOF
> A: B; touch A
> B: C; touch B
> C: ; touch C
> EOF
> rm -f A B C; make; rm -f C; make
> 
> 
> Introducing sleeps in aclocal, autoconf, or automake would be a serious
> usability issue; I need to avoid falling into that misconception of mine
> again.
>
> Thanks for being persistent.
>
> Cheers,
> Ralf
> 

Thanks,
  Stefano