I'd like to have further discussion about this ongoing subject here, for the sake of future trackability.
So far as I can see, we've currently got Bruno's patch#2 from https://lists.gnu.org/archive/html/automake/2024-06/msg00055.html (attached here)
0001-automake-Save-up-to-2-seconds-of-configure-time.patch
Description: Binary data
plus Nick's change to use AC_CONFIG_COMMANDS_POST instead of _PRE,
copied below, plus some sort of limiting. --thanks, karl.
Date: Mon, 17 Jun 2024 00:29:07 -0400
From: Nick Bowler <nbow...@draconx.ca>
Subject: Re: 1.16.90 regression: configure now takes 7 seconds to start
If the problem is simply that we want to avoid the situation where
"make" considers config.status to be out of date wrt. configure, or
something similar with any other pair of files, then this should be
solveable fairly easily with a pattern like this (but see below):
AC_CONFIG_COMMANDS_POST([cat >conftest.mk <<'EOF'
configure: config.status
false
EOF
while ${MAKE-make} -f conftest.mk >/dev/null 2>&1
do
touch config.status
done])
In my own experience the above pattern is portable. It works with HP-UX
make. It works with a "touch" that truncates timestamps. In the common
case where configure is sufficiently old the loop condition will always
be false and there is no delay.
It won't guarantee that config.status has a strictly newer timestamp
than configure (except on HP-UX), but it sounds like that's fine.
One missing element is that there is no limit, which would be a bit of a
problem if the clock skew is severe (e.g., if configure's mtime is years
or even minutes in the future), so something extra is probably desirable
to bound the amount of time this runs to something practical.
