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: 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



reply via email to

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