autoconf
[Top][All Lists]
Advanced

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

Re: Which Perl versions Autoconf needs


From: Jacob Bachmeyer
Subject: Re: Which Perl versions Autoconf needs
Date: Wed, 29 Mar 2023 21:29:30 -0500
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

Paul Eggert wrote:
On 2023-03-29 16:32, Jacob Bachmeyer wrote:

Is there anything more needed from me to get similar fixes into Autoconf?

I started to do that, by installing this:

https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=e2220ed33e69d8bc6504e3f6279894afe33a99a5

into Autoconf master on Savannah and then drafting the attached patch. However, the attached patch is not right, because some other Perl 5.10 code is now in autoconf/build-aux/help-extract.pl (and perhaps a few other places; I haven't checked). So I did not install this draft patch.

If it's easy to backport help-extract.pl (and etc.?) to older Perl then feel free to come up with an additional patch set. If not, I wouldn't worry too much. As Warren mentioned, these old Perls are getting rare on platforms that users are likely to be running Autoconf on.

I ran into this issue when testing the latest Autoconf release candidate on Solaris 10, which ships with Perl 5.8.4. Although Solaris 10 is obsolescent Oracle says they will support it through January 2024.

The excuses given in the draft patch for requiring Perl 5.10 fall flat.

Once again, Digest::SHA was installable from CPAN long before it was a core module, so its use does *not* drive a Perl version requirement. Perl is *not* Python; Perl modules are (with a few exceptions) _independent_ of the Perl core version. There is no sensible fallback for Digest::SHA---you need the module if you need the module, but the Perl version does *not* indicate its presence (distributions can package core modules separately if they want, so it could be missing, even with Perl 5.10 or later) or absence (it could have been installed from CPAN in an older Perl) or even its version (likewise, it could be updated from CPAN independently of the Perl core).

Do we need a direct configure test for "has Perl module"? AC_PERL_MODULE([Digest::SHA]) would need to execute `$PERL -e "require Digest::SHA"` and consider Digest::SHA available if that returns success. Using Perl's -M option works for most modules, but a few (such as Devel::Cover) produce effects beyond the perl process when import is called, so simply evaluating "require" is less likely to cause weirdness. (Theoretically, a module could do something when loaded with require, but those kinds of side effects are strongly discouraged. Devel::Cover creates a coverage database in the current directory when import is called, but does nothing when loaded with "require".)

While the defined-or operators and state variables are new features in Perl 5.10, they can both be trivially emulated in older Perls: defined-or can be accomplished (almost exactly) with a ternary ("defined $X ? $X : $Y" for "$X // $Y") ($X is evaluated twice in the longer form; this is trivially accommodated by putting the value into a lexical variable and using that) or (in most cases, specifically _unless_ false values must be distinguished from unset) with the ordinary or operator (e.g. "$count = $arg || 0"), and the effect of "state" can be accomplished using a closure ("{my $whatever; sub use_whatever {...} }" for "sub use_whatever { state $whatever; ...}"). This last solution is explicitly called out in perlsub as a way to get "state" variables in Perl older than 5.10, while perlop specifically explains defined-or as the related ternary form (except that the ternary form can also be an lvalue if $X and $Y are both lvalues).

That leaves \K in the regexp. The simple solution is to also revert commit db7205a8647f5c197953a60d1e86a9993e1a9dca where it was introduced. The other change in that commit (using File::Spec::Functions "for reduced clunkiness") is of debatable value; the "File::Spec->catfile" form is arguably much more clear on simple inspection. (Was "catfile" imported using File::Spec::Functions or is it a local function that somehow applies "cat" to a file? The name is ambiguous; go look...)


-- Jacob



reply via email to

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