Hi Eric and all,
mdate-sh was older at the time 1.4.19
was cut; it has changed in the meantime
The only changes to mdate-sh in recent years have been trivialities
involving the help message and induced Emacs incompatibilities for the
Local Variables block. The actual code hasn't changed in ages.
since unpacking the tarball in different months may inadverently
result in two environments with different dates on the file
It could? Shouldn't the mtime in the tarball be preserved when
unpacking, on any reasonable system? And if the .texi in fact changes,
then isn't it fine for the new date (mtime) to be used? I'm missing
something.
caller to specify an epoch that a particular build should place into
version.texi, regardless of file timestamps being newer than that
specified epoch?
I'm not sure what you mean by "epoch". I think of "epoch" as meaning
1970-01-01, in our world. Not as a value to be specified.
Then, manuals could continue to use @value{UPDATED},
Well, that is clearly desirable. I looked at the bug-m4 thread from
https://lists.gnu.org/archive/html/bug-m4/2025-04/msg00043.html
but I'm afraid I understand neither the problem nor the given solutions.
Anyway, if there's a change to be made to mdate-sh or Automake, let me
know. Ideally with a patch (and even more ideally also with a test).
I'm hoping to make a new Automake release soonly. If there's something
to do for this problem, clearly it would be nice to include. --thanks, karl.
