From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#23203: 25.0.91; some loaddefs files have auto-save remnants after building (and install doesn't ignore them) Date: Fri, 08 Apr 2016 11:22:50 +0300 Message-ID: <83oa9kjyqt.fsf@gnu.org> References: <87twjjqidp.fsf@Rainer.invalid> <87shz35b8i.fsf@Rainer.invalid> <87lh4v0y1z.fsf@linux-m68k.org> <87egam6hif.fsf@Rainer.invalid> <3bf1141d622845eb4fe66b6dce573551.squirrel@cloud103.planethippo.com> <83fuv2plj5.fsf@gnu.org> <837fgepjm7.fsf@gnu.org> <83oa9po0li.fsf@gnu.org> <87wpodyqdy.fsf@russet.org.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1460103861 21122 80.91.229.3 (8 Apr 2016 08:24:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Apr 2016 08:24:21 +0000 (UTC) Cc: 23203@debbugs.gnu.org, stromeko@nexgo.de To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Apr 08 10:24:15 2016 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 1aoRi9-0000TL-1S for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Apr 2016 10:24:13 +0200 Original-Received: from localhost ([::1]:54911 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoRi4-0004cv-JP for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Apr 2016 04:24:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoRi0-0004b8-Uz for bug-gnu-emacs@gnu.org; Fri, 08 Apr 2016 04:24:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aoRhy-0003T2-Ja for bug-gnu-emacs@gnu.org; Fri, 08 Apr 2016 04:24:04 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoRhy-0003Sy-Fm for bug-gnu-emacs@gnu.org; Fri, 08 Apr 2016 04:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1aoRhy-00023J-96 for bug-gnu-emacs@gnu.org; Fri, 08 Apr 2016 04:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Apr 2016 08:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23203 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23203-submit@debbugs.gnu.org id=B23203.14601038037842 (code B ref 23203); Fri, 08 Apr 2016 08:24:02 +0000 Original-Received: (at 23203) by debbugs.gnu.org; 8 Apr 2016 08:23:23 +0000 Original-Received: from localhost ([127.0.0.1]:53475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aoRhK-00022P-Lb for submit@debbugs.gnu.org; Fri, 08 Apr 2016 04:23:22 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45582) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aoRhI-00022C-Nf for 23203@debbugs.gnu.org; Fri, 08 Apr 2016 04:23:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aoRhC-00035D-OU for 23203@debbugs.gnu.org; Fri, 08 Apr 2016 04:23:15 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56943) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoRh5-00032k-QC; Fri, 08 Apr 2016 04:23:07 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3911 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aoRh4-0001gg-UV; Fri, 08 Apr 2016 04:23:07 -0400 In-reply-to: <87wpodyqdy.fsf@russet.org.uk> (phillip.lord@russet.org.uk) 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" Xref: news.gmane.org gmane.emacs.bugs:116191 Archived-At: > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: 23203@debbugs.gnu.org, stromeko@nexgo.de > Date: Mon, 04 Apr 2016 23:12:57 +0100 > > > How about this alternative: only disable backing up the initial > > (effectively empty) contents of the autoloads file? AFAICT, the > > backup files are created during a bootstrap only because we first > > write the initial "rubric" into it, using write-region, and only after > > that visit it. This defeats the normal mechanism of backing up just > > once per session, and leaves a backup file whose contents are not > > interesting. > > That sounds plausible. > > > > > So an alternative would be to modify autoload-ensure-default-file so > > that it returns some indication about the fact it created the file, > > and then change its caller to set buffer-backed-up after it visits the > > file, thus preventing the backup _only_ when the file is first > > created. > > > > This should at least solve Achim's problem, but without affecting > > anything else. > > > > WDYT? > > Also, it sounds reasonable -- I've attached a patch with a variation on > this theme. Thanks. There seem to be spurious unrelated whitespace changes in the patch. Also, wouldn't it be more elegant to have autoload-ensure-default-file return a cons cell reporting whether the file did exist before, so that autoload-find-generated-file could act on that? But if you prefer your implementation, I won't argue. > My concerns is that we will still produce backup files which may end up > in a dist build. Consider these commands: > > make (from bootstrap) > rm lisp/loaddefs.el > make > > Removing loaddefs will result in generation of all the associated > loaddef files, all of which will now be backups. > > So, we need to make sure that the packaging system does not copy backup > files. "make install" already removes backup files from the target tree, so is there any problem left?