Re: rhel8 test failure confirmation?

[Jacob Bachmeyer]

Mike Frysinger wrote:
> On 02 Dec 2023 17:07, Jacob Bachmeyer wrote:
>   
> > Mike Frysinger wrote:
> >     
> > > On 06 Apr 2023 21:29, Jacob Bachmeyer wrote:
> > >       
> > > > Karl Berry wrote:
> > > >         
> > > > >     jb> a more thorough test would locate the autom4te script and grep it
> > > > >     for the perllibdir that was substituted when autoconf was
> > > > >     configured.
> > > > >
> > > > > I guess that would work.
> > > > >       
> > > > >           
> > > > Challenge accepted.  Here's a refined version:  (lines \-folded for email)
> > > >
> > > > if $PERL -I${autom4te_perllibdir:-$(sed -n \
> > > >               '/autom4te_perllibdir/{s/^.*|| //;s/;$//;s/^.//;s/.$//;p;q}' \
> > > >             <$(command -v autom4te))} -MAutom4te::FileUtils \
> > > >          -e 'exit defined $INC{q[Time/HiRes.pm]} ? 0 : 1'; then
> > > >    # autom4te uses Time::HiRes
> > > > else
> > > >    # autom4te does not use Time::HiRes
> > > > fi
> > > >     
> > > >         
> > > this doesn't work on systems that wrap `autom4te`.  [...]
> [...]
>
> so i don't know why we would need to set/export autom4te_perllibdir in our
> wrapper.  we've been doing this for over 20 years without ever setting that
> var (or any other internal autoconf/automake var), so i'm pretty confident
> our approach is OK.
>   

No, not in the wrapper---in the automake ebuild script that runs 
configure to match the autom4te that the wrapper will run.  That test I 
proposed checks for autom4te_perllibdir in the environment before 
extracting it from autom4te precisely so distributions like Gentoo would 
have a knob to turn if their packaging breaks that test.

That said, it turns out that this whole line of discussion is now a red 
herring; see below.

> [...]
> i'm not aware of anything loading the Autom4te perl modules outside of the
> autoconf projects.  does that actually happen ?  i don't think we want to
> have automake start loading autoconf perl modules directly.  going through
> the CLI interface seems better at this point.

Autoconf and Automake are very closely associated; there is even some 
shared code that is synchronized between them.  Autom4te::FileUtils is 
also Automake::FileUtils, for example.

The test we are discussing here was intended for Automake's configure 
script to use to check if the installed Autoconf has high-resolution 
timestamp support.  It turned out that the test I wrote can give a false 
positive, as some versions of other dependencies of Autom4te::FileUtils 
/also/ use Time::HiRes, causing the test to correctly report that 
Time::HiRes was loaded, but Autom4te::FileUtils nonetheless does not 
actually use it.  The test could probably be improved to fix the false 
positives, but that would be getting into deep magic in Perl that might 
not be fully reliable across Perl versions.  (It would be necessary to 
determine if (a) Time::HiRes::stat exists and (b) 
Autom4te::FileUtils::stat is an alias to it.  Having configure build a 
special XSUB just to check this is well into "ridiculous" territory.)

As such, the Automake maintainers replaced this particular test with a 
simpler test that just locates Autom4te/FileUtils.pm and greps it for 
"Time::HiRes", thus the error message you received, which initially had 
me confused because the test I proposed cannot produce that message as 
it does not use grep.

An important bit of context to keep in mind is that I am not certain 
that timestamp resolution is still a problem outside of the Automake and 
Autoconf testsuites, since Autoconf and Automake now require cache files 
to actually be newer than their sources and consider the cache files 
stale if the timestamps are equal.  This is a problem for the testsuite 
because the testsuite is supposed to actually exercise the caching 
mechanism, and higher-resolution timestamps can significantly reduce the 
amount of time required to run the tests by reducing the delays needed 
to ensure the caches will be valid.


-- Jacob