Re: rhel8 test failure confirmation?

[Zack Weinberg]

On Sun, Dec 3, 2023, at 4:49 PM, Karl Berry wrote:
>> There would not need to be much parsing, just "automake --version | grep 
>     > HiRes" in that case, or "case `automake --version` in *HiRes*) ...;; 
>     > easc" to avoid running grep if you want.
>
>     I specifically want to hear what Karl thinks.
>
> I lean towards Jacob's view that automake --version | grep HiRes will
> suffice. Not having a new option seems simpler/better in terms of later
> understanding, too. --thanks, karl.

Did I misunderstand which program's --version output we are talking about?
I thought we were talking about automake's testsuite probing the behavior
of *autom4te*, but all the quoted text seems to be imagining a probe of
*automake* instead.  Yinz can change automake yourselves, you don't need
me to jump in :-)

Assuming this is really about autom4te, how does this look?

$ ./tests/autom4te --version
autom4te (GNU Autoconf) 2.72d.6-49ab3-dirty (subsecond timestamps supported)
Copyright (C) 2023 Free Software Foundation, Inc.
[etc]

If subsecond timestamps are *not* supported, you'll get instead

autom4te (GNU Autoconf) 2.72d.6-49ab3-dirty
Copyright (C) 2023 Free Software Foundation, Inc.
[etc]

I'm not using the identifier "HiRes" because the use of Time::HiRes is an
implementation detail that could change.  For instance, if there's a third
party CPAN module that lets us get at nanosecond-resolution timestamps
*without* loss of precision due to conversion to an NV (aka IEEE double)
we could, in the future, look for that first.

The implementation is just

BEGIN
{
  our $subsecond_timestamps = 0;
  eval
    {
      require Time::HiRes;
      import Time::HiRes qw(stat);
      $subsecond_timestamps = 1;
    }
}

Jacob, can you confirm that's an accurate test, given all the things you
said earlier about ways that grepping the source code might get it wrong?

zw