reddit / emacs

Emacs 28 doesn't seem to be doing native compilation of packages automatically

oantolin · 2022-11-27 15:30
I'm hoping someone can help figure out what I'm doing wrong. I recently updated to Emacs 28.2 on two machines and though the native compiler is working when I run it manually, it doesn't seem to be running automatically on packages I install with `package.el` nor on some personal libraries. The rest of this post has whatever details I think I might get asked about, but probably excludes some necessary details which, due to my ignorance, I don't realize are necessary! :) I do now have native compilation in both installations, and for built-in functions `describe-function` says "... is a native-compiled Lisp functions in ...". If I manually call `emacs-lisp-native-compile-and-load` on a file, it does get compiled to native code, the corresponding `.eln` file gets placed in `.emacs.d/eln-cache/28.2-7a6329ed/`. The cached file *is* found on subsequent runs of Emacs when I load that library, and `describe-function` does says those functions are native-compiled. But, though I've been running Emacs 28 for a couple of weeks, not a single one of the packages I've written nor the ones installed through `package.el` has been native-compiled in the background for me, I only have native-compiled code for the built-in packages and for whatever I have manually called the compiler on. I've left what I think are the relevant variables at their default values: - `native-comp-always-compile`: nil. I'm not sure what this variable does: the entire docstring is "Non-nil means unconditionally (re-)compile all files." - `native-comp-eln-load-path`: this contains `~/.emacs.d/eln-cache/` as its first entry, and on Debian, the second entry is `/usr/lib/emacs/28.2/native-lisp/`. (I don't remember what this variable is set to on Windows, but I do know I don't configure it, and leave it at the default value ---on Debian I use the `emacs` package from Debian Unstable, on Windows 10 I use binaries from the GNU Emacs website.) - `load-no-native`: nil - `package-native-compile`: nil. My understanding is that nil does *not* mean "don't compile packages" it only means "don't compile them ahead-of-time, when installing them". - `native-comp-deferred-compilation`: t. This is supposed to native-compile any Lisp file for which I load the corresponding `.elc` file, to do it asynchronously, and then replace the byte-compiled functions with their native-compiled versions. Any ideas? I guess that as a work-around I could set `package-native-compile` to `t` for packages I install, and then manually call `emacs-lisp-native-compile-and-load` on any extra libraries I write, but I'd really like the automatic asynchronous, deferred compilation to work if possible.
[deleted] · 2022-11-27 16:09
[deleted]
_viz_ · 2022-11-27 17:05
There was a long thread in emacs-devel initiated by one of the Debian maintainers of the emacs package asking to add a mechanism to inhibit native compilation even if Emacs was compiled with native compilation support. That thread produced the variable inhibit-automatic-compilation and I believe Debian backported this change to Emacs 28. So maybe check if this variable is set to t?
oantolin · 2022-11-27 17:11
I don't have that variable. I don't have any variable whose name contains both `inh` and `compi` in either order. Now I am curious to read this thread you mentioned. Why inhibit native-compilation? Why add another variable? Don't `no-native-compile`, `package-native-compile`, `native-comp-deferred-compilation` and `native-comp-deferred-compilation-deny-list` provide sufficient control?
_viz_ · 2022-11-27 18:05
https://yhetil.org/emacs-devel/87ill8paw7.fsf@trouble.defaultvalue.org/ here is the thread. I did not follow the thread thoroughly but the motivation was to let the users disable native compilation while still having natively compiled core libraries, something that I would be interested in as well. OTOH, looking at the Debian bug tracker, I noticed an issue about not being to natively compile and a patch from master was backported on ~Nov 8. Maybe updating will solve the issue?