Re: Which Perl versions Autoconf needs [PATCH included]

Jacob Bachmeyer <[email protected]>
Newsgroups gmane.comp.sysutils.autoconf.general
Message-ID <[email protected]>
Paul Eggert wrote:
> On 2023-03-30 06:06, Zack Weinberg wrote:
>> Are you, Jacob Bachmeyer, volunteering to maintain the Perl scripts in
>> autoconf and automake, for at least the next several years, and in
>> particular to test compatibility with these very old versions of Perl?
>
> Although testing Jacob's little patch with old Perl versions is of 
> course needed now, surely a multi-year support commitment is not 
> necessary. If that patch (along with my draft-but-not-installed 
> patches) ports Autoconf to Perl 5.6, then that should be good enough 
> for the next Autoconf release as we're not planning any substantive 
> changes before then.
>
> I agree that we should not commit Autoconf to sticking with 5.6 for 
> the next several years. We might even increase the minimum Perl 
> requirement in the very next Autoconf release if that is needed.

I also agree that legitimate reasons exist to require a Perl newer than 
5.6, or 5.8, or even newer than 5.10.  I just have yet to see one that 
actually applies to Autoconf and/or Automake.  The rationales given so 
far, of core modules in 5.10 that were available from CPAN in 5.6 (or, 
as in the case of Time::HiRes, were actually core modules in 5.8 but 
were used to purportedly justify a requirement for 5.10) have been more 
excuses than legitimate reasons.  The closest I have seen so far was the 
use of the regex \K escape in build-aux/help-extract.pl, except that the 
tool in question only needs to be run by Autoconf maintainers because 
its outputs are included in release tarballs, and there was a perfectly 
good equivalent regex previously used that my patch restored.  (I could 
rewrite that function to actually parse for backslash escapes instead of 
escaping interpolations, but I wanted to keep the patch trivial if 
possible and reinstating older code is copyright-trivial while writing 
significant new code is not.)

I also argue that Autoconf should stick to its own stated philosophy of 
testing for features rather than versions.  For Perl, this means that 
Autoconf should work if all required modules are available, whether they 
were bundled with perl, installed from CPAN, or updated from CPAN after 
being initially installed bundled with perl.


-- Jacob
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.