Nick Bowler wrote:
On 2024-06-16 21:35, Jacob Bachmeyer wrote:
I think we might best be able to avoid this by using AC_CONFIG_COMMANDS_POST
to touch config.status if neccessary, instead of trying to decide
whether to sleep before writing config.status.
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.
We can guarantee that by reusing the pattern in AM_SANITY_CHECK, which
uses `ls -t`, with the advantage that we have already used that pattern,
so it cannot add "new" possible portability problems. I would also
suggest a `sleep 1` in the loop instead of spinning on the test, since
we expect the common case to not loop at all.
Also, if we use `echo >> config.status` as Bruno Haible suggested in
another reply, every cycle will add one newline to the end of
config.status, so spinning at the test could make config.status very large.
If we want to allow "checking that generated files are newer than
configure" to fail, I would suggest bounding this at 5 seconds and
bailing out after 5 `sleep 1` if config.status is not newer by then, but
see below.
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.
This will not be a problem: AM_SANITY_CHECK bails out (or will bail
out) if a recently-created file cannot be made newer than configure by
sleeping briefly. If configure's mtime is in the future, config.status
will never be written and this code will never be reached. The delay
here is thus bounded by the filesystem timestamp resolution, since we
may have to wait until config.status is newer than configure---but no
longer---and that only if configure was regenerated just before being
run. In the case of a tree of configure scripts that started this
current mess, time will march on as the first run waits for
config.status to be newer, and the later configure runs will each find
that their config.status is newer when it is first written.
In fact, now that I think about it, I am not sure how this could ever be
a problem: time marches on as AM_SANITY_CHECK is doing its thing before
any tests are run, so once conftest.file is newer than configure, surely
config.status, which is produced after all tests are run, /must/ also be
newer than configure?
How is this last check/delay actually necessary? Are there broken
systems out there that play games with causality?
-- Jacob
