Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories

[Stefano Lattarini]

On Tuesday 21 June 2011, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Tue, Jun 21, 2011 at 10:43:06PM CEST:
> > On Tuesday 21 June 2011, Ralf Wildenhues wrote:
> > > * Stefano Lattarini wrote on Sun, May 29, 2011 at 04:26:36PM CEST:
> > > > --- a/lib/am/configure.am
> > > > +++ b/lib/am/configure.am
> > > > @@ -22,7 +22,7 @@
> > > >  ## %MAKEFILE% is updated before considering the am--refresh target.
> > > 
> > > The comment up here ^^^ needs to be updated in this particular patch.
> > >
> > OK will fix in a follow-up patch (probably tomorrow).  The above comment
> > holds only for GNU make BTW (and correctly states so), so I think I'll
> > just remove it.
> 
> No.
>
Why not?  That comment used to explain the reasons for a non obvious part of
the code, but now we've changed that part back the "obvious form/behaviour",
so the comment is not needed anymore.

> > > I have an objection: you guys manage to discuss a log entry for half a
> > > dozen mails, yet never address the most interesting question the log
> > > entries throw up: "what is that 'silly' limitation" that non-GNU makes
> > > have here?
> > >
> > It's not a silly limitation of those make implementations at all -- it is
> > was silly limitation in automake!  Automake-generated code was relying on
> > GNU make semantics even when POSIX semantics would have worked just as well.
> 
> This is not true, IIRC.
>
Why not?  Honest question, as my tests seem to prove otherwise (but then,
they might be incomplete).

> > And IMHO ChangeLog entry describes this silly limitation in detail (albeit
> > probably with suboptimal wording):
> > 
> >  ``... the limitation [was] that, with non-GNU make implementations,
> >     "make Makefile" has to be issued from the top-level directory in
> >     order to rebuild autotools-generated files *due to an updated
> >     configure.ac* ...''
> 
> This just describes a symptom, not the underlying issue.
>
The underlying issue was that the `am--refresh' target didn't depend from
Makefile.

> I am pretty sure if the issue wasn't deeper, and the fix you issued not
> problematic for other use cases, then Alexandre would have implemented
> that years ago.
>
Ah, but consider that (unless I'm grossly mistaken), the remake rules
were originally written to work only with GNU make, and have been only
later extended to work (sorta) also with non-GNU make implementations.
So it's quite possible that the bit touched by my patch hasn't been
fixed before simply because it has gone unnoticed until now (after all,
how often do you run "make Makefile" from a subdirectory while using
a non-GNU make implementation *and* because you have updated not the
local Makefile.am, but the top-level configure.ac?)

> I don't approve of this change without a good analysis
>
You could probably just ask Alexandre why he wrote that snippet the
way he did.  I'm serious about this: maybe he knows the answer right
away.

> of why this does not introduce regressions.
>
I'd rather ask why do you think it could cause a regression.  My change
seems so natural and simple *to me* that I cannot see it causing any
problem (but again, I might be wrong, and overlooking something crucial).

> (No need to do it right away.)
>
> Cheers,
> Ralf
> 

Regards,
  Stefano