all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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 --]

  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

* 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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.