Re: [RFC PATCH]: autom4te: report subsecond timestamp support in --version

[Jacob Bachmeyer]

Zack Weinberg wrote:

On Mon, Dec 4, 2023, at 7:26 PM, Jacob Bachmeyer wrote:
  

Now that I have seen the actual patch, yes, this test should be
accurate.  The test in the main autom4te script will also work, even
if there is a mismatch between the script and its library



Good.

  

This appears to be misaligned with the GNU Coding Standards, which
states:  "The first line is meant to be easy for a program to parse;
the version number proper starts after the last space."

Perhaps the best option would be to conditionally add a line "This
autom4te supports subsecond timestamps." after the license notice?



I don't like putting anything after the license notice because it's
convenient to be able to pipe --version output to sed '/Copyright/,$d'
without losing anything relevant for troubleshooting.  So how about

$ autom4te --version
autom4te (GNU Autoconf) 2.71
Features: subsecond-timestamps

Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
, 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Akim Demaille.

This preserves the effectiveness of sed '/Copyright/,$d' and also
leaves room for future additions to the "Features:" line.


That looks like a good idea to me, although the GNU Coding Standards do 
say (section 4.8.1, "--version") that the copyright and license notices 
"should" immediately follow the version numbers.  The presence or 
absence of this feature is effectively determined by something similar 
to a library version (the availability of the Perl Time::HiRes module) 
and it is expected to be important for debugging, which is the criteria 
stated for listing library versions.  Further, "should" does not express 
an absolute requirement and no rationale that would effectively make an 
absolute requirement (like a rule for automated parsing) is given here, 
unlike for the version in the first line.



-- Jacob

Re: rhel8 test failure confirmation?

[Jacob Bachmeyer]

Zack Weinberg wrote:

On Mon, Dec 4, 2023, at 7:14 PM, Jacob Bachmeyer wrote:
  

Zack Weinberg wrote:


[snip everything addressed in the other thread]
  

Yes, there was a bit of confusion here; not only is the FileUtils
module synchronized between autom4te and automake



Thanks for reminding me that I need to make sure all those files are
actually in sync before I cut the final 2.72 release.

  

  require Time::HiRes;
  import Time::HiRes qw(stat);
  

I believe that the import is not actually necessary



The previous line is a "require", not a "use", so I believe it _is_
necessary.  Have I misunderstood?

  

... should do no harm as long as any use of stat in the code
is prepared to handle floating-point timestamps.



There's only one use, in 'sub mtime', and that's the place
where we actively want the floating-point timestamps.


Yes, before seeing your actual patch, I had the mistaken impression that 
this code was in autom4te itself, not the FileUtils module.  The import 
is needed in the FileUtils module, so the patch is correct.



-- Jacob

Re: [RFC PATCH]: autom4te: report subsecond timestamp support in --version

[Karl Berry]

Features: subsecond-timestamps

Sounds good to me, FWIW. Thanks to all. -k

Re: rhel8 test failure confirmation?

[Zack Weinberg]

On Mon, Dec 4, 2023, at 7:14 PM, Jacob Bachmeyer wrote:
> Zack Weinberg wrote:
[snip everything addressed in the other thread]
> Yes, there was a bit of confusion here; not only is the FileUtils
> module synchronized between autom4te and automake

Thanks for reminding me that I need to make sure all those files are
actually in sync before I cut the final 2.72 release.

>>   require Time::HiRes;
>>   import Time::HiRes qw(stat);
>
> I believe that the import is not actually necessary

The previous line is a "require", not a "use", so I believe it _is_
necessary.  Have I misunderstood?

> ... should do no harm as long as any use of stat in the code
> is prepared to handle floating-point timestamps.

There's only one use, in 'sub mtime', and that's the place
where we actively want the floating-point timestamps.

zw

Re: [RFC PATCH]: autom4te: report subsecond timestamp support in --version

[Zack Weinberg]

On Mon, Dec 4, 2023, at 7:26 PM, Jacob Bachmeyer wrote:
> Now that I have seen the actual patch, yes, this test should be
> accurate.  The test in the main autom4te script will also work, even
> if there is a mismatch between the script and its library

Good.

> This appears to be misaligned with the GNU Coding Standards, which
> states:  "The first line is meant to be easy for a program to parse;
> the version number proper starts after the last space."
>
> Perhaps the best option would be to conditionally add a line "This
> autom4te supports subsecond timestamps." after the license notice?

I don't like putting anything after the license notice because it's
convenient to be able to pipe --version output to sed '/Copyright/,$d'
without losing anything relevant for troubleshooting.  So how about

$ autom4te --version
autom4te (GNU Autoconf) 2.71
Features: subsecond-timestamps

Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
, 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Akim Demaille.

This preserves the effectiveness of sed '/Copyright/,$d' and also
leaves room for future additions to the "Features:" line.

zw