From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Glenn Morris Newsgroups: gmane.emacs.bugs Subject: bug#22213: 24.5; please allow specification or elimination of timestamp in autoloads Date: Sat, 19 Dec 2015 22:39:01 -0500 Message-ID: References: <877fkauv8l.fsf@zancas.localnet> <874mfeusl9.fsf@zancas.localnet> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1450582817 4773 80.91.229.3 (20 Dec 2015 03:40:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Dec 2015 03:40:17 +0000 (UTC) Cc: 22213@debbugs.gnu.org To: David Bremner Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 20 04:40:08 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aAUqt-0006g0-M8 for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Dec 2015 04:40:07 +0100 Original-Received: from localhost ([::1]:39531 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAUqt-0001TW-2G for geb-bug-gnu-emacs@m.gmane.org; Sat, 19 Dec 2015 22:40:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAUqp-0001T3-Iz for bug-gnu-emacs@gnu.org; Sat, 19 Dec 2015 22:40:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aAUqo-0002sq-Ju for bug-gnu-emacs@gnu.org; Sat, 19 Dec 2015 22:40:03 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49742) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAUqo-0002sm-GJ for bug-gnu-emacs@gnu.org; Sat, 19 Dec 2015 22:40:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aAUqo-0004sF-9R for bug-gnu-emacs@gnu.org; Sat, 19 Dec 2015 22:40:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Glenn Morris Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Dec 2015 03:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22213 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22213-submit@debbugs.gnu.org id=B22213.145058275918682 (code B ref 22213); Sun, 20 Dec 2015 03:40:02 +0000 Original-Received: (at 22213) by debbugs.gnu.org; 20 Dec 2015 03:39:19 +0000 Original-Received: from localhost ([127.0.0.1]:57344 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aAUq7-0004rG-CG for submit@debbugs.gnu.org; Sat, 19 Dec 2015 22:39:19 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:59661) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aAUq5-0004r2-9S for 22213@debbugs.gnu.org; Sat, 19 Dec 2015 22:39:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aAUpz-0002YO-52 for 22213@debbugs.gnu.org; Sat, 19 Dec 2015 22:39:11 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57555) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAUpr-0002Xk-2U; Sat, 19 Dec 2015 22:39:03 -0500 Original-Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1aAUpp-0004jL-Kr; Sat, 19 Dec 2015 22:39:01 -0500 X-Spook: Exposure Pakistan Yukon CBNRC Aldergrove Collapse CDMA X-Ran: .w_#H{<-@b:=UA^M{;(KChHdVLQfB`%t,=JW.RoW??iVXW@/s0g'-m9I&?4`,?Z3Q$)'6; X-Hue: blue X-Attribution: GM In-Reply-To: <874mfeusl9.fsf@zancas.localnet> (David Bremner's message of "Sat, 19 Dec 2015 15:49:22 -0400") User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:110197 Archived-At: 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?