Re: rhel8 test failure confirmation?

[Jacob Bachmeyer]

Bogdan wrote:
> Jacob Bachmeyer <jcb62281@gmail.com>, Mon Apr 03 2023 06:16:53 
> GMT+0200 (Central European Summer Time)
> > Karl Berry wrote:
> > > [...]
> > >    What can we do about this?
> > >
> > > As for automake: can we (you :) somehow modify the computation of the
> > > sleep value to determine if autom4te can handle the HiRes testing or 
> > > not
> > > (i.e., has the patch installed)? And then use the longer sleep in
> > > automake testing if needed.
> >
> > If you can locate Autom4te::FileUtils, grepping it for "Time::HiRes" 
> > will tell you if autom4te supports sub-second timestamps, but then 
> > you need more checks to validate that the filesystem actually has 
> > sub-second timestamps.
> >
> > A simple check:
> >
> > if $PERL -I${autom4te_perllibdir:-/usr/share/autoconf} 
> > -I/usr/local/share/autoconf \
> >         -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 method also has the advantage of implicitly also checking that 
> > $PERL has Time::HiRes installed by determining if loading 
> > Autom4te::FileUtils causes Time::HiRes to be loaded.  (In other 
> > words, this will give the correct answer on Perl 5.6 if Time::HiRes 
> > was installed from CPAN or on later Perls if a distribution packager 
> > has unbundled Time::HiRes and the user has not installed its package.)
>
>
>  Nice. The 0 and 1 may not be portable to each OS in the Universe (see 
> EXIT_SUCCESS and EXIT_FAILURE in exit(3)), but should be good/portable 
> enough for our goals. Or maybe some other simple solution.

Generally, "exit 0" reports success to the shell and any other exit 
value is taken as false.  I am unsure if POSIX actually requires that, 
however.

>  As I understand, this could even be used to actually call the sub 
> which checks the timestamps, so we'd have a read-to-use test. Only a 
> matter of where to put it... Is there some code that runs *before* all 
> tests that could set some environment variable passed to the tests, 
> create a file, or whatever?

The intended implication was that that test would go in configure.

Verifying that the filesystem actually /has/ subsecond timestamps is a 
separate issue; that test only detects whether autom4te will use 
subsecond timestamps /if/ they are available.

The test also guesses the location of autoconf's Perl libraries; a more 
thorough test would locate the autom4te script and grep it for the 
perllibdir that was substituted when autoconf was configured.


-- Jacob