check for stale configure much earlier
Darren Tucker
dtucker at dtucker.net
Sat Jul 23 16:48:29 AEST 2022
Hi.
We have a Makefile rule that checks if configure's source files are
newer than configure itself and if so, error out. This was intended to
prevent people from being caught out by a stale configure after changing
configure.ac.
Unfortunately this turns out to be quite annoying particularly on slow
systems since it doesn't happen until all of the work in configure has
been wasted. Instead, I'd like to configure to handle this itself as
early as possible. Any objections?
diff --git a/Makefile.in b/Makefile.in
index 3c285682..4144a834 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -184,16 +184,11 @@ FIXPATHSCMD = $(SED) $(PATHSUBS)
FIXALGORITHMSCMD= $(SHELL) $(srcdir)/fixalgorithms $(SED) \
@UNSUPPORTED_ALGORITHMS@
-all: configure-check $(CONFIGFILES) $(MANPAGES) $(TARGETS)
+all: $(CONFIGFILES) $(MANPAGES) $(TARGETS)
$(LIBSSH_OBJS): Makefile.in config.h
$(SSHOBJS): Makefile.in config.h
$(SSHDOBJS): Makefile.in config.h
-configure-check: $(srcdir)/configure
-
-$(srcdir)/configure: configure.ac $(srcdir)/m4/*.m4
- @echo "ERROR: configure is out of date; please run ${AUTORECONF} (and configure)" 1>&2
- @exit 1
.c.o:
$(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $@
diff --git a/configure.ac b/configure.ac
index 3e9fd700..747fa90f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -16,6 +16,17 @@
AC_INIT([OpenSSH], [Portable], [openssh-unix-dev at mindrot.org])
AC_CONFIG_MACRO_DIR([m4])
AC_CONFIG_SRCDIR([ssh.c])
+
+# Check for stale configure as early as possible.
+for i in $srcdir/configure.ac $srcdir/m4/*.m4; do
+ if test "$i" -nt "$srcdir/configure"; then
+ AC_MSG_WARN([$i newer than configure, running autoreconf])
+ (cd $srcdir && autoreconf) || AC_MSG_ERROR([autoreconf failed])
+ AC_MSG_WARN([reexecing $0 $@])
+ exec $0 "$@"
+ fi
+done
+
AC_LANG([C])
AC_CONFIG_HEADERS([config.h])
--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
More information about the openssh-unix-dev
mailing list