Zack Weinberg wrote:
On Sun, Dec 3, 2023, at 4:49 PM, Karl Berry wrote:
There would not need to be much parsing, just "automake --version | grep
> HiRes" in that case, or "case `automake --version` in *HiRes*) ...;;
> easc" to avoid running grep if you want.
I specifically want to hear what Karl thinks.
I lean towards Jacob's view that automake --version | grep HiRes will
suffice. Not having a new option seems simpler/better in terms of later
understanding, too. --thanks, karl.
Did I misunderstand which program's --version output we are talking about?
I thought we were talking about automake's testsuite probing the behavior
of *autom4te*, but all the quoted text seems to be imagining a probe of
*automake* instead.
Yes, there was a bit of confusion here; not only is the FileUtils module
synchronized between autom4te and automake, but those two are near
"sound-alikes" as I read them. Oops.
The issue here seems to be determining if a fix that (I think)
originated in automake has been applied to the active autom4te.
[...]
I'm not using the identifier "HiRes" because the use of Time::HiRes is an
implementation detail that could change. For instance, if there's a third
party CPAN module that lets us get at nanosecond-resolution timestamps
*without* loss of precision due to conversion to an NV (aka IEEE double)
we could, in the future, look for that first.
That is fine, but "[HiRes]" or "[HiResTime]" is much shorter and we
could use it as the name of the feature regardless of the underlying
implementation. Characters in the first line of `autom4te --version`
are a finite resource if we want it to fit on a standard 80-column
terminal without wrapping. If we need to distinguish, "[HiRes]
[HiRes-ns]" could be used to indicate your hypothetical integer
nanosecond-resolution timestamp support, which would indicate also
having sub-second timestamp support.
I also suggest changing the tag, since the GNU Coding Standards call for
the version number to be indicated by the last space, but parenthesized
text between the name and version is supposed to be the package, so this
would lead to:
$ ./tests/autom4te --version
autom4te [HiResTime] (GNU Autoconf) 2.72d.6-49ab3-dirty
Copyright (C) 2023 Free Software Foundation, Inc.
[...]
Is this workable all the way around, everyone? Or should the feature be
indicated with another line after the license notice? ("This autom4te
has subsecond timestamp resolution.") My apologies for neglecting to
check this before suggesting a tag in the --version output.
The implementation is just
BEGIN
{
our $subsecond_timestamps = 0;
eval
{
require Time::HiRes;
import Time::HiRes qw(stat);
$subsecond_timestamps = 1;
}
}
Jacob, can you confirm that's an accurate test, given all the things you
said earlier about ways that grepping the source code might get it wrong?
That will determine if (a) Time::HiRes could be loaded and (b)
Time::HiRes::stat could be imported. This is the same test that
Autom{ak,4t}e::FileUtils effectively uses to use Time::HiRes::stat. I
believe that the import is not actually necessary (i.e. Time::HiRes
always exported Time::HiRes::stat) but it should do no harm as long as
any use of stat in the code is prepared to handle floating-point
timestamps. As long as the autom4te script and its library are
consistent (which is the distribution's problem if they screw that up),
this test should be accurate.
-- Jacob
