GNU bug report logs - #61240
improve high-res file timestamp in Automake

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 61240 in the body.
You can then email your comments to 61240 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: automake-patches <at> gnu.org
Subject: improve high-res file timestamp in Automake
Date: Thu, 2 Feb 2023 14:24:59 -0800

[Message part 1 (text/plain, inline)]

I installed the attached to port a FileUtils.pm patch back from Autoconf 
into Automake. I wish Perl supported file timestamps with nanosecond 
resolution, but apparently not, so this is the best we could do easily.

Although this bumps the required Perl version from 5.6 (2000) to 5.10 
(2007), I don't think that's a problem nowadays.

[0001-maint-require-perl-5.010-or-later.patch (text/x-patch, attachment)]

[0002-Use-higher-resolution-file-timestamps.patch (text/x-patch, attachment)]

Message #10 received at 61240 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 61240 <at> debbugs.gnu.org
Subject: Re: [bug#61240] improve high-res file timestamp in Automake
Date: Fri, 03 Feb 2023 20:27:29 -0600

Paul Eggert wrote:
> I installed the attached to port a FileUtils.pm patch back from 
> Autoconf into Automake. I wish Perl supported file timestamps with 
> nanosecond resolution, but apparently not, so this is the best we 
> could do easily.
>
> Although this bumps the required Perl version from 5.6 (2000) to 5.10 
> (2007), I don't think that's a problem nowadays.

Where are you actually using a 5.10 feature?  Please do not arbitrarily 
bump version requirements just to bump version requirements.


-- Jacob

Message #13 received at 61240 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: jcb62281 <at> gmail.com
Cc: 61240 <at> debbugs.gnu.org
Subject: Re: [bug#61240] improve high-res file timestamp in Automake
Date: Fri, 3 Feb 2023 19:03:47 -0800

On 2023-02-03 18:27, Jacob Bachmeyer wrote:
> Where are you actually using a 5.10 feature?

Where lib/Automake/FileUtils.pm says "use Time::HiRes qw(stat);". This 
does not work with Perl 5.6.

For why we bumped the version to 5.10, please see:

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

> Please do not arbitrarily bump version requirements just to bump version requirements.

That's not what was done here. The abovementioned URL says version 
requirements were bumped from 5.6 to 5.10 because the feature is not 
present in 5.6 (2000), is present in 5.10 (2007), and we lacked access 
to the museum pieces in the middle. If you are sure that a version 
number lower than 5.10 will do, please let us know.

Message #16 received at 61240 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 61240 <at> debbugs.gnu.org
Subject: Re: [bug#61240] improve high-res file timestamp in Automake
Date: Sat, 04 Feb 2023 18:02:56 -0600

Paul Eggert wrote:
> On 2023-02-03 18:27, Jacob Bachmeyer wrote:
>> Where are you actually using a 5.10 feature?
>
> Where lib/Automake/FileUtils.pm says "use Time::HiRes qw(stat);". This 
> does not work with Perl 5.6.

Time::HiRes is (perhaps was) installable from CPAN and is definitely 
/not/ a 5.10 feature.  I have a Perl 5.8 with it installed, and while my 
memories that far back are a bit fuzzy, I seem to remember installing 
Time::HiRes on a Perl 5.6 installation some years ago.  Things like 
"our" variables, PerlIO-by-default, and the defined-or operator are Perl 
features (those in 5.6, 5.8, and 5.10 if I remember correctly), modules 
are (with rare exceptions) not Perl features.

The correct solution if you do not want to provide for the case where 
Time::HiRes is not available is to simply "use Time::HiRes qw(stat);" 
and *let* *that* *fail* if Time::HiRes is not available or cannot export 
stat().  Time::HiRes was on CPAN long before it was bundled with Perl, 
so the Perl version does /not/ tell you if it is available.  (If 
Automake::FileUtils is not immediately loaded, put "use Time::HiRes;" 
somewhere that is.  That will be enough to ensure that Time::HiRes is 
available.)

> For why we bumped the version to 5.10, please see:
>
> https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=61901a1a14fd50c03cfb1529d091554376fef286 
>
>
>> Please do not arbitrarily bump version requirements just to bump 
>> version requirements.
>
> That's not what was done here. The abovementioned URL says version 
> requirements were bumped from 5.6 to 5.10 because the feature is not 
> present in 5.6 (2000), is present in 5.10 (2007), and we lacked access 
> to the museum pieces in the middle. If you are sure that a version 
> number lower than 5.10 will do, please let us know.

This was arbitrary because Time::HiRes is not actually dependent on the 
Perl version in that way.  (You should also be able to get access to the 
museum pieces in the middle fairly easily using perlbrew.)

I am fairly sure that Time::HiRes could be installed from CPAN on at 
least Perl 5.6 and later, and possibly even on Perls older than 5.6.  
(To add it to a 5.6 installation today may require retrieving it from 
BackPAN.)  I definitely know that it can be installed on 5.8, as I still 
have a Perl 5.8 that has it, and "use Time::HiRes qw(stat);" succeeds in 
that Perl.  If the requirement is Time::HiRes, then the proper course of 
action is to "require Time::HiRes;" rather than requiring some version 
of Perl that you know shipped it as a core module.  Doing the latter 
/is/ arbitrarily bumping the version requirement.

In fact, according to my copy of Module::CoreList (or, to be precise, 
its corelist(1) command-line frontend), Time::HiRes was first bundled 
with Perl 5.7.3.  Note that I ran that query against a Perl 5.34 
installation; the Perl community takes backwards compatibility like this 
very seriously.  Note also that I said "bundled"; it could be installed 
from CPAN in older Perls, so requiring 5.8 (since 5.7 was a development 
series) is /not/ correct here.

There are also the no-runtime-overhead options of using "eval { use 
Time::HiRes qw(stat) };" which will replace stat() with the hi-res 
version if it is available and continue with the regular stat() builtin 
if not, or "use constant HAVE_Time_HiRes => eval { use Time::HiRes };" 
and a conditional "if (HAVE_Time_HiRes) { ... } else { ... }" as I 
suggested as an improvement to Mike Frysinger's patch.

In any case, you will still need to account for the possibility that 
Time::HiRes::stat() might not actually have higher resolution, depending 
on the filesystem.  FAT, in particular, is notorious for its 2-second 
timestamp resolution.  (This issue is actually mentioned in the 
Time::HiRes::stat documentation.)


-- Jacob

Message #19 received at 61240 <at> debbugs.gnu.org (full text, mbox):

From: Sam James <sam <at> cmpct.info>
To: jcb62281 <at> gmail.com
Cc: 61240 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: [bug#61240] improve high-res file timestamp in Automake
Date: Sun, 5 Feb 2023 00:06:00 +0000

[Message part 1 (text/plain, inline)]

> On 5 Feb 2023, at 00:02, Jacob Bachmeyer <jcb62281 <at> gmail.com> wrote:
> 
> Paul Eggert wrote:
>> On 2023-02-03 18:27, Jacob Bachmeyer wrote:
>>> Where are you actually using a 5.10 feature?
>> 
>> Where lib/Automake/FileUtils.pm says "use Time::HiRes qw(stat);". This does not work with Perl 5.6.
> 
> Time::HiRes is (perhaps was) installable from CPAN and is definitely /not/ a 5.10 feature.  I have a Perl 5.8 with it installed, and while my memories that far back are a bit fuzzy, I seem to remember installing Time::HiRes on a Perl 5.6 installation some years ago.  Things like "our" variables, PerlIO-by-default, and the defined-or operator are Perl features (those in 5.6, 5.8, and 5.10 if I remember correctly), modules are (with rare exceptions) not Perl features.
> 
> The correct solution if you do not want to provide for the case where Time::HiRes is not available is to simply "use Time::HiRes qw(stat);" and *let* *that* *fail* if Time::HiRes is not available or cannot export stat().  Time::HiRes was on CPAN long before it was bundled with Perl, so the Perl version does /not/ tell you if it is available.  (If Automake::FileUtils is not immediately loaded, put "use Time::HiRes;" somewhere that is.  That will be enough to ensure that Time::HiRes is available.)
> 
>> For why we bumped the version to 5.10, please see:
>> 
>> https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=61901a1a14fd50c03cfb1529d091554376fef286
>> 
>>> Please do not arbitrarily bump version requirements just to bump version requirements.
>> 
>> That's not what was done here. The abovementioned URL says version requirements were bumped from 5.6 to 5.10 because the feature is not present in 5.6 (2000), is present in 5.10 (2007), and we lacked access to the museum pieces in the middle. If you are sure that a version number lower than 5.10 will do, please let us know.
> 
> This was arbitrary because Time::HiRes is not actually dependent on the Perl version in that way.  (You should also be able to get access to the museum pieces in the middle fairly easily using perlbrew.)

I think you probably mean "a mistake" rather than "arbitrary". He didn't choose it for no reason or for fun.

[signature.asc (application/pgp-signature, attachment)]

Message #22 received at 61240 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: jcb62281 <at> gmail.com
Cc: 61240 <at> debbugs.gnu.org
Subject: Re: [bug#61240] improve high-res file timestamp in Automake
Date: Sat, 4 Feb 2023 17:56:05 -0800

On 2023-02-04 16:02, Jacob Bachmeyer wrote:
> In any case, you will still need to account for the possibility that 
> Time::HiRes::stat() might not actually have higher resolution, depending 
> on the filesystem.

That's fine. All we want is the exact file timestamp. If the file system 
timestamp resolution is only 2 s, then we want that multiple of 2. 
Admittedly we can't get the exact file timestamp on many modern file 
systems since Time::HiRes is precise only to the nearest ~238 ns for 
today's timestamps, but the idea is to get what we easily can.


> There are also the no-runtime-overhead options of using "eval { use Time::HiRes qw(stat) };" which will replace stat() with the hi-res version if it is available and continue with the regular stat() builtin if not, or "use constant HAVE_Time_HiRes => eval { use Time::HiRes };" and a conditional "if (HAVE_Time_HiRes) { ... } else { ... }" as I suggested as an improvement to Mike Frysinger's patch. 

Sorry, I don't remember seeing that suggestion. I guess it was in 
another thread. Could you resend that patch to 61240 <at> debbugs.gnu.org and 
cc me? Preferably a patch against the latest Automake, in "git 
format-patch" format; see <https://savannah.gnu.org/git/?group=automake> 
for how to get bleeding-edge Automake. The idea would be to port 
bleeding-edge Automake to Perl < 5.10 when that's easy.

Please bear in mind that I stopped coding in Perl 30 years ago and so am 
a bit rusty.

Message #25 received at 61240 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 61240 <at> debbugs.gnu.org
Subject: Re: [bug#61240] improve high-res file timestamp in Automake
Date: Sun, 05 Feb 2023 19:14:08 -0600

Paul Eggert wrote:
> On 2023-02-04 16:02, Jacob Bachmeyer wrote:
>> In any case, you will still need to account for the possibility that 
>> Time::HiRes::stat() might not actually have higher resolution, 
>> depending on the filesystem.
>
> That's fine. All we want is the exact file timestamp. If the file 
> system timestamp resolution is only 2 s, then we want that multiple of 
> 2. Admittedly we can't get the exact file timestamp on many modern 
> file systems since Time::HiRes is precise only to the nearest ~238 ns 
> for today's timestamps, but the idea is to get what we easily can.

How often is Perl built to use long doubles these days?  (That was an 
option beginning with Perl 5.6.)

>> There are also the no-runtime-overhead options of using "eval { use 
>> Time::HiRes qw(stat) };" which will replace stat() with the hi-res 
>> version if it is available and continue with the regular stat() 
>> builtin if not, or "use constant HAVE_Time_HiRes => eval { use 
>> Time::HiRes };" and a conditional "if (HAVE_Time_HiRes) { ... } else 
>> { ... }" as I suggested as an improvement to Mike Frysinger's patch. 
>
> Sorry, I don't remember seeing that suggestion. I guess it was in 
> another thread. Could you resend that patch to 61240 <at> debbugs.gnu.org 
> and cc me? Preferably a patch against the latest Automake, in "git 
> format-patch" format; see 
> <https://savannah.gnu.org/git/?group=automake> for how to get 
> bleeding-edge Automake. The idea would be to port bleeding-edge 
> Automake to Perl < 5.10 when that's easy.

It was bug#60807.  Looking at the patch, I suspect that I will need to 
take a closer look at the code:  the existing code before Mike's patch 
used File::stat, which I suspect may not be compatible with 
Time::HiRes::stat (not compatible in the sense that File::stat's 
override of stat() probably will not use Time::HiRes's override of 
stat()).  If so, then "use Time::HiRes qw(stat);" will not do what you 
want because either stat() will either cease to return an object or will 
not have subsecond resolution.

Looking at the code, commit 01bf65daf6f6627b56fbe78fc436fd877ccd3537 
appears fine, all I am asking is that commit 
4e3744a15c4d8bdb46c11ead2fb56c5f591b714b be reverted.  The current 
Automake Git master should actually work on Perl 5.6 if Time::HiRes has 
been installed, which was possible with 5.6 although it was bundled with 
Perl beginning with the 5.7.3 development release.

In other words, bleeding-edge Automake is already ported to Perl < 5.10, 
in fact it should run on 5.8 out-of-the-box and 5.6 if Time::HiRes has 
been installed from CPAN (or perhaps BackPAN today, but Time::HiRes was 
on CPAN when 5.6 was current).

> Please bear in mind that I stopped coding in Perl 30 years ago and so 
> am a bit rusty.

Yes, very---30 years ago would have been before Perl 5.6!  Much of 
modern Perl did not exist then...


-- Jacob

Message #28 received at 61240 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: jcb62281 <at> gmail.com
Cc: 61240 <at> debbugs.gnu.org
Subject: Re: [bug#61240] improve high-res file timestamp in Automake
Date: Sun, 5 Feb 2023 19:08:07 -0800

On 2023-02-05 17:14, Jacob Bachmeyer wrote:

> How often is Perl built to use long doubles these days?  (That was an 
> option beginning with Perl 5.6.)

I doubt it's used much. It's not used in Ubuntu or Fedora, for what it's 
worth. And on some platforms (e.g., macOS on current Apple silicon) 
-Duselongdouble doesn't matter because long double is the same as double.

Besides, although it's too bad that Perl can't represent file timestamps 
precisely, that's not something Autoconf can fix.


> Looking at the code, commit 01bf65daf6f6627b56fbe78fc436fd877ccd3537 
> appears fine, all I am asking is that commit 
> 4e3744a15c4d8bdb46c11ead2fb56c5f591b714b be reverted.  The current 
> Automake Git master should actually work on Perl 5.6 if Time::HiRes has 
> been installed, which was possible with 5.6 although it was bundled with 
> Perl beginning with the 5.7.3 development release.

Unfortunately the Perl version bump was prompted by evidence in the 
field that without making it clear that bare Perl 5.6 does not suffice, 
Autoconf and Automake fail in ways that are mysterious to their users. 
We can't expect people to install extensions in Perl 5.6 to work around 
this problem. We must make things simple and easy for installers and 
users to understand. Particularly since these are old Perl versions that 
Autoconf and Automake users are unlikely to be running (people who use 
bleeding-edge Autoconf and Automake almost invariably run recent Perl).

It would be OK to go back to requiring only 5.6 if we can write 
conditionalized code that works with 5.6 but with lower-res timestamps, 
and quietly switches to higher-res timestamps if available and works 
fine when they are available. Autoconf and Automake should not rely on 
users installing optional Perl packages or dealing with Perl's 
diagnostics when the optional stuff is missing: the code must work out 
of the box with no expertise required.

Can you write an Automake patch to do that, and test it on old Perl 
installations? 'git format-patch' form preferred. I don't have access to 
ancient Perl and am a bit squeezed for time, so I'm afraid this will 
need to be done by a Perl expert such as yourself.

Message #31 received at 61240 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 61240 <at> debbugs.gnu.org
Subject: Re: [bug#61240] improve high-res file timestamp in Automake
Date: Sun, 05 Feb 2023 23:43:21 -0600

Paul Eggert wrote:
> On 2023-02-05 17:14, Jacob Bachmeyer wrote:
>
> [...]
>> Looking at the code, commit 01bf65daf6f6627b56fbe78fc436fd877ccd3537 
>> appears fine, all I am asking is that commit 
>> 4e3744a15c4d8bdb46c11ead2fb56c5f591b714b be reverted.  The current 
>> Automake Git master should actually work on Perl 5.6 if Time::HiRes 
>> has been installed, which was possible with 5.6 although it was 
>> bundled with Perl beginning with the 5.7.3 development release.
>
> Unfortunately the Perl version bump was prompted by evidence in the 
> field that without making it clear that bare Perl 5.6 does not 
> suffice, Autoconf and Automake fail in ways that are mysterious to 
> their users. We can't expect people to install extensions in Perl 5.6 
> to work around this problem. We must make things simple and easy for 
> installers and users to understand. Particularly since these are old 
> Perl versions that Autoconf and Automake users are unlikely to be 
> running (people who use bleeding-edge Autoconf and Automake almost 
> invariably run recent Perl).

I believe the proper autoconf solution would be for configure to verify 
that "$PERL -MTime::HiRes -e 1" completes successfully (that is, that 
$PERL has the Time::HiRes module available) and fail with a diagnostic 
that Time::HiRes is required if not, perhaps noting that Time::HiRes was 
bundled beginning with Perl 5.8.  (The 5.7 series were development 
releases.)

Note that the real requirement here is not a given Perl version, but the 
Time::HiRes module (solution to that below), so checking the Perl 
version is incorrect here.  Even though Perl 5.8 and later have 
Time::HiRes bundled, it is still a module and it is possible for a 
distribution package builder to separate Time::HiRes from the main perl 
package, so there is no guarantee that Time::HiRes will actually be 
available unless you explicitly test for it.  I doubt that any major 
distribution currently does this with Time::HiRes, but the Perl version 
does not actually imply the availability of any given module.

> It would be OK to go back to requiring only 5.6 if we can write 
> conditionalized code that works with 5.6 but with lower-res 
> timestamps, and quietly switches to higher-res timestamps if available 
> and works fine when they are available. Autoconf and Automake should 
> not rely on users installing optional Perl packages or dealing with 
> Perl's diagnostics when the optional stuff is missing: the code must 
> work out of the box with no expertise required.

I believe that is quite easy to do:

   BEGIN { eval { require Time::HiRes; Time::HiRes->import('stat') } }

instead of:

   use Time::HiRes qw(stat);

In Perl, "use Module LIST" is shorthand for "BEGIN { require Module; 
import Module LIST; }", so the above could also be written as "BEGIN { 
eval { require Time::HiRes; import Time::HiRes qw(stat) } }" if you 
wanted, although the direct package method call is a more common style.

If Time::HiRes is available, that will transparently replace stat() with 
Time::HiRes::stat(); if not, processing continues using the basic 
stat(), since require throws an exception immediately if it fails, which 
the eval BLOCK will catch.  This has the advantage of testing for the 
specific feature, and will give high-resolution timestamps even on 5.6 
if Time::HiRes is installed and basic timestamps otherwise.

Since Perl 5.8 and later all have Time::HiRes bundled, the import should 
succeed and high resolution timestamps will be available.  I say 
/should/ because it is possible for distribution packagers to separate 
bundled modules out from their main perl packages, as I mentioned above.

> Can you write an Automake patch to do that, and test it on old Perl 
> installations? 'git format-patch' form preferred. I don't have access 
> to ancient Perl and am a bit squeezed for time, so I'm afraid this 
> will need to be done by a Perl expert such as yourself.

The oldest Perl I normally use is a 5.8 installation from source that 
has (bundled) Time::HiRes, so I have perlbrew cooking up a 5.6.2 to test 
the fallback as I write this.

Should the patch be relative to commit 
6d6fc91c472fd84bd71a1b012fa9ab77bd94efea (before the version requirement 
bump) or should it include reverting commit 
4e3744a15c4d8bdb46c11ead2fb56c5f591b714b (the version requirement bump)?


-- Jacob

Message #34 received at 61240 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: jcb62281 <at> gmail.com
Cc: 61240 <at> debbugs.gnu.org
Subject: Re: [bug#61240] improve high-res file timestamp in Automake
Date: Sun, 5 Feb 2023 21:53:32 -0800

On 2023-02-05 21:43, Jacob Bachmeyer wrote:
> 
> Should the patch be relative to commit 
> 6d6fc91c472fd84bd71a1b012fa9ab77bd94efea (before the version requirement 
> bump) or should it include reverting commit 
> 4e3744a15c4d8bdb46c11ead2fb56c5f591b714b (the version requirement bump)?

Might as well do it all at once, thanks.

Message #37 received at 61240 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 61240 <at> debbugs.gnu.org
Subject: Re: [bug#61240] [PATCH 0/2] restore support for 5.6 and gracefully
 degrade timestamps
Date: Tue, 07 Feb 2023 23:28:27 -0600

Paul Eggert wrote:
> On 2023-02-05 21:43, Jacob Bachmeyer wrote:
>> Should the patch be relative to commit 
>> 6d6fc91c472fd84bd71a1b012fa9ab77bd94efea (before the version 
>> requirement bump) or should it include reverting commit 
>> 4e3744a15c4d8bdb46c11ead2fb56c5f591b714b (the version requirement bump)?
>
> Might as well do it all at once, thanks.

Two patches, generated with git format-patch as requested, follow under 
separate cover.

I had to rework my local repository, where I had previously rolled back 
to before the version requirement bump instead of reverting it.  Using 
"git diff" confirms no differences between the two local branch tips, so 
I am sending in the patch now while tests continue to run here.  Patch 1 
reverts the version requirement bump; patch 2 allows Automake to 
gracefully degrade if Time::HiRes is not available.

While Automake clearly works correctly under Perl 5.6.2 with these 
patches applied, I am still running down some minor testsuite result 
differences between the system Perl 5.34.1 and perlbrew Perl 5.6.2 on 
the machine I am using for the tests.  Should patches to correct these 
issues be sent under this bug or should they be sent separately to 
automake-patches?

Preliminary analysis suggests that the Perl fragment in 
t/ax/am-test-lib.sh:is_blocked_signal needs a few improvements (to 
improve compatibility in both directions; an accessor method was 
introduced in Perl 5.8 and the code fails under Perl 5.6 due to other 
limitations; [*facepalm*]), and t/pm/General.pl appears to be tickling a 
compiler bug in Perl 5.6.2 that produces a false syntax error, but 
Automake itself is unaffected.  The only other differences are 
t/pm/Condition-t.pl and t/pm/DisjConditions-t.pl, which are skipped due 
to a lack of the required thread support in the older Perl.  The failure 
of is_blocked_signal causes ERRORs in t/parallel-tests-interrupt.tap, 
t/self-check-exit.tap, t/self-check-is-blocked-signal.tap, and 
t/tap-signal.tap.  No other tests FAIL with either Perl.

I also found that t/get-sysconf.sh FAILs if libtool is not installed, 
but configure does not detect and complain about the unavailability of 
libtoolize.


-- Jacob

Message #40 received at 61240 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 61240 <at> debbugs.gnu.org
Subject: Re: [bug#61240] [PATCH 1/2] revert Perl version requirement bump
Date: Tue, 07 Feb 2023 23:28:59 -0600

Paul Eggert wrote:
> On 2023-02-05 21:43, Jacob Bachmeyer wrote:
>> Should the patch be relative to commit 
>> 6d6fc91c472fd84bd71a1b012fa9ab77bd94efea (before the version 
>> requirement bump) or should it include reverting commit 
>> 4e3744a15c4d8bdb46c11ead2fb56c5f591b714b (the version requirement bump)?
>
> Might as well do it all at once, thanks.

This first patch is simply `git revert 4e3744`.

8<------
From: Jacob Bachmeyer <jcb <at> gnu.org>
Date: Tue, 7 Feb 2023 22:39:29 -0600
Subject: [PATCH 1/2] Revert "maint: require perl 5.010 or later"

This reverts commit 4e3744a15c4d8bdb46c11ead2fb56c5f591b714b.
---
NEWS                           |    6 +-----
bin/aclocal.in                 |    2 +-
bin/automake.in                |    2 +-
configure.ac                   |    5 +++--
lib/Automake/ChannelDefs.pm    |    2 +-
lib/Automake/Channels.pm       |    2 +-
lib/Automake/Condition.pm      |    2 +-
lib/Automake/Config.in         |    2 +-
lib/Automake/Configure_ac.pm   |    2 +-
lib/Automake/DisjConditions.pm |    2 +-
lib/Automake/FileUtils.pm      |    2 +-
lib/Automake/General.pm        |    2 +-
lib/Automake/Getopt.pm         |    2 +-
lib/Automake/Item.pm           |    2 +-
lib/Automake/ItemDef.pm        |    2 +-
lib/Automake/Language.pm       |    2 +-
lib/Automake/Location.pm       |    2 +-
lib/Automake/Options.pm        |    2 +-
lib/Automake/Rule.pm           |    2 +-
lib/Automake/RuleDef.pm        |    2 +-
lib/Automake/VarDef.pm         |    2 +-
lib/Automake/Variable.pm       |    2 +-
lib/Automake/Version.pm        |    2 +-
lib/Automake/Wrap.pm           |    2 +-
lib/Automake/XFile.pm          |    2 +-
25 files changed, 27 insertions(+), 30 deletions(-)

diff --git a/NEWS b/NEWS
index cb32564..8cba8b3 100644
--- a/NEWS
+++ b/NEWS
@@ -5,10 +5,6 @@ please see NEWS-2.0 and start following the advice there now.

New in 1.17:

-* Version requirements:
-
-  - Perl 5.10 (2007) or greater is required.
-
* New features added

  - RANLIB may be overridden on a per-target basis.
@@ -40,7 +36,7 @@ New in 1.17:
    and -Q is not used, since its support and behavior varies.

  - Emacs Lisp compilations respects silent make output.
-
+  
  - distcleancheck ignores "silly rename" files (.nfs* .smb* .__afs*)
    that can show up on network file systems.

diff --git a/bin/aclocal.in b/bin/aclocal.in
index 34c2530..f04cb30 100644
--- a/bin/aclocal.in
+++ b/bin/aclocal.in
@@ -19,7 +19,7 @@
# Written by Tom Tromey <tromey <at> redhat.com>, and
# Alexandre Duret-Lutz <adl <at> gnu.org>.

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/bin/automake.in b/bin/automake.in
index afd296a..139d5ad 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -22,7 +22,7 @@

package Automake;

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/configure.ac b/configure.ac
index bf72023..dcf2d95 100644
--- a/configure.ac
+++ b/configure.ac
@@ -73,9 +73,10 @@ if test -z "$PERL"; then
fi
# Save details about the selected perl interpreter in config.log.
AM_RUN_LOG([$PERL --version])
-$PERL -e 'require 5.010;' || {
+$PERL -e 'require 5.006;' || {
   AC_MSG_ERROR(
-[perl 5.10 (2007) or better is required.  If you have several perl versions
+[perl 5.6 or better is required; perl 5.8.2 or better
+is recommended.  If you have several perl versions
installed, select the one Automake should use using
  ./configure PERL=/path/to/perl])
}
diff --git a/lib/Automake/ChannelDefs.pm b/lib/Automake/ChannelDefs.pm
index bfe5ba5..1c43664 100644
--- a/lib/Automake/ChannelDefs.pm
+++ b/lib/Automake/ChannelDefs.pm
@@ -44,7 +44,7 @@ shorthand function to output on specific channels.

=cut

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/Channels.pm b/lib/Automake/Channels.pm
index 5a36c93..b4563d3 100644
--- a/lib/Automake/Channels.pm
+++ b/lib/Automake/Channels.pm
@@ -66,7 +66,7 @@ etc.) that can also be overridden on a per-message basis.

=cut

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/Condition.pm b/lib/Automake/Condition.pm
index d1e6811..31ac81d 100644
--- a/lib/Automake/Condition.pm
+++ b/lib/Automake/Condition.pm
@@ -15,7 +15,7 @@

package Automake::Condition;

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/Config.in b/lib/Automake/Config.in
index 3cc094d..4fc918b 100644
--- a/lib/Automake/Config.in
+++ b/lib/Automake/Config.in
@@ -17,7 +17,7 @@

package Automake::Config;

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/Configure_ac.pm b/lib/Automake/Configure_ac.pm
index d4751ee..efd428e 100644
--- a/lib/Automake/Configure_ac.pm
+++ b/lib/Automake/Configure_ac.pm
@@ -20,7 +20,7 @@

package Automake::Configure_ac;

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/DisjConditions.pm b/lib/Automake/DisjConditions.pm
index 7612f60..16540e7 100644
--- a/lib/Automake/DisjConditions.pm
+++ b/lib/Automake/DisjConditions.pm
@@ -15,7 +15,7 @@

package Automake::DisjConditions;

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/FileUtils.pm b/lib/Automake/FileUtils.pm
index 6e9796a..697ff7e 100644
--- a/lib/Automake/FileUtils.pm
+++ b/lib/Automake/FileUtils.pm
@@ -34,7 +34,7 @@ This perl module provides various general purpose file handling functions.

=cut

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/General.pm b/lib/Automake/General.pm
index 4b97750..4c1d063 100644
--- a/lib/Automake/General.pm
+++ b/lib/Automake/General.pm
@@ -15,7 +15,7 @@

package Automake::General;

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/Getopt.pm b/lib/Automake/Getopt.pm
index 3b37d64..67958fd 100644
--- a/lib/Automake/Getopt.pm
+++ b/lib/Automake/Getopt.pm
@@ -30,7 +30,7 @@ line options in conformance to the GNU Coding standards.

=cut

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/Item.pm b/lib/Automake/Item.pm
index a2e6c14..a2637c6 100644
--- a/lib/Automake/Item.pm
+++ b/lib/Automake/Item.pm
@@ -15,7 +15,7 @@

package Automake::Item;

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/ItemDef.pm b/lib/Automake/ItemDef.pm
index ca9bbb1..3e958a8 100644
--- a/lib/Automake/ItemDef.pm
+++ b/lib/Automake/ItemDef.pm
@@ -15,7 +15,7 @@

package Automake::ItemDef;

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/Language.pm b/lib/Automake/Language.pm
index 12a29be..8cd866d 100644
--- a/lib/Automake/Language.pm
+++ b/lib/Automake/Language.pm
@@ -15,7 +15,7 @@

package Automake::Language;

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/Location.pm b/lib/Automake/Location.pm
index 77b0599..21d08f7 100644
--- a/lib/Automake/Location.pm
+++ b/lib/Automake/Location.pm
@@ -15,7 +15,7 @@

package Automake::Location;

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/Options.pm b/lib/Automake/Options.pm
index aee1831..69fc2ec 100644
--- a/lib/Automake/Options.pm
+++ b/lib/Automake/Options.pm
@@ -15,7 +15,7 @@

package Automake::Options;

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/Rule.pm b/lib/Automake/Rule.pm
index 6a622e6..9f72d27 100644
--- a/lib/Automake/Rule.pm
+++ b/lib/Automake/Rule.pm
@@ -15,7 +15,7 @@

package Automake::Rule;

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/RuleDef.pm b/lib/Automake/RuleDef.pm
index e5b3a1b..1ae8b63 100644
--- a/lib/Automake/RuleDef.pm
+++ b/lib/Automake/RuleDef.pm
@@ -15,7 +15,7 @@

package Automake::RuleDef;

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/VarDef.pm b/lib/Automake/VarDef.pm
index 3e13932..9f09411 100644
--- a/lib/Automake/VarDef.pm
+++ b/lib/Automake/VarDef.pm
@@ -15,7 +15,7 @@

package Automake::VarDef;

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/Variable.pm b/lib/Automake/Variable.pm
index cc6b12f..2c11831 100644
--- a/lib/Automake/Variable.pm
+++ b/lib/Automake/Variable.pm
@@ -15,7 +15,7 @@

package Automake::Variable;

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/Version.pm b/lib/Automake/Version.pm
index 02146a5..369a229 100644
--- a/lib/Automake/Version.pm
+++ b/lib/Automake/Version.pm
@@ -15,7 +15,7 @@

package Automake::Version;

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/Wrap.pm b/lib/Automake/Wrap.pm
index 73a6247..9233798 100644
--- a/lib/Automake/Wrap.pm
+++ b/lib/Automake/Wrap.pm
@@ -15,7 +15,7 @@

package Automake::Wrap;

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

diff --git a/lib/Automake/XFile.pm b/lib/Automake/XFile.pm
index fb256c9..05e8b32 100644
--- a/lib/Automake/XFile.pm
+++ b/lib/Automake/XFile.pm
@@ -69,7 +69,7 @@ and C<getlines> methods to translate C<\r\n> to C<\n>.

=cut

-use 5.010;
+use 5.006;
use strict;
use warnings FATAL => 'all';

--
8<------


-- Jacob

Message #43 received at 61240 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 61240 <at> debbugs.gnu.org
Subject: Re: [bug#61240] [PATCH 2/2] Gracefully degrade if Time::HiRes is
 not available
Date: Tue, 07 Feb 2023 23:29:30 -0600

Paul Eggert wrote:
> On 2023-02-05 21:43, Jacob Bachmeyer wrote:
>> Should the patch be relative to commit 
>> 6d6fc91c472fd84bd71a1b012fa9ab77bd94efea (before the version 
>> requirement bump) or should it include reverting commit 
>> 4e3744a15c4d8bdb46c11ead2fb56c5f591b714b (the version requirement bump)?
>
> Might as well do it all at once, thanks.

This second patch is the change I previously suggested.  As noted in the 
patch, please use my gnu.org address for public attribution.  (I would 
prefer to minimize any indirect advertising of GMail.)

I have found no better ChangeLog entry than the commit message:

   * lib/Automake/FileUtils.pm: Gracefully degrade if Time::HiRes is 
not available.

8<------
From: Jacob Bachmeyer <jcb <at> gnu.org>
Date: Tue, 7 Feb 2023 22:42:59 -0600
Subject: [PATCH 2/2] Gracefully degrade if Time::HiRes is not available

---
lib/Automake/FileUtils.pm |    5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/lib/Automake/FileUtils.pm b/lib/Automake/FileUtils.pm
index 697ff7e..8d0b368 100644
--- a/lib/Automake/FileUtils.pm
+++ b/lib/Automake/FileUtils.pm
@@ -39,9 +39,12 @@ use strict;
use warnings FATAL => 'all';

use Exporter;
-use Time::HiRes qw(stat);
use IO::File;

+# use sub-second resolution timestamps if available,
+# carry on with one-second resolution timestamps if that is all we have
+BEGIN { eval { require Time::HiRes; import Time::HiRes qw(stat) } }
+
use Automake::Channels;
use Automake::ChannelDefs;

--
8<------


-- Jacob

Message #50 received at 61240 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Warren Young <warren <at> etr-usa.com>
Cc: Dagobert Michelsen <dam <at> opencsw.org>, 61240 <at> debbugs.gnu.org,
 autoconf <at> gnu.org, Jacob Bachmeyer <jcb62281 <at> gmail.com>,
 Jim Meyering <jim <at> meyering.net>
Subject: Re: [bug#61240] [PATCH 2/2] Gracefully degrade if Time::HiRes is not
 available
Date: Tue, 28 Mar 2023 10:03:02 -0700

On 2023-03-28 08:21, Warren Young wrote:
> Surely Solaris 10 (shipped in 2005) is relegated to the role of porting target, getting nothing but a “dist” tarball?

Good point. I'll cc this to Dagobert Michelsen, who maintains the 
Autoconf port for Solaris 10. Dagobert, are people still running 
Autoconf on Solaris 10? If not, worrying about porting to older Perl 
should be even lower priority than it already is.

For context, this email is about GNU bug 61240:

https://bugs.gnu.org/61240

and the fallout that the latest Autoconf release candidate does not run 
on the old version of Perl installed by default on Solaris 10. See:

https://lists.gnu.org/r/autoconf/2023-03/msg00030.html

If OpenCSW already installs a new-enough Perl version then this Autoconf 
business shouldn't be a real issue. On the other hand if it's really 
trivial to keep Autoconf portable to older Perl, and if Jacob Bachmeyer 
or some other Perl expert can vouch for the change, we might as well put 
it in.


PS. I see that msg00030 was not archived at https://bugs.gnu.org/61240, 
so here is a quoted copy of the contents of msg00030 so that this stuff 
gets archived there too:

> On 2023-02-07 21:29, Jacob Bachmeyer wrote:
>> use Exporter;
>> -use Time::HiRes qw(stat);
>> use IO::File;
>>
>> +# use sub-second resolution timestamps if available,
>> +# carry on with one-second resolution timestamps if that is all we have
>> +BEGIN { eval { require Time::HiRes; import Time::HiRes qw(stat) } }
> 
> Thanks for looking into this. Sorry about the long delay.
> 
> My memory was jogged by the recent Autoconf release candidate, which requires Perl 5.10 for what I think is the same reason <https://lists.gnu.org/r/autoconf/2023-03/msg00020.html>. This release candidate didn't build on my Solaris 10 server because Solaris 10 has only Perl 5.8.4. Of course I can work around this by also installing a recent Perl but that is a bit of a pain. I'll cc this email to autoconf <at> gnu.org to give them a heads-up about <https://bugs.gnu.org/61240>.
> 
> It'd be nice (though not crucial) if we could get to the bottom of this for Automake and to sync the result to Autoconf before the new Autoconf release comes out, so that Solaris 10 users of the new Autoconf need to install only recent GNU M4, and not also a recent Perl.
> 
> To get back to the proposed patch quoted above:
> 
> Why change from "use Time::HiRes qw(stat);" to "require Time::HiRes; import Time::HiRes qw(stat)"? (Again, please bear in mind that my Perl is quite rusty.)
> 
> The code formerly had "use File::stat;" before it changed to "use Time::HiRes qw(stat);". Why doesn't the proposed patch need to fall back to "use File::stat;" on older Perls lacking Time::HiRes?
> 
> Thanks again for any advice you can provide.

Message #53 received at 61240 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 61240 <at> debbugs.gnu.org, Dagobert Michelsen <dam <at> opencsw.org>,
 Autoconf <autoconf <at> gnu.org>, Jim Meyering <jim <at> meyering.net>
Subject: Re: [bug#61240] [PATCH 2/2] Gracefully degrade if Time::HiRes is
 not available
Date: Tue, 28 Mar 2023 21:06:40 -0500

[expanding CC list to cover later message]

Paul Eggert wrote:
> On 2023-02-07 21:29, Jacob Bachmeyer wrote:
>> use Exporter;
>> -use Time::HiRes qw(stat);
>> use IO::File;
>>
>> +# use sub-second resolution timestamps if available,
>> +# carry on with one-second resolution timestamps if that is all we have
>> +BEGIN { eval { require Time::HiRes; import Time::HiRes qw(stat) } }
>
> Thanks for looking into this. Sorry about the long delay.

I was about to send another ping this weekend.

> My memory was jogged by the recent Autoconf release candidate, which 
> requires Perl 5.10 for what I think is the same reason 
> <https://lists.gnu.org/r/autoconf/2023-03/msg00020.html>. This release 
> candidate didn't build on my Solaris 10 server because Solaris 10 has 
> only Perl 5.8.4. Of course I can work around this by also installing a 
> recent Perl but that is a bit of a pain. I'll cc this email to 
> autoconf <at> gnu.org to give them a heads-up about 
> <https://bugs.gnu.org/61240>.
>
> It'd be nice (though not crucial) if we could get to the bottom of 
> this for Automake and to sync the result to Autoconf before the new 
> Autoconf release comes out, so that Solaris 10 users of the new 
> Autoconf need to install only recent GNU M4, and not also a recent Perl.
>
> To get back to the proposed patch quoted above:
>
> Why change from "use Time::HiRes qw(stat);" to "require Time::HiRes; 
> import Time::HiRes qw(stat)"? (Again, please bear in mind that my Perl 
> is quite rusty.)

In Perl, "use MODULE LIST;" is shorthand for "BEGIN { require Module; 
import Module LIST; }".  The patch must expand that shorthand in order 
to insert an "eval BLOCK" to catch the error "require" will throw if 
Time::HiRes is not available.  In this case, we do not worry about 
actually handling the error, since the fallback is to use the stat 
builtin instead of replacing it with Time::HiRes::stat.

Putting them close together, we have three forms:

(1) use Time::HiRes qw(stat);
(2) BEGIN { require Time::HiRes; import Time::HiRes qw(stat); }
(3) BEGIN { eval { require Time::HiRes; import Time::HiRes qw(stat); } }

According to the Perl manual ("use" in perlfunc), (1) and (2) are 
"exactly equivalent" forms, with a minor syntactic difference not 
relevant here.  (Form (2) is slightly more general.)  The patch replaces 
(1) with (3), which allows the error that occurs if Time::HiRes cannot 
be loaded to be ignored.  Notably, Time::HiRes could be installed from 
CPAN before it became a core module, so this patch also allows 
sub-second timestamps with Perl 5.6 if Time::HiRes has been installed.

Simply saying "eval { use Time::HiRes qw(stat) };" will not work because 
it would expand to "eval { BEGIN { require Time::HiRes; ...} };" which 
would execute the "require" while compiling the "eval" block, and thus 
fail to catch the error if Time::HiRes is not available because the 
error is thrown before the "eval" is actually in force.  Conversely, 
"eval 'use Time::HiRes qw(stat)';" would be too *late*:  the rest of the 
program would have already been compiled to use the stat builtin.  The 
import must be executed before the rest of the program is compiled, and 
an eval must be in force when it is executed to catch the error if 
Time::HiRes is not available.  This requires expanding "use" to its 
equivalent "BEGIN { require ... }" in order to put the "eval" in the 
right place.

> The code formerly had "use File::stat;" before it changed to "use 
> Time::HiRes qw(stat);". Why doesn't the proposed patch need to fall 
> back to "use File::stat;" on older Perls lacking Time::HiRes?

File::stat is a convenience wrapper around the stat builtin that 
modifies it to return an object instead of the 13-element list Perl's 
core stat produces.  File::stat and Time::HiRes::stat are incompatible, 
so the program had to be modified to remove the use of File::stat before 
it could use Time::HiRes::stat.

The reason that the fallback is to do nothing if requiring Time::HiRes 
and importing Time::HiRes::stat fails is that Time::HiRes::stat is a 
drop-in replacement for the stat builtin, which remains available if the 
import fails.  So we attempt to import Time::HiRes::stat (which will 
transparently replace the stat builtin if it succeeds) and proceed with 
the stat builtin (that Perl 5 always has) if the import fails.

> Thanks again for any advice you can provide.

You are welcome.  Also note patches at bug#61670 and bug#61671 which 
resolve some minor testsuite issues with Perl 5.6.2.


-- Jacob

Message #56 received at 61240 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Dagobert Michelsen <dam <at> opencsw.org>, 61240 <at> debbugs.gnu.org,
 autoconf <at> gnu.org, Jim Meyering <jim <at> meyering.net>,
 Warren Young <warren <at> etr-usa.com>
Subject: Re: [bug#61240] [PATCH 2/2] Gracefully degrade if Time::HiRes is
 not available
Date: Tue, 28 Mar 2023 21:36:14 -0500

Paul Eggert wrote:
> On 2023-03-28 08:21, Warren Young wrote:
>> Surely Solaris 10 (shipped in 2005) is relegated to the role of 
>> porting target, getting nothing but a “dist” tarball?
>
> Good point. I'll cc this to Dagobert Michelsen, who maintains the 
> Autoconf port for Solaris 10. Dagobert, are people still running 
> Autoconf on Solaris 10? If not, worrying about porting to older Perl 
> should be even lower priority than it already is.
>
> For context, this email is about GNU bug 61240:
>
> https://bugs.gnu.org/61240
>
> and the fallout that the latest Autoconf release candidate does not 
> run on the old version of Perl installed by default on Solaris 10. See:
>
> https://lists.gnu.org/r/autoconf/2023-03/msg00030.html
>
> If OpenCSW already installs a new-enough Perl version then this 
> Autoconf business shouldn't be a real issue. On the other hand if it's 
> really trivial to keep Autoconf portable to older Perl, and if Jacob 
> Bachmeyer or some other Perl expert can vouch for the change, we might 
> as well put it in.

I have since checked and it appears that the same patch I submitted for 
Automake on this bug should also work for Autoconf, applied atop commit 
3a9802d60156809c139e9b4620bf04917e143ee2 (also back out the change to 
"use 5.008" in that commit, which was bogus for the same reasons I have 
previously explained for the Perl version requirement bump in 
Automake).  Autoconf would also do well to revert commit 
61901a1a14fd50c03cfb1529d091554376fef286 and/or possibly split 
m4/perl-time-hires.m4 out of that commit and remove the "use 5.010;" 
line from it; the correct test is for a perl that has Time::HiRes::stat, 
not for any specific version of perl.  I find this particularly grating 
in Autoconf, where the entire point is supposed to be "test for 
features, not versions".  :-/


-- Jacob

Message #59 received at 61240 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: jcb62281 <at> gmail.com
Cc: 61240 <at> debbugs.gnu.org, Dagobert Michelsen <dam <at> opencsw.org>,
 Autoconf <autoconf <at> gnu.org>, Jim Meyering <jim <at> meyering.net>
Subject: Re: [bug#61240] [PATCH 2/2] Gracefully degrade if Time::HiRes is not
 available
Date: Wed, 29 Mar 2023 12:20:09 -0700

Thanks for the explanation. I installed those two patches into Automake.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.