Re: rhel8 test failure confirmation?

[Jacob Bachmeyer]

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