Hi Erik - following up on your final comment in #68119:
P.P.S. It still needs
export am_cv_sleep_fractional_seconds=false
to correctly run the tests on macOS. Without that, 75-90 tests fail.
Maybe we can try to figure out why the code that tries to automatically
discern whether subsecond mtimes are supported is insufficient? It seems
there is something different about the mac filesystem (or something). So
I suspect there will be problems on other systems, too.
If there are any test(s) which more or less consistently fail without
the override the sleep_fractional_seconds, maybe we can discern why
those tests are failing. I am dearly hoping not to have inspect every
single test and scatter $sleep commands everywhere.
Meanwhile, the code that tries to figure out if subsecond mtimes are
supported is in m4/sanity.m4, function
_AM_FILESYSTEM_TIMESTAMP_RESOLUTION. It essentially writes to three
files and sleeps for the trial resolution between them, starting at a
hundredth of a second. Then, if ls -t sorts in the right order, it
assumes that resolution is ok.
For one thing, just to get a grip on reality, maybe you could try
running those commands by hand and see what the result is. I'm guessing
the Mac (and its sleep command?) do support subsecond mtimes in reality.
am_try_res=.001
echo alpha > conftest.ts1
sleep $am_try_res
echo beta > conftest.ts2
sleep $am_try_res
echo gamma > conftest.ts3
ls -t conftest.ts?
The result should be conftest.ts3 first, then ts2, then ts1.
But, looking at that code, I belatedly see that shell arrays are being
used. At least I think so. It wouldn't surprise me if the mac /bin/sh
doesn't support arrays. But that should result in assuming subsecond
mtimes are not supported when they are, instead of the reverse. Anyway,
I don't think we can assume arrays, so I'll have to think about that.
But the important thing is why so many tests fail on your system when
subsecond mtimes are enabled (and succeed when not). --thanks, karl.
