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 subdirec


From: Stefano Lattarini
Subject: Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories
Date: Tue, 31 May 2011 11:28:50 +0200
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

On Tuesday 31 May 2011, Peter Rosin wrote:
> Den 2011-05-30 22:22 skrev Stefano Lattarini:
>
> [HUGE CUT]
>
> > In effect, using the present tense to describe a just fixed, and thus
> > past, problem, is suboptimal and might be confusing.  So what about
> > this updated ChangeLog entry?
> > 
> >     remake: behave better with non-GNU make in subdirectories
> >     Currently, with every decent make program, it is possible to
> >     rebuild out-of-date autotools-generated files with a simple
> >     "make Makefile".  But for this to work reliably with non-GNU
> >     make implementations, that command had be issued from the
> >     top-level directory.  This patch has removed such limitation.
> >     * lib/am/configure.am (am--refresh): Depend on `%MAKEFILE%'.
> >     * tests/defs.in (using_gmake): New function, backported from the
> >     `master' branch (and simplified).
> >     * tests/remake-subdir.test: New test.
> >     * tests/remake-subdir2.test: Likewise.
> >     * tests/remake-subdir-gnu.test: Likewise.
> >     * tests/remake-subdir-from-subdir.test: Likewise.
> >     * tests/Makefile.am (TESTS): Update.
> > 
> 
> Ok, new attempt at criticism. Sigh. Here we go.
> 
> I think it is a bit awkward to talk about "this patch" in the patch
> description, as it is obvious that the text refers to this patch. I also
> think "currently" is not obviously the state *without* the patch, you
> can also spot that there are problems with that when you continue
> to refer to how it was before the patch in past tense ("that command
> _had_ been issued") even though you started out with describing the state
> before the patch as the current state. One would think that the current
> state deserves present tense, but present tense is reserved for the
> changes themselves.
> 
> It quickly becomes a maze when you try to talk about both the state
> before the change, the change itself and the state after the change.
> So you have to be careful.
>
Understood.  Thanks for the detailed explanation, I'll try to be more
careful about this in the future.

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

> 
> Now, I haven't looked into the patch so I'm not sure *which* Makefile
> "make Makefile" regenerates if run from a subdir.  The top-level one
> (my blind guess) or the one in the current directory (which might be
> more natural)?
>
It depends; if configure.ac or one of it's prerequisites has been modified,
than "make Makefile" from a subdir should rebuild *all* Makefiles, but if,
say, only the Makefile.am in the current directory has been modified, then
"make Makefile" should only update the Makefile in the current directory.
I'm not sure this latter behaviour is currently checked by the testsuite;
if not, I might add a test for it (but that's for the `testsuite-work'
branch anyway).

> 
> Cheers,
> Peter
> 

Thanks,
  Stefano



reply via email to

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