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

[Ralf Wildenhues]

* 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