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

[Ralf Wildenhues]

* 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.

> > 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.

> 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.

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.  I don't approve of this change without a good analysis
of why this does not introduce regressions.

(No need to do it right away.)

Cheers,
Ralf