bug#58267: 29.0.50; Native-compiling the same files at every start

[Eli Zaretskii]

> From: Holger Schurig <holgerschurig@gmail.com>
> Date: Tue, 4 Oct 2022 22:13:24 +0200
> 
> > cl-loaddefs.el has a "no-native-compile: t" cookie, so it's expected
> 
> Ah, okay. Still weird that the log claims that it's logged as if it is 
> compiled:
> 
> Compiling /usr/local/share/emacs/29.0.50/lisp/emacs-lisp/cl-loaddefs.el.gz...
> uncompressing cl-loaddefs.el.gz...
> uncompressing cl-loaddefs.el.gz...done
> 
> Would I have read
> 
> Uncompress /usr/local/share/emacs/29.0.50/lisp/emacs-lisp/cl-loaddefs.el.gz...
> ...done. no-native-compile set, ignored
> 
> then I wouldn't have wondered into this trap.
> 
> > If you start "emacs -Q" and type "M-x load-library RET pcase RET", does 
> > pcase get compiled and
> deposited into your eln-cache?
> 
> Ah, that is the difference. Yes, this time it did. Previously it didn't. And 
> the difference was ...  I started
> "emacs" without -Q for the pcase.el example. So I did start Emacs Doom, not 
> vanilla Emacs. And Dooms
> one sets different cache directories:
> 
> > native-comp-eln-load-path is a variable defined in comp.c.
> >
> > Value
> > ("/home/holger/.emacs.d/.local/cache/eln/" 
> > "/home/holger/.emacs.d/eln-cache/"
> "/usr/local/stow/emacs/lib/emacs/29.0.50/native-lisp/")
> 
> So the native-compiled pcase.el ended up in Doom's place, not in Emacs' 
> place, where I did expect it.
> 
> That also explains what I reported in my original post.
> 
> * I started "emacs" (Doom) and noticed several files in the Async log
> * Then I started "emacs -Q" and saw the same files again
> * This was because Doom wrote the compiled ones into his directory, hidden 
> from vanilla Emacs, and
> vanilla Emacs had to compile them. Again.
> * On top of that the cl-loaddefs file with the no-native-compile cookie 
> confused me further
> 
> So, sorry that I bothered you. This bug isn't a bug and can be closed.

Thanks, I'm therefore closing this bug.