mainAutoconf - Support: sr #110989, Improve reliability of...

 
 

sr #110989: Improve reliability of AT_MTIME_DELAY in test suite with a loop

Submitter:  Zack Weinberg <zackw>
Submitted:  Fri 22 Dec 2023 04:21:35 PM UTC
   
 
Priority:  * 3 - Release N+1 Severity:  1 - Wish
Status:  Confirmed Privacy:  Public
Assigned to:  None Open/Closed:  Open
Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 09 Jan 2024 09:30:40 PM UTC, comment #2: 

No, if I understood Nick and Jacob's suggestions correctly, the idea is to replace $am_sleep / AT_MTIME_DELAY with something like


while [ ! newer_file -nt older_file ]; do
  sleep $am_cv_filesystem_timestamp_resolution
  touch newer_file
done


But we need a Perl helper to implement that, because test -nt isn't in POSIX, and a test implementation that does support -nt will probably be comparing 'struct timespec's directly rather than converting to 'double' first as Perl does.  My current vague plan is to make it be a special mode of autom4te,


autom4te --ensure-newer newer_file older_file


It could also be a separate helper script like move-if-change or automake's "missing".

Zack Weinberg <zackw>
Group administrator
Mon 08 Jan 2024 11:46:57 PM UTC, comment #1: 

Zack, isn't that essentially the code you wrote for _AM_FILESYSTEM_TIMESTAMP_RESOLUTION in Automake (sanity.m4)?


for am_try_res in $am_try_resolutions; do
  # Any one fine-grained sleep might happen to cross the boundary
  # between two values of a coarser actual resolution, but if we do
  # two fine-grained sleeps in a row, at least one of them will fall
  # entirely within a coarse interval.
  echo alpha > conftest.ts1
  sleep $am_try_res
  echo beta > conftest.ts2
  sleep $am_try_res
  echo gamma > conftest.ts3

  # We assume that 'ls -t' will make use of high-resolution
  # timestamps if the operating system supports them at all.
  if (set X `ls -t conftest.ts?` &&
      test "$[]2" = conftest.ts3 &&
      test "$[]3" = conftest.ts2 &&
      test "$[]4" = conftest.ts1); then
    am_cv_filesystem_timestamp_resolution=$am_try_res
    break
  fi
done


Karl Berry <karl>
Group Member
Fri 22 Dec 2023 04:21:35 PM UTC, original submission:  

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.

Zack Weinberg <zackw>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by karl (Posted a comment)
  • -email is unavailable- added by zackw (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-12-22 zackw Priority5 - Unprioritized 3 - Release N+1

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code