No, if I understood Nick and Jacob's suggestions correctly, the idea is to replace $am_sleep / AT_MTIME_DELAY with something like

while [ ! newer_file -nt older_file ]; do
  sleep $am_cv_filesystem_timestamp_resolution
  touch newer_file
done

But we need a Perl helper to implement that, because test -nt isn't in POSIX, and a test implementation that does support -nt will probably be comparing 'struct timespec's directly rather than converting to 'double' first as Perl does.  My current vague plan is to make it be a special mode of autom4te,

autom4te --ensure-newer newer_file older_file

It could also be a separate helper script like move-if-change or automake's "missing".

Recording this idea for the next release cycle:

On Fri, Dec 22, 2023, at 10:08 AM, Nick Bowler wrote:

> On 2023-12-22 09:28, Zack Weinberg wrote:
>> On Thu, Dec 21, 2023, at 10:07 PM, Jacob Bachmeyer wrote:
> [...]
>>> 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.
>
> Since for the purpose of testing autom4te behaviour one should be able
> to assume autom4te is available, a solution for this issue would be to
> simply add a mechanism to autom4te (or find a creative way to do it
> with existing autom4te) which compares two file timestamps, and use
> that in the loop.

Rather than adding it to autom4te itself, perhaps a tiny Perl script
that does the loop.  We would still need to detect whether automake
understands high-resolution timestamps.

It would also make sense for autom4te to ensure that its output file
is newer than its cache file.