Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories
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 stefano.lattar...@gmail.com + + 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 stefano.lattar...@gmail.com 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
References:
http://lists.gnu.org/archive/html/automake-patches/2011-05/msg00110.html
http://lists.gnu.org/archive/html/automake-patches/2011-06/msg00197.html
On Tuesday 21 June 2011, Stefano Lattarini wrote:
On Tuesday 21 June 2011, Ralf Wildenhues wrote:
What's more: have you tried this patch on a nontrivial source tree
(where regenerating takes more than a second or so) with a few non-GNU
makes and GNU make? I kinda fear that it can cause an endless regen loop.
It doesn't I think. See the attached test (which I'd like to commit in
a follow-up patch, to be merged into maint). Works with Solaris make,
GNU make, NetBSD make and FreeBSD make. If that tests doesn't cover the
scenario you have in mind, could you please explain it in more detail, so
that we can write a proper test case for it?
Attached is the test I've ended up applying at last; it is more complicated,
but also safer and more correct.
Regards,
Stefano
From 044035ce85d089a9bbdfd6fa99c31dd22b74e7db Mon Sep 17 00:00:00 2001
Message-Id: 044035ce85d089a9bbdfd6fa99c31dd22b74e7db.1309772506.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Mon, 4 Jul 2011 11:41:34 +0200
Subject: [PATCH] remake: add test ensuring that slower remakes don't hang
* tests/remake-subdir-long-time.test: New test.
* tests/Makefile.am (TESTS): Update.
Suggestion by Ralf Wildenhues.
---
ChangeLog |7 ++
tests/Makefile.am |1 +
tests/Makefile.in |1 +
tests/remake-subdir-long-time.test | 116
4 files changed, 125 insertions(+), 0 deletions(-)
create mode 100755 tests/remake-subdir-long-time.test
diff --git a/ChangeLog b/ChangeLog
index 80506a7..7108823 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,12 @@
2011-07-04 Stefano Lattarini stefano.lattar...@gmail.com
+ remake: add test ensuring that slower remakes don't hang
+ * tests/remake-subdir-long-time.test: New test.
+ * tests/Makefile.am (TESTS): Update.
+ Suggestion by Ralf Wildenhues.
+
+2011-07-04 Stefano Lattarini stefano.lattar...@gmail.com
+
remake: fix outdated comment in configure.am
* lib/am/configure.am: Fix comment falsified by changes in
commit `v1.11-366-gbee9871'.
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 33ae8bc..9c5c03f 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -658,6 +658,7 @@ remake-subdir-from-subdir.test \
remake-subdir-gnu.test \
remake-subdir.test \
remake-subdir2.test \
+remake-subdir-long-time.test \
pr8365-remake-timing.test \
regex.test \
req.test \
diff --git a/tests/Makefile.in b/tests/Makefile.in
index ad45cff..1b01757 100644
--- a/tests/Makefile.in
+++ b/tests/Makefile.in
@@ -926,6 +926,7 @@ remake-subdir-from-subdir.test \
remake-subdir-gnu.test \
remake-subdir.test \
remake-subdir2.test \
+remake-subdir-long-time.test \
pr8365-remake-timing.test \
regex.test \
req.test \
diff --git a/tests/remake-subdir-long-time.test b/tests/remake-subdir-long-time.test
new file mode 100755
index 000..18ba732
--- /dev/null
+++ b/tests/remake-subdir-long-time.test
@@ -0,0 +1,116 @@
+#! /bin/sh
+# Copyright (C) 2011 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+
+# Check that remake rules from subdirectories do not hang or cycle
+# endlessly, even with build systems that takes several seconds to
+# rebuild the Makefiles.
+# This test tries to ensure a long-enough rebuild time by introducing
+# an explicit delay in the build process.
+# Suggestion by Ralf Wildenhues.
+
+. ./defs || Exit 1
+
+set -e
+
+cat configure.in END
+AC_INIT([$me], [1.0])
+AM_INIT_AUTOMAKE([foreign -Wall -Werror])
+AC_CONFIG_FILES([Makefile sub/Makefile])
+AC_SUBST([MAGIC], [magic])
+AC_OUTPUT
+END
+
+echo SUBDIRS = sub Makefile.am
+mkdir sub
+: sub/Makefile.am
+
+# Both aclocal and automake are expected to run one and just one time.
+# Create and use wrappers that will verify that.
+
+ocwd=`pwd` || fatal_ cannot get current working directory
+
+mkdir bin
+
+cat bin/automake END
+#!/bin/sh
+set -e
+PATH='$PATH'; export PATH
+sentinel='$ocwd/automake-has-run'
+if test -f \$sentinel; then
+ echo Automake has been run more than one time 2
+ exit 1
+else
+ echo automake has run \$sentinel
+fi
+$sleep; $sleep;
+exec $AUTOMAKE \${1+\$@}
+END
+chmod a+x bin/automake
+
+cat bin/aclocal END
Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories
* 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
Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories
What's more: have you tried this patch on a nontrivial source tree (where regenerating takes more than a second or so) with a few non-GNU makes and GNU make? I kinda fear that it can cause an endless regen loop. It might actually be smarter to use some newer BSD make features to mark Makefile as prerequisite to rebuild, and ignore other makes. But well, this thread doesn't yet contain analysis about the bug in question ... Thanks, Ralf
Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories
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
Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories
* Stefano Lattarini wrote on Tue, Jun 21, 2011 at 10:43:06PM CEST: 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. No. 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. This is not true, IIRC. 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* ...'' This just describes a symptom, not the underlying issue. I am pretty sure if the issue wasn't deeper, and the fix you issued not problematic for other use cases, then Alexandre would have implemented that years ago. I don't approve of this change without a good analysis of why this does not introduce regressions. (No need to do it right away.) Cheers, Ralf
Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories
On Tuesday 21 June 2011, Ralf Wildenhues wrote: What's more: have you tried this patch on a nontrivial source tree (where regenerating takes more than a second or so) with a few non-GNU makes and GNU make? I kinda fear that it can cause an endless regen loop. It doesn't I think. See the attached test (which I'd like to commit in a follow-up patch, to be merged into maint). Works with Solaris make, GNU make, NetBSD make and FreeBSD make. If that tests doesn't cover the scenario you have in mind, could you please explain it in more detail, so that we can write a proper test case for it? It might actually be smarter to use some newer BSD make features to mark Makefile as prerequisite to rebuild, and ignore other makes. But well, this thread doesn't yet contain analysis about the bug in question ... I honestly don't understand what isn't clear yet about the bug (which BTW I see as a limitation rather than a real bug). Could you please elaborate a bit more on this? Thanks, Stefano remake-subdir-long-time.test Description: application/shellscript
Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories
On Tuesday 21 June 2011, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Tue, Jun 21, 2011 at 10:43:06PM CEST: 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. No. Why not? That comment used to explain the reasons for a non obvious part of the code, but now we've changed that part back the obvious form/behaviour, so the comment is not needed anymore. 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. This is not true, IIRC. Why not? Honest question, as my tests seem to prove otherwise (but then, they might be incomplete). 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* ...'' This just describes a symptom, not the underlying issue. The underlying issue was that the `am--refresh' target didn't depend from Makefile. I am pretty sure if the issue wasn't deeper, and the fix you issued not problematic for other use cases, then Alexandre would have implemented that years ago. Ah, but consider that (unless I'm grossly mistaken), the remake rules were originally written to work only with GNU make, and have been only later extended to work (sorta) also with non-GNU make implementations. So it's quite possible that the bit touched by my patch hasn't been fixed before simply because it has gone unnoticed until now (after all, how often do you run make Makefile from a subdirectory while using a non-GNU make implementation *and* because you have updated not the local Makefile.am, but the top-level configure.ac?) I don't approve of this change without a good analysis You could probably just ask Alexandre why he wrote that snippet the way he did. I'm serious about this: maybe he knows the answer right away. of why this does not introduce regressions. I'd rather ask why do you think it could cause a regression. My change seems so natural and simple *to me* that I cannot see it causing any problem (but again, I might be wrong, and overlooking something crucial). (No need to do it right away.) Cheers, Ralf Regards, Stefano
Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories
On Tuesday 31 May 2011, Stefano Lattarini wrote: 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've now pushed the patch. Thanks Peter for your feedback. Regards, Stefano
Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories
Den 2011-05-30 22:22 skrev Stefano Lattarini: On Sunday 29 May 2011, Peter Rosin wrote: Den 2011-05-29 19:32 skrev Stefano Lattarini: Hi Peter, thanks for the review. I wouldn't call it review, it was more of a knee-jerk reaction Well, I still appreciate it anyway. (and I haven't even read the actual patch). There's still time to remedy that, right? (Just kidding ;-) There is just no way I'm going to keep up with your seemingly endless string of patches. :-) On Sunday 29 May 2011, Peter Rosin wrote: Den 2011-05-29 16:26 skrev Stefano Lattarini: Currently, every decent non-GNU make program makes it possible to remake out-of-date autotools-generated files with a simple make Makefile issued from the top-level directory. And while having to run make Makefile by hand isn't as convenient as the GNU make feature of automatic remake *and reloading* of out-of-date makefiles, it is usually good enough and definitely worth having. Unfortunately, a silly limitation in the current implementation of remake rules prevents this idiom from working when it's used outside the top-level directory. Luckily, this limitation is easy to remove, and that's what this patch does. Nitpick: The tense is wrong for a ChangeLog entry, and there's a tab in there as well. Suggestion: Remove silly limitation that prevents this idiom from working outside the top-level directory. I'm not sure if the essay style of the first paragraph should stay or go though? I mostly agree with your objections. What do you think about this ChangeLog entry instead? Hmmm, it just feels like you have identified some problem, and then you proceed to writing a patch. Then you write some words to tell the world about the problem and the solution and put it all in the ChangeLog. Actually, I did the other way around (mostly: identify problem, write ChangeLog entry, fix problem, tweak ChangeLog entry if needed). While this might sometimes lead to overly longish ChangeLog entries, IMVHO it also usually leads to better patches, as it forces me to express clearly and unambiguously what I'm trying to do, and more importantly, why. It feels backwards to have the *original* problem description in the ChangeLog, but I'm no longer sure if it's really all that bad or if it just feels backwards _to_me_. Do you have explicit, specifical objections to the ChangeLog change, or suggestions about how to improve it? I'm prepared to listen to them, and tweak the ChangeLog entry accordingly. And regarding the tense, now that I think of it that's probably only the rule for the actual changes in the asterisk lines, not the header, so that was probably off base too. Not sure though. 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. Me feels bad, sorry for the interruption. I lost the confidence to voice my opinion... Why? I think that the modified ChangeLog entries prompted by your answer are already an improvement over my original one; so I wouldn't qualify your intervention as useless, or as an interruption. 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. 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
Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories
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
Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories
On Sunday 29 May 2011, Peter Rosin wrote: Den 2011-05-29 19:32 skrev Stefano Lattarini: Hi Peter, thanks for the review. I wouldn't call it review, it was more of a knee-jerk reaction Well, I still appreciate it anyway. (and I haven't even read the actual patch). There's still time to remedy that, right? (Just kidding ;-) On Sunday 29 May 2011, Peter Rosin wrote: Den 2011-05-29 16:26 skrev Stefano Lattarini: Currently, every decent non-GNU make program makes it possible to remake out-of-date autotools-generated files with a simple make Makefile issued from the top-level directory. And while having to run make Makefile by hand isn't as convenient as the GNU make feature of automatic remake *and reloading* of out-of-date makefiles, it is usually good enough and definitely worth having. Unfortunately, a silly limitation in the current implementation of remake rules prevents this idiom from working when it's used outside the top-level directory. Luckily, this limitation is easy to remove, and that's what this patch does. Nitpick: The tense is wrong for a ChangeLog entry, and there's a tab in there as well. Suggestion: Remove silly limitation that prevents this idiom from working outside the top-level directory. I'm not sure if the essay style of the first paragraph should stay or go though? I mostly agree with your objections. What do you think about this ChangeLog entry instead? Hmmm, it just feels like you have identified some problem, and then you proceed to writing a patch. Then you write some words to tell the world about the problem and the solution and put it all in the ChangeLog. Actually, I did the other way around (mostly: identify problem, write ChangeLog entry, fix problem, tweak ChangeLog entry if needed). While this might sometimes lead to overly longish ChangeLog entries, IMVHO it also usually leads to better patches, as it forces me to express clearly and unambiguously what I'm trying to do, and more importantly, why. It feels backwards to have the *original* problem description in the ChangeLog, but I'm no longer sure if it's really all that bad or if it just feels backwards _to_me_. Do you have explicit, specifical objections to the ChangeLog change, or suggestions about how to improve it? I'm prepared to listen to them, and tweak the ChangeLog entry accordingly. And regarding the tense, now that I think of it that's probably only the rule for the actual changes in the asterisk lines, not the header, so that was probably off base too. Not sure though. 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. Me feels bad, sorry for the interruption. I lost the confidence to voice my opinion... Why? I think that the modified ChangeLog entries prompted by your answer are already an improvement over my original one; so I wouldn't qualify your intervention as useless, or as an interruption. Regards, Stefano
Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories
Den 2011-05-29 16:26 skrev Stefano Lattarini: Currently, every decent non-GNU make program makes it possible to remake out-of-date autotools-generated files with a simple make Makefile issued from the top-level directory. And while having to run make Makefile by hand isn't as convenient as the GNU make feature of automatic remake *and reloading* of out-of-date makefiles, it is usually good enough and definitely worth having. Unfortunately, a silly limitation in the current implementation of remake rules prevents this idiom from working when it's used outside the top-level directory. Luckily, this limitation is easy to remove, and that's what this patch does. Nitpick: The tense is wrong for a ChangeLog entry, and there's a tab in there as well. Suggestion: Remove silly limitation that prevents this idiom from working outside the top-level directory. I'm not sure if the essay style of the first paragraph should stay or go though? Cheers, Peter
Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories
Hi Peter, thanks for the review. On Sunday 29 May 2011, Peter Rosin wrote: Den 2011-05-29 16:26 skrev Stefano Lattarini: Currently, every decent non-GNU make program makes it possible to remake out-of-date autotools-generated files with a simple make Makefile issued from the top-level directory. And while having to run make Makefile by hand isn't as convenient as the GNU make feature of automatic remake *and reloading* of out-of-date makefiles, it is usually good enough and definitely worth having. Unfortunately, a silly limitation in the current implementation of remake rules prevents this idiom from working when it's used outside the top-level directory. Luckily, this limitation is easy to remove, and that's what this patch does. Nitpick: The tense is wrong for a ChangeLog entry, and there's a tab in there as well. Suggestion: Remove silly limitation that prevents this idiom from working outside the top-level directory. I'm not sure if the essay style of the first paragraph should stay or go though? I mostly agree with your objections. What do you think about this ChangeLog entry instead? 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, the command must be issued from the top-level directory. This patch removes 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. Thanks, Stefano
Re: [PATCH] {maint} remake: behave better with non-GNU make in subdirectories
Den 2011-05-29 19:32 skrev Stefano Lattarini: Hi Peter, thanks for the review. I wouldn't call it review, it was more of a knee-jerk reaction (and I haven't even read the actual patch). On Sunday 29 May 2011, Peter Rosin wrote: Den 2011-05-29 16:26 skrev Stefano Lattarini: Currently, every decent non-GNU make program makes it possible to remake out-of-date autotools-generated files with a simple make Makefile issued from the top-level directory. And while having to run make Makefile by hand isn't as convenient as the GNU make feature of automatic remake *and reloading* of out-of-date makefiles, it is usually good enough and definitely worth having. Unfortunately, a silly limitation in the current implementation of remake rules prevents this idiom from working when it's used outside the top-level directory. Luckily, this limitation is easy to remove, and that's what this patch does. Nitpick: The tense is wrong for a ChangeLog entry, and there's a tab in there as well. Suggestion: Remove silly limitation that prevents this idiom from working outside the top-level directory. I'm not sure if the essay style of the first paragraph should stay or go though? I mostly agree with your objections. What do you think about this ChangeLog entry instead? Hmmm, it just feels like you have identified some problem, and then you proceed to writing a patch. Then you write some words to tell the world about the problem and the solution and put it all in the ChangeLog. It feels backwards to have the *original* problem description in the ChangeLog, but I'm no longer sure if it's really all that bad or if it just feels backwards _to_me_. And regarding the tense, now that I think of it that's probably only the rule for the actual changes in the asterisk lines, not the header, so that was probably off base too. Not sure though. Me feels bad, sorry for the interruption. I lost the confidence to voice my opinion... Cheers, Peter
