[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[sr #110989] Improve reliability of AT_MTIME_DELAY in test suite with a
From: |
Zack Weinberg |
Subject: |
[sr #110989] Improve reliability of AT_MTIME_DELAY in test suite with a loop |
Date: |
Fri, 22 Dec 2023 11:21:37 -0500 (EST) |
URL:
<https://savannah.gnu.org/support/?110989>
Summary: Improve reliability of AT_MTIME_DELAY in test suite
with a loop
Group: Autoconf
Submitter: zackw
Submitted: Fri 22 Dec 2023 04:21:35 PM UTC
Priority: 5 - Unprioritized
Severity: 1 - Wish
Status: Confirmed
Privacy: Public
Assigned to: None
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Operating System: None
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Fri 22 Dec 2023 04:21:35 PM UTC By: Zack Weinberg <zackw>
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.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/support/?110989>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
- [sr #110989] Improve reliability of AT_MTIME_DELAY in test suite with a loop,
Zack Weinberg <=