GNU bug report logs - #79124
emacs -Q doesn't give me a clean slate

Previous Next

Package: emacs;

Reported by: Paul Eggert <eggert <at> cs.ucla.edu>

Date: Wed, 30 Jul 2025 00:00:02 UTC

Severity: normal

Full log


Message #95 received at 79124 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: rpluim <at> gmail.com, 79124 <at> debbugs.gnu.org, rms <at> gnu.org
Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate
Date: Tue, 05 Aug 2025 18:55:03 +0300
> Date: Tue, 5 Aug 2025 08:23:22 -0700
> Cc: rpluim <at> gmail.com, rms <at> gnu.org, 79124 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> On 2025-08-05 04:19, Eli Zaretskii wrote:
> 
> > AFAIR, you accepted the AOT
> > build as a workaround for this problem,
> 
> No, I didn't. I rejected it because it's too much of a pain to expect 
> users to rebuild Emacs (in an especially-length process!) just to 
> reproduce a bug.

If the only problem is the pain, then you did accept it as the
workaround.  The effort to produce an AOT build is not relevant to
this discussion, only the correctness of the resulting *.eln files is.
Let's please not waste time on irrelevant tangents, and focus on the
main issues.

> > I don't understand how the *.eln files compiled from the *.el files in the
> > Emacs source tree are "kosher" when they are in the installation tree,
> > but not if they are under ~/.emacs.c/eln-cache/.
> 
> I'm assuming that Emacs was installed correctly (if not, all bets are 
> off anyway). What I don't want to assume is anything in the user's home 
> directory, because that can make tests irreproducible.

The same code which writes *.eln files in the AOT case writes them in
the user's eln-cache directory.  So either both are acceptable or both
aren't.

> >> A reproducible test should not be disrupted merely because the
> >> user's ~/.emacs.d/...macroexpand_0.eln is corrupt.
> > 
> > Why would it be corrupt, but the same file under /usr/lib/emacs cannot
> > be?
> 
> Could be many reasons. For example, maybe they backed up their home 
> directory but then restored it incorrectly. Whatever the reason is, I 
> don't want the user's home directory to affect the test.

Whatever can happen with the user's home directory can also happen
with the files in the directories of the installation tree.  The *.eln
files written into the user's eln-cache while compiling *.el files
from the installation tree are for all practical purposes parts of the
Emacs build, not parts of the user configuration.

> > The directory where these files live is not important.
> 
> It is important, because I want the tests to depend only on the 
> installed Emacs, not on the user's own files. That's a core part of 
> making tests reproducible.

The files in ~/.emacs.d/eln-cache/ produced by compiling *.el files
from the installation tree are part of the installed Emacs.  They just
live in a different directory.




This bug report was last modified 3 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.