On Thu, Dec 21, 2023, at 10:07 PM, Jacob Bachmeyer wrote: > Zack Weinberg wrote: >> On Thu, Dec 21, 2023, at 3:27 AM, Frederic Berat wrote: >>> 11: autoconf: forbidden tokens, basic FAILED (tools.at:481) >>> So far I got it on aarch64 and s390x. Timing issue maybe ? >> >> Yeah, this one is <https://savannah.gnu.org/support/?110986>. >> We're expecting the second of two autoconf runs in quick succession >> to pull from a cache and sometimes it doesn't. I get it >> reproducibly on one of my test machines and I may try to pin it >> down later today, but I don't think it's worth holding the release >> for. > Looking at tests/tools.at, I think I found the problem: the > generated configure script is the /output/ from autoconf; there is > no reason for its timestamp to matter. That's a reasonable thing to think, but autom4te really does compare the timestamp of a file in its cache, to the timestamp of the *output* file, in order to decide whether to replace the output file. Right at the bottom of bin/autom4te.in: { # Actual M4 expansion, if the user wants it, or if $output is old # (STDOUT is pretty old). handle_output ($req, $output) if $force || mtime ($output) <= mtime ($ocache . $req->id); } It's been that way since autom4te was created (~2001). I'm not 100% sure I understand what it's doing but I believe this is *not* a bug. It regenerates *the file in the cache* ($ocache . $req->id) if *that* file is older than the inputs (configure.ac, aclocal.m4, etc, in this case). Then, if the file in the cache is now newer than the output file, it replaces the output file. It might make more sense to think of this as a move-if-change operation, more or less (there's several transforms in between what's in the cache and the actual output). Any how, I see several ways autom4te could be improved, here, but I think all of them are too invasive for today. The ‘touch’ that I added to the test case in 3fbfb13e7a846e98fa931b2bce373b5b2364a11b should be good enough for 2.72. > I suggest revising AT_MTIME_DELAY to actually create two files and > loop touching one of them until the timestamps differ. This won’t work, because whether *test* thinks two timestamps differ may be different from whether *autom4te* thinks two timestamps differ (due to the whole mess with Time::HiRes not necessarily being available, timestamps getting rounded to the nearest IEEE double, etc). Also, test -nt isn’t portable, we’d have to do the same mess with ls -t that’s in the code setting at_ts_resolution. > A quick look at tests/local.at (on Git master) suggests a possible > merge error probably unrealated to this issue: the AS_ECHO on line > 222 that announces the detected mtime resolution is in the subshell > that verifies that required programs are available instead of the > main level just after the "rm -f conftest.ts?" on line 170 that > cleans up the timestamp test files. That’s intentional. We report what timestamp resolution we are using after we report the versions of all the programs that might affect the outcome. zw
