[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH.
|
From: |
Liliana Marie Prikler |
|
Subject: |
[bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH. |
|
Date: |
Sun, 28 Jan 2024 10:51:37 +0100 |
|
User-agent: |
Evolution 3.46.4 |
Am Sonntag, dem 28.01.2024 um 00:13 +0000 schrieb Suhail:
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> [...]
> > but ‘uniquify’ remains byte-compiled for no explainable reason.
>
> And too that as of v8 patch, uniquify still isn't natively-compiled.
> However, if you unload it and then reload it, it becomes
> natively-compiled.
>
> #+begin_src bash
> emacs --batch --eval "(message \"%s\" (progn (unload-feature
> 'uniquify) (require 'uniquify) (take 1 (split-string (substring-no-
> properties (describe-function 'uniquify-item-p)) \"\\n\" t))))"
> #+end_src
>
> #+RESULTS:
> : Type q in help window to delete it
> : (uniquify-item-p is a native-compiled Lisp function in
> `uniquify.el'.)
>
>
> I think the issue is because uniquify (along with some others such as
> prog-mode, backquote etc that I tested) are preloaded in Emacs. I
> believe that these preloaded packages need to be treated specially.
> In a non-Guix system, these preloaded packages have their .eln files
> stored under something like
> <native-comp-eln-load-path-entry>/29.x-<hash>/preloaded/ , whereas in
> the v8 series there is no "preloaded" directory. Instead .eln files
> for packages such as uniquify, prog-mode, backquote etc. are in
> various locations:
>
> - uniquify :: <n-c-e-l-p-entry>/29.2-<hash>/uniquify.eln
> - prog-mode :: <n-c-e-l-p-entry>/29.2-<hash>/progmodes/prog-mode.eln
> - backquote :: <n-c-e-l-p-entry>/29.2-<hash>/emacs-lisp/backquote.eln
>
> I suspect that the code which does the preloading may need to be
> patched and/or the preloaded packages may need to have their .eln
> files generated under a preloaded sub-directory (similar to what
> happens in non-Guix systems).
>From my experiments, the installing of these files is a red herring. I
instrumented lread.c to print the relative and absolute file names
tried, and it appears that these aren't loaded at all after install
while EMACSNATIVELOADPATH is ignored when dumping.
Cheers
- [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH., (continued)
- [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH., Liliana Marie Prikler, 2024/01/27
- [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH., Suhail, 2024/01/27
- [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH., Suhail, 2024/01/27
- [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH., Liliana Marie Prikler, 2024/01/27
- [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH., Suhail, 2024/01/27
- [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH., Liliana Marie Prikler, 2024/01/27
- [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH., Suhail, 2024/01/27
- [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH., Liliana Marie Prikler, 2024/01/27
- [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH., Suhail, 2024/01/27
- [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH., Suhail, 2024/01/27
- [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH.,
Liliana Marie Prikler <=
- [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH., Suhail, 2024/01/28
- [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH., Liliana Marie Prikler, 2024/01/28