From: David Bremner <david@tethera.net>
To: Glenn Morris <rgm@gnu.org>
Cc: 22213@debbugs.gnu.org
Subject: bug#22213: 24.5; please allow specification or elimination of timestamp in autoloads
Date: Mon, 21 Dec 2015 08:28:12 -0400 [thread overview]
Message-ID: <87y4cof0kj.fsf@zancas.localnet> (raw)
In-Reply-To: <bs7fk9ssa2.fsf@fencepost.gnu.org>
[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 647 bytes --]
next prev parent reply other threads:[~2015-12-21 12:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-19 18:52 bug#22213: 24.5; please allow specification or elimination of timestamp in autoloads David Bremner
2015-12-19 19:11 ` Glenn Morris
2015-12-19 19:49 ` David Bremner
2015-12-20 3:39 ` Glenn Morris
2015-12-21 0:38 ` Glenn Morris
2015-12-21 1:54 ` Stefan Monnier
2015-12-21 2:20 ` Glenn Morris
2015-12-21 15:59 ` Stefan Monnier
2016-01-07 7:42 ` Glenn Morris
2016-01-08 7:41 ` Stefan Monnier
2016-01-08 14:53 ` Drew Adams
2016-05-25 22:37 ` Glenn Morris
2015-12-21 12:28 ` David Bremner [this message]
2015-12-20 9:33 ` Philipp Stephani
2015-12-20 9:29 ` Philipp Stephani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y4cof0kj.fsf@zancas.localnet \
--to=david@tethera.net \
--cc=22213@debbugs.gnu.org \
--cc=rgm@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).