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`. 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
symlinks are vastly inferior. they require privilege to modify, are not atomic,
and bleed into the rest of the system and other users. the wrappers we have in
Gentoo on the otherhand respect env vars (so you can e.g. WANT_AUTOCONF=2.53),
and by default scan the current set of generated files to see what was used, and
then see what's installed to automatically match. so if you're running automake
in a project built with automake 1.11 and you have that installed, we will use
it automatically for you. or you can force WANT_AUTOMAKE=latest to always use
the latest version.
> 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.
when e.g. autoconf 2.69 is built to use versioned paths at configure, compile,
and install time, there is no need to muck around with internal vars like the
autom4te_perllibdir. `autoconf-2.69` & `autom4te-2.69` always invokes exactly
the 2.69 version regardless of what `autoconf` does.
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.
> > 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.
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.
-mike
signature.asc
Description: PGP signature
