* 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. > if %?TOPDIR_P% > .PHONY: am--refresh > -am--refresh: > +am--refresh: %MAKEFILE% > @: > endif %?TOPDIR_P% * Stefano Lattarini wrote on Tue, May 31, 2011 at 11:28:50AM CEST: > On Tuesday 31 May 2011, Peter Rosin wrote: > > My attempt follows: > > > > remake: behave better with non-GNU make in subdirectories. > > With a decent make program, it is possible to rebuild > > out-of-date autotools-generated files with a simple "make > > Makefile". Remove the limitation that "make Makefile" has > > to be issued from the top-level directory with non-GNU > > make implementations. > > > Thanks; this helped me to come up with this other entry, which while > being unfortunately more complex, is also more precise: > > remake: behave better with non-GNU make in subdirectories. > Remove the limitation 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 (or to an updated prerequisite thereof). > > This is what I'll use if there are no further objections. 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? Also, you violate the "put the explanation in the code, not in the log entry" principle, actually falsifying an existing comment in the code. Cheers, Ralf