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. Yinz can change automake yourselves, you don't need
me to jump in :-)
Assuming this is really about autom4te, how does this look?
$ ./tests/autom4te --version
autom4te (GNU Autoconf) 2.72d.6-49ab3-dirty (subsecond timestamps supported)
Copyright (C) 2023 Free Software Foundation, Inc.
[etc]
If subsecond timestamps are *not* supported, you'll get instead
autom4te (GNU Autoconf) 2.72d.6-49ab3-dirty
Copyright (C) 2023 Free Software Foundation, Inc.
[etc]
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.
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?
zw
