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

[Stefano Lattarini]

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.
>
OK will fix in a follow-up patch (probably tomorrow).  The above comment
holds only for GNU make BTW (and correctly states so), so I think I'll
just remove it.

> >  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?
>
It's not a silly limitation of those make implementations at all -- it is
was silly limitation in automake!  Automake-generated code was relying on
GNU make semantics even when POSIX semantics would have worked just as well.

And IMHO ChangeLog entry describes this silly limitation in detail (albeit
probably with suboptimal wording):

 ``... the limitation [was] 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* ...''

> Also, you violate the "put the explanation in the code, not in the log
> entry" principle, actually falsifying an existing comment in the code.
>
True.  Sorry about that.

Regards,
  Stefano