Glenn Morris <rgm@gnu.org> writes:

> 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?

It seems pretty common for multi-file packages to have some kind of
staging process (e.g. "make elpa") in their build process (at least
company-mode, circe, magit, and projectile all do). This means the
production of tarball itself has timestamps based the VCS checkout.

Of course, in this case one could push the responsibility back onto the
package authors, but toolchain fixes seem better if possible (where
emacs is the toolchain here).

> 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?

They only need to be preserved in a limited way to satisfy make; for
example in the staging process above, the copied files are not examined
by make after copying.

> 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...

[snips]

> 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?

Right, personally I think the installed files, including any generated
loaddefs (I'm guessing you're using loaddefs in a generic sense,
independent of the setting of GENERATED-AUTOLOADS-FILE?), should be
immutable.

Stefan's comment about stripping comments from the loaddefs files as
part of the install process is intriguing. Am I correct in thinking this
is pretty much equivalent to your option #1, in that the ";;;###"
section is only used for updating the loaddefs file?

Cheers,

David