Re: rhel8 test failure confirmation?

[Bogdan]

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.

 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?



> > [...]
> > It seems to me that using autoconf -f or similar is papering over the
> > problem, so that the tests are no longer testing the normal behavior.
> > Which does not sound desirable.
>
> The Automake testsuite is supposed to test Automake, not Autoconf, so 
> working around Autoconf issues is appropriate.


 I agree with this one, too. Don't do workarounds in tests to fix 
Automake issues, just fix the issue in Automake :). But workarounds, 
conditional code, skipping tests, etc. are allowed when using other 
tools in Automake tests.


>   In this case, if 
> always using "autoconf -f" allows us to eliminate the sleeps entirely 
> (and does not expand the running time of Autoconf too much), we should 
> do that, at least in my view.


 Yes, that could be the simplest. I (or someone) just need to find 
out how to time individual tests (or maybe I'll just run 'time make 
check TESTS=...') and do the actual measurements :).
 I was hoping to have more time for this, but unfortunately, I got 
busy with other things and this may have to wait a bit. Maybe this 
week, maybe the next...


--
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org