From: Martin von Zweigbergk <hidden> Date: 2016-06-15 22:55:38
Hi,
I use autoconf with git.git. I have noticed lately, especially when
doing things like "git rebase -i --exec make", that ./configure is run
every time. If I understand correctly, this is because of 8242ff4
(build: reconfigure automatically if configure.ac changes,
2012-07-19). Just a few days before that commit, on 2012-07-15, the
branch jn/makefile-cleanup including 520a6cd (Makefile: move
GIT-VERSION-FILE dependencies closer to use, 2012-06-20) was merged
(to next?). I wonder if these two subjects were aware of each other.
The reason 'configure' depends on GIT-VERSION-FILE is because it
inserts the version into the call to AC_INIT. I have close to no
experience with autoconf or even make and it's not at all clear to me
why we need to pass the verison to AC_INIT. It seems like it's just
for messages printed by ./configure. If that's the case, we shouldn't
need to generate a new 'configure' file ever time. At the very least,
we shouldn't need to run it.
Do you think we should simply remove the dependency from 'configure'
to 'GIT-VERSION-FILE' and leave a comment there instead? Or should we
instead somehow make 'reconfigure' depend only on 'configure.ac'? Both
of these feel a little wrong to me, because they would remove real
dependencies. Maybe the (probably mangled) patch at the end of this
message is better?
Martin
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:55:38
Hi Martin,
Martin von Zweigbergk wrote:
I use autoconf with git.git. I have noticed lately, especially when
doing things like "git rebase -i --exec make", that ./configure is run
every time. If I understand correctly, this is because of 8242ff4
(build: reconfigure automatically if configure.ac changes,
2012-07-19).
How about this patch (untested)?
-- >8 --
Subject: build: do not automatically reconfigure unless configure.ac changed
Starting with v1.7.12-rc0~4^2 (build: reconfigure automatically if
configure.ac changes, 2012-07-19), "config.status --recheck" is
automatically run every time the "configure" script changes. In
particular, that means the configuration procedure repeats whenever
the version number changes (since the configure script changes to
support "./configure --version" and "./configure --help"), making
bisecting painfully slow.
The intent was to make the reconfiguration process only trigger for
changes to configure.ac's logic. Tweak the Makefile rule to match
that intent by depending on configure.ac instead of configure.
Reported-by: Martin von Zweigbergk <redacted>
Signed-off-by: Jonathan Nieder <redacted>
---
[...]
@@ -142,7 +142,10 @@ fi ## Configure body starts here. AC_PREREQ(2.59)-AC_INIT([git], [@@GIT_VERSION@@], [git@vger.kernel.org])+AC_INIT([git],+ m4_esyscmd([ ./GIT-VERSION-GEN &&+ { sed -ne 's/GIT_VERSION = //p' GIT-VERSION-FILE | xargs echo -n; } ]),+ [git@vger.kernel.org])
I don't think that would warrant dropping the GIT-VERSION-FILE
dependency, since the resulting configure script still hard-codes the
version number.
Sane?
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The next line just outside the context here does depend on
'configure', which is why I thought this would not be right. But it
seems impossible to get away from that, and AUTOCONFIGURED should only
be set when ./configure has been run (IIUC), so it's not even
realistic to have "git reconfigure" fail to find "./configure". So,
again, looks good.
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:55:38
Starting with v1.7.12-rc0~4^2 (build: reconfigure automatically if
configure.ac changes, 2012-07-19), configure is automatically run
every time the "configure" script changes. In particular, that
means configure is automatically rerun whenever the version number
changes (which changes the configure script to support "./configure
--helpe"), which makes bisecting painfully slow.
The intent was to make the reconfiguration process only trigger for
changes to configure.ac's logic. Tweak the Makefile rule to match
that intent by depending on configure.ac instead of configure.
Reported-by: Martin von Zweigbergk <redacted>
Signed-off-by: Jonathan Nieder <redacted>
---
Martin von Zweigbergk wrote:
The next line just outside the context here does depend on
'configure', which is why I thought this would not be right.
Yes, the 'configure' script that is run needs to reflect the changes
to configure.ac. Hopefully this version will work better.
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Jeff King <hidden> Date: 2016-06-15 22:55:38
On Wed, Jan 02, 2013 at 12:25:44AM -0800, Jonathan Nieder wrote:
Starting with v1.7.12-rc0~4^2 (build: reconfigure automatically if
configure.ac changes, 2012-07-19), configure is automatically run
every time the "configure" script changes. In particular, that
means configure is automatically rerun whenever the version number
changes (which changes the configure script to support "./configure
--helpe"), which makes bisecting painfully slow.
The intent was to make the reconfiguration process only trigger for
changes to configure.ac's logic. Tweak the Makefile rule to match
that intent by depending on configure.ac instead of configure.
It seems I am late to the party. But FWIW, this looks the most sane to
me of the patches posted in this thread.
-Peff
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:55:38
Jonathan Nieder wrote:
Starting with v1.7.12-rc0~4^2 (build: reconfigure automatically if
configure.ac changes, 2012-07-19), configure is automatically run
every time the "configure" script changes. In particular, that
means configure is automatically rerun whenever the version number
changes (which changes the configure script to support "./configure
--helpe")
Gah, I sent the log commit message --- the patch description from v1
is the right one. Sorry for the trouble. Here is the fixed
description again.
Subject: build: do not automatically reconfigure unless configure.ac changed
Starting with v1.7.12-rc0~4^2 (build: reconfigure automatically if
configure.ac changes, 2012-07-19), "config.status --recheck" is
automatically run every time the "configure" script changes. In
particular, that means the configuration procedure repeats whenever
the version number changes (since the configure script changes to
support "./configure --version" and "./configure --help"), making
bisecting painfully slow.
The intent was to make the reconfiguration process only trigger for
changes to configure.ac's logic. Tweak the Makefile rule to match
that intent by depending on configure.ac instead of configure.
Reported-by: Martin von Zweigbergk <redacted>
Signed-off-by: Jonathan Nieder <redacted>
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:55:38
Jeff King wrote:
It seems I am late to the party. But FWIW, this looks the most sane to
me of the patches posted in this thread.
Thanks. config.status runs ./configure itself, though, so the rule
should actually be
config.status: configure.ac
$(QUIET_GEN)$(MAKE) configure && \
if test -f config.status; then \
./config.status --recheck; \
else \
./configure;
fi
Rather than screw it up yet again, I'm going to sleep. :) If someone
else corrects the patch before tomorrow, I won't mind.
It seems I am late to the party. But FWIW, this looks the most sane to
me of the patches posted in this thread.
Thanks. config.status runs ./configure itself, though, so the rule
should actually be
config.status: configure.ac
$(QUIET_GEN)$(MAKE) configure && \
if test -f config.status; then \
./config.status --recheck; \
else \
./configure;
fi
Rather than screw it up yet again, I'm going to sleep. :) If someone
else corrects the patch before tomorrow, I won't mind.
FYI, this seems a sane approach to me. At least until Autoconf is
improved to offer better (read: some :-) support to "dynamic" package
version numbers specified at configure runtime. I hope that day
isn't too far, since the current Autoconf limitation has been causing
its share of annoyances small woes in Automake and Gnulib as well.
The only nit I have to offer is that I'd like to see more comments in
the git Makefile about why this "semi-hack" is needed.
Thanks,
Stefano