GNU bug report logs - #71652
optimizing the sleep in Automake's sanity.m4

Previous Next

To reply to this bug, email your comments to 71652 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: automake-patches <at> gnu.org
Subject: optimizing the sleep in Automake's sanity.m4
Date: Wed, 19 Jun 2024 10:26:43 -0600

[Message part 1 (text/plain, inline)]

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 (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.