GNU bug report logs - #67260
[PATCH emacs-team 0/2] Think ahead when compiling

Previous Next

Full log

View this message in rfc822 format

From: Suhail <suhail <at> bayesians.ca>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: cox.katherine.e+guix <at> gmail.com, 67260 <at> debbugs.gnu.org, Suhail <suhail <at> bayesians.ca>, andrew <at> trop.in
Subject: [bug#67260] [PATCH emacs-team v10 0/7] Preload most of the things
Date: Sun, 18 Feb 2024 00:56:09 +0000

"Liliana Marie Prikler" <liliana.prikler <at> gmail.com> writes:

> I don't think our choice of putting Emacs itself last is wrong here.

I'm not sure I understand.  Just to be clear (please ignore in case this
was already clear), in non-Guix Emacs the situation is as follows:

1. The directory where 'mule-util and 'ucs-normalize are located
   ("/usr/share/emacs/29.2/lisp/international") occurs in the load-path.
   And this entry occurs in the load-path AFTER
   "/usr/share/emacs/29.2/lisp".

2. The directory where 'term/internal is located
   ("/usr/share/emacs/29.2/lisp/international") does NOT occur in the
   load-path (and thus trivially doesn't occur before the
   "share/emacs/29.2/lisp" entry).

After installing the v10 patch series, both 1 and 2 hold in Guix Emacs
as well.  However, Guix Emacs's behaviour when locating/loading
natively-compiled versions of the above three features differs from the
behaviour in non-Guix Emacs.  Specifically, 1 and 2 above seem to pose a
problem for only Guix Emacs and after remedying 1 and 2 above, as in the
test script, the tests pass.

All this to say, if by "putting Emacs itself last" you meant the change
I made to the test script to make the tests pass, then while it may not
be wrong, it also isn't correct either (seeing how it's not needed in
non-Guix Emacs).  My goal in sharing the patch was not to suggest a fix,
but rather to possibly highlight something correlated with the cause of
the problem we're observing.

> Can you do some more research as to how this confusion comes to be?

Since I have less familiarity with the internals of how Emacs locates
natively-compiled features and loads them, I'm not sure where to begin.
Do you have some concrete suggestions?

What (I believe) we know:

- Not all the .eln entries in the "preloaded" native-comp-eln-load-path
  directory in Emacs are actually loaded by default.  This doesn't
  directly concern the issue, but it's to clarify that my use of the
  term "preloaded" in this thread is regarding the former and not the
  latter.

- The issue of
  whether-natively-compiled-variants-are-loaded-or-not-depends-on-order-in-load-path
  doesn't seem to affect packages that aren't built-in.  Specifically,
  if the load-entry for a not-built-in package is put after the
  "share/emacs/29.2/lisp" entry, Guix Emacs is still able to load the
  natively-compiled variant.

- It is unclear why other packages such 'log-edit, 'find-func
  etc. (built-in, but not loaded by default, having their load-entry
  after the "share/emacs/29.2/lisp" entry) aren't affected.

-- 
Suhail

This email is not an offer capable of acceptance, does not evidence an
intention to enter into an agreement, has no operative effect until a
definitive agreement is signed in writing by both parties, and that no
party should act in reliance on the email or any representations of the
sender until a definitive agreement is signed in writing by both
parties.

Previous Next

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