Re: rhel8 test failure confirmation?

[Jacob Bachmeyer]

Karl Berry wrote:
>     jb> The test also guesses the location of autoconf's Perl libraries; 
>
> I'm skeptical that any "guessing" of library locations would be reliable
> enough.
>   

The guess was the two most probable locations:  /usr/share/autoconf and 
/usr/local/share/autoconf.

>     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 version matches a patten that was introduced in commit 
c737451f8c17afdb477ad0fe72f534ea837e001e on 2001-09-13 preceding 
autoconf-2.52f, and Automake currently requires autoconf-2.65 or later, 
so this should work.

Getting the single quotes away from the value without directly 
mentioning them is the purpose of the "s/^.//;s/.$//;" part of the sed 
command.  Wrapping it as "$(eval echo $(sed ...))" would have been 
another option to have the shell strip the single quotes.

> Automake and autoconf are not two independent tools. Automake completely
> relies on autoconf.
>
> It's not for me to hand down any final pronouncements, but personally I
> feel strongly that the tests should not paper over this problem by
> changing the way tests work in general. With rm -rf of the cache, or
> autoconf -f, etc. That is not what users do, so that's not what the
> tests should do, either. Such global changes could have all kinds of
> other unknown/undesirable effects on the tests.
>
> In contrast to setting the sleep value "as appropriate", which is what
> is/should be already done, so changing the conditions under which it is
> set is unlikely to cause any unforeseen additional problems.
>   

While potentially compromising the real-world validity of the testsuite 
is a legitimate concern, the fact that Automake depends on Autoconf does 
not preclude the Automake testsuite from working around Autoconf 
limitations in order to accurately test /Automake/.


-- Jacob