Re: rhel8 test failure confirmation?

[Jacob Bachmeyer]

Zack Weinberg wrote:
> 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.

Yes, there was a bit of confusion here; not only is the FileUtils module 
synchronized between autom4te and automake, but those two are near 
"sound-alikes" as I read them.  Oops.

The issue here seems to be determining if a fix that (I think) 
originated in automake has been applied to the active autom4te.

> [...]
>
> 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.
>   

That is fine, but "[HiRes]" or "[HiResTime]" is much shorter and we 
could use it as the name of the feature regardless of the underlying 
implementation.  Characters in the first line of `autom4te --version` 
are a finite resource if we want it to fit on a standard 80-column 
terminal without wrapping.  If we need to distinguish, "[HiRes] 
[HiRes-ns]" could be used to indicate your hypothetical integer 
nanosecond-resolution timestamp support, which would indicate also 
having sub-second timestamp support.

I also suggest changing the tag, since the GNU Coding Standards call for 
the version number to be indicated by the last space, but parenthesized 
text between the name and version is supposed to be the package, so this 
would lead to:

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


Is this workable all the way around, everyone?  Or should the feature be 
indicated with another line after the license notice?  ("This autom4te 
has subsecond timestamp resolution.")  My apologies for neglecting to 
check this before suggesting a tag in the --version output.

> 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?

That will determine if (a) Time::HiRes could be loaded and (b) 
Time::HiRes::stat could be imported.  This is the same test that 
Autom{ak,4t}e::FileUtils effectively uses to use Time::HiRes::stat.  I 
believe that the import is not actually necessary (i.e. Time::HiRes 
always exported Time::HiRes::stat) but it should do no harm as long as 
any use of stat in the code is prepared to handle floating-point 
timestamps.  As long as the autom4te script and its library are 
consistent (which is the distribution's problem if they screw that up), 
this test should be accurate.


-- Jacob