* 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
