|
From: | Jacob Bachmeyer |
Subject: | Re: rhel8 test failure confirmation? |
Date: | Sat, 02 Dec 2023 18:33:11 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |