[Top][All Lists]
[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: |
Stefano Lattarini |
Subject: |
Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories |
Date: |
Mon, 4 Jul 2011 11:43:40 +0200 |
User-agent: |
KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) |
References:
<http://lists.gnu.org/archive/html/automake-patches/2011-05/msg00110.html>
<http://lists.gnu.org/archive/html/automake-patches/2011-06/msg00193.html>
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.
>
> > 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.
>
You're right about this; a really bad blunder.
So here is what I've applied to a proper bug-fixing branch (already
merged to maint):
diff --git a/ChangeLog b/ChangeLog
index 9c9b256..af2db86 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2011-07-04 Stefano Lattarini <address@hidden>
+
+ remake: fix outdated comment in configure.am
+ * lib/am/configure.am: Fix comment falsified by changes in
+ commit `v1.11-366-gbee9871'.
+ Suggestion from Ralf Wildenhues.
+
2011-05-29 Stefano Lattarini <address@hidden>
remake: behave better with non-GNU make in subdirectories
diff --git a/lib/am/configure.am b/lib/am/configure.am
index d00846a..594ec67 100644
--- a/lib/am/configure.am
+++ b/lib/am/configure.am
@@ -17,9 +17,10 @@
## This dummy rule is called from subdirectories whenever one of the
-## top-level Makefile's dependencies must be updated. It does not
-## need to depend on %MAKEFILE% because GNU make will always make sure
-## %MAKEFILE% is updated before considering the am--refresh target.
+## top-level Makefile's dependencies must be updated. It does depend
+## on %MAKEFILE% for the benefit of non-GNU make implementations (GNU
+## make will always make sure %MAKEFILE% is updated before considering
+## the am--refresh target anyway).
if %?TOPDIR_P%
.PHONY: am--refresh
am--refresh: %MAKEFILE%
Regards,
Stefano
- Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories,
Stefano Lattarini <=