Re: rhel8 test failure confirmation?

Zack Weinberg wrote:
> On Sat, Dec 2, 2023, at 6:37 PM, Karl Berry wrote:
>   
>> The best way to check if high-resolution 
>>     timestamps are available to autom4te is to have perl load 
>>     Autom4te::FileUtils and check if that also loaded Time::HiRes.
>>
>> The problem with that turned out to be that Time::HiRes got loaded from
>> other system modules, resulting in the test thinking that autom4te used
>> it when that wasn't actually the case. That's what happened in practice
>> with your patch.
>>     
>
> Would it help if we added a command line option to autom4te that made it report whether it thought it could use high resolution timestamps? Versions of autom4te that didn't recognize this option should be conservatively assumed not to support them.
>   

Why not just add that information to the --version message?  Add a 
"(HiRes)" tag somewhere if Time::HiRes is available?  All versions that 
know to check if Time::HiRes is loaded will also know how to use it, 
unlike the earlier test.

> (Of course there's the additional wrinkle that whether high resolution timestamps *work* depends on what filesystem autom4te.cache is stored in, but that's even harder to probe... one problem at a time?)

Yes; even standard-resolution timestamps might not be "all there" with 
FAT and its infamous 2-second timestamp resolution.

Is this actually still a problem (other than for ensuring the cache is 
used in the testsuite) after Bogdan's patches to require that cache 
files be strictly newer than their source files?


-- Jacob