automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rhel8 test failure confirmation?


From: Jacob Bachmeyer
Subject: Re: rhel8 test failure confirmation?
Date: Sat, 02 Dec 2023 17:07:46 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0

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`.  Gentoo for example wraps
all autoconf & automake scripts to support parallel installs of different
versions.  this way we can easily have access to every autoconf version.  we
got this idea from Mandrake, so we aren't the only ones ;).

If you install a wrapper script, (instead of, for example, making autom4te, etc. easily-repointable symlinks), then you must also set autom4te_perllibdir in the environment to the appropriate directory when building autoconf/automake. This (with the Gentoo-specific knowledge of where the active autom4te is actually located) should be easy to add to the ebuild.

If autom4te_perllibdir is set in the environment, its value will be used instead of extracting that information from the autom4te script.

[...]

seems like the only reliable option is to invoke autom4te.
        am_autom4te_ver=`$AUTOM4TE --version | sed -n '1{s:.*) ::;p}'
        AS_CASE([$am_autom4te_ver],
        ... do the matching ...

what is the first autoconf release that has the fix ?

The problem with testing autoconf versions for this is that Time::HiRes is an *optional* module in Perl. It was available from CPAN before it was bundled with Perl, and distributions technically can *unbundle* it from later Perl releases if they want. The only reliable way to know if Time::HiRes is available (without effectively reimplementing Perl's module search) is to try to load it. Autom4te now (correctly) uses Time::HiRes if it is available and falls back to Perl builtins if not, for any version of Perl. The best way to check if high-resolution timestamps are available to autom4te is to have perl load Autom4te::FileUtils and check if that also loaded Time::HiRes.


-- Jacob




reply via email to

[Prev in Thread] Current Thread [Next in Thread]