automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ralf Wildenhues
Subject: Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories
Date: Tue, 21 Jun 2011 22:29:12 +0200

* 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]