bug#22213: 24.5; please allow specification or elimination of timestamp in autoloads

[Glenn Morris <rgm@gnu.org>]

David Bremner wrote:

> It changes the problem to one of managing timestamps of files. This is
> probably easier than the current situation, but not completely trivial,
> since e.g. both git checkout and build systems that copy files will
> modify timestamps.

Point taken about VCS checkouts. Is that a case you need to deal with?
I was thinking of rebuilding a binary package from a given
source tarfile. But surely a build system must preserve source file
timestamps, for the sake of make?

Anyway, for an optional, non-default behaviour controlled by an
(env)var, two ideas come to mind.

1) Store no timestamp in the loaddefs file, and use the modtime of the
loaddefs file instead. In fact, I'm not sure why we don't just do it
this way...

The only reason I can come up with is parallel builds where the input
files may get modified during the time it takes to write the loaddefs
file. But if that could happen, then the generated loaddefs file might
be wrong, so the build system dependencies must be written to prevent this.
(Generated lisp files are almost always no-update-autoloads anyway.)
So after thinking about it, this explanation doesn't make sense.
So maybe I'm missing some other reason why it is how it is...?

2) Use md5sums instead of timestamps.
This would require the final "these files contained no autoloads"
section to be split up into one section per file, each with its own md5sum.
This method would slow down the (re)building of loaddefs (which is why
timestamps are used now most of the time). This would be more work to
implement, and make builds slower, but it would be strictly correct.


I'm guessing you don't care about in-place updating of a pre-existing
loaddefs after modifying the inputs, so 1) would be fine?