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
