Re: Which Perl versions Autoconf needs

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