GNU bug report logs - #77745
Async native compilation runs every time I start Emacs

Previous Next

To reply to this bug, email your comments to 77745 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Björn Lindqvist <bjourne <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Async native compilation runs every time I start Emacs
Date: Fri, 11 Apr 2025 16:47:17 +0200

The native compiler does not realize that it has already compiled the
code so it recompiles it again every time I restart
Emacs. Unfortunately, the logs don't describe *why* the compiler
thinks the source is stale so debugging the problem is difficult. I
can trigger the recompilation easily just by eagerly loading a package
in my init.el. For example,

    (use-package magit)

will cause magit and all modules it depends on to be recompiled. I'm
using magit as an example, but the same thing happens with most other
packages too. I can prevent recompilation by using lazy loading:

    (use-package magit :defer t)

Then only the file "use-package-core-b234260b-cc1d969d.eln"
gets recompiled. However, I don't think eager loading should trigger
redundant recompilations.

The entirety of my init.el is:

    (setq user-emacs-directory "~/.config/emacs/lisp/")
    (setq package-user-dir "~/.config/emacs/packages/")

    (require 'package)
    (package-initialize)
    (use-package magit)

I've tested with both Emacs 30.1 and 31.0.50 from git and it's the
same problem. Something I noticed is that the "hash" seem to be cut
short during compilation. E.g., the temporary file is called
magit-commit-664f0701-bd4a7b87KHzrEe.eln.tmp but the destination file
magit-commit-664f0701-bd4a7b87.eln. And if I load magit after init.el
it doesn't get recompiled either.

My async compilation log:
https://gist.github.com/bjourne/8958a3918b6f0e61840a5fc10a546b4b


-- 
mvh/best regards Björn Lindqvist

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Björn Lindqvist <bjourne <at> gmail.com>
Cc: 77745 <at> debbugs.gnu.org
Subject: Re: bug#77745: Async native compilation runs every time I start Emacs
Date: Fri, 11 Apr 2025 19:27:09 +0300

> From: Björn Lindqvist <bjourne <at> gmail.com>
> Date: Fri, 11 Apr 2025 16:47:17 +0200
> 
> The native compiler does not realize that it has already compiled the
> code so it recompiles it again every time I restart
> Emacs. Unfortunately, the logs don't describe *why* the compiler
> thinks the source is stale so debugging the problem is difficult. I
> can trigger the recompilation easily just by eagerly loading a package
> in my init.el. For example,
> 
>     (use-package magit)
> 
> will cause magit and all modules it depends on to be recompiled. I'm
> using magit as an example, but the same thing happens with most other
> packages too.

You need to figure out why this happens, because it definitely isn't
happening for others.

Do you see the *.eln files created each time the native compilation is
triggered?  If so, are these files recreated using the same hashes in
the file name, or do the hashes change?  Are the sources moved between
the sessions, perhaps?  Are you always starting the same Emacs binary,
or do you rebuild Emacs between sessions?  Did you customize the value
of native-comp-eln-load-path from its default?

These and other questions need to be answered before we can understand
why you have this problem.

> I can prevent recompilation by using lazy loading:
> 
>     (use-package magit :defer t)
> 
> Then only the file "use-package-core-b234260b-cc1d969d.eln"
> gets recompiled. However, I don't think eager loading should trigger
> redundant recompilations.

What happens if you start "emacs -Q" and then load Magit manually by
"M-x load-library"? does it get recompiled every time in that case?

> 
> The entirety of my init.el is:
> 
>     (setq user-emacs-directory "~/.config/emacs/lisp/")
>     (setq package-user-dir "~/.config/emacs/packages/")
> 
>     (require 'package)
>     (package-initialize)
>     (use-package magit)
> 
> I've tested with both Emacs 30.1 and 31.0.50 from git and it's the
> same problem. Something I noticed is that the "hash" seem to be cut
> short during compilation. E.g., the temporary file is called
> magit-commit-664f0701-bd4a7b87KHzrEe.eln.tmp but the destination file
> magit-commit-664f0701-bd4a7b87.eln. And if I load magit after init.el
> it doesn't get recompiled either.
> 
> My async compilation log:
> https://gist.github.com/bjourne/8958a3918b6f0e61840a5fc10a546b4b

Didn't see any errors there, so it sounds like the compilations all
succeeded.

Is this a recent problem, or did that always happen for you?  If this
started happening only lately, can you tell when?

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

From: Björn Lindqvist <bjourne <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77745 <at> debbugs.gnu.org
Subject: Re: bug#77745: Async native compilation runs every time I start Emacs
Date: Fri, 11 Apr 2025 20:50:17 +0200

> Do you see the *.eln files created each time the native compilation is
> triggered?  If so, are these files recreated using the same hashes in
> the file name, or do the hashes change?  Are the sources moved between
> the sessions, perhaps?  Are you always starting the same Emacs binary,
> or do you rebuild Emacs between sessions?  Did you customize the value
> of native-comp-eln-load-path from its default?

Yes. Same hashes. No. Same binary. Yes! At the top of my init.el I have

    (setq user-emacs-directory "~/.config/emacs/lisp/")

causing *most* .eln files to be dumped in
~/.config/emacs/lisp/eln-cache/31.0.50-859de2ee. However, two
mysterious files are still being written to
~/.config/emacs/eln-cache/31.0.50-859de2ee (no lisp) in the path:

    subr--trampoline-6d616b652d70726f63657373_make_process_0.eln
    subr--trampoline-616c6c2d636f6d706c6574696f6e73_all_completions_0.eln

If I do not set user-emacs-directory, native-comp-eln-load-path stays
at its default value and the recompilation problem goes away. I'll use
that as my workaround since setting user-emacs-directory to a
non-default isn't important for me. It appears that
native-comp-eln-load-path shouldn't be touched from within init.el
because that causes weird side-effects.

As an aside, shouldn't the default native-comp-eln-load-path be
~/.cache/emacs/eln-cache? Cache artifacts aren't meant to be generated in
the configuration hierarchy.


-- 
mvh/best regards Björn Lindqvist

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Björn Lindqvist <bjourne <at> gmail.com>
Cc: 77745 <at> debbugs.gnu.org
Subject: Re: bug#77745: Async native compilation runs every time I start Emacs
Date: Fri, 11 Apr 2025 22:09:59 +0300

> From: Björn Lindqvist <bjourne <at> gmail.com>
> Date: Fri, 11 Apr 2025 20:50:17 +0200
> Cc: 77745 <at> debbugs.gnu.org
> 
> > Do you see the *.eln files created each time the native compilation is
> > triggered?  If so, are these files recreated using the same hashes in
> > the file name, or do the hashes change?  Are the sources moved between
> > the sessions, perhaps?  Are you always starting the same Emacs binary,
> > or do you rebuild Emacs between sessions?  Did you customize the value
> > of native-comp-eln-load-path from its default?
> 
> Yes. Same hashes. No. Same binary. Yes! At the top of my init.el I have
> 
>     (setq user-emacs-directory "~/.config/emacs/lisp/")
> 
> causing *most* .eln files to be dumped in
> ~/.config/emacs/lisp/eln-cache/31.0.50-859de2ee.

Why are you setting the value of user-emacs-directory?

> However, two
> mysterious files are still being written to
> ~/.config/emacs/eln-cache/31.0.50-859de2ee (no lisp) in the path:
> 
>     subr--trampoline-6d616b652d70726f63657373_make_process_0.eln
>     subr--trampoline-616c6c2d636f6d706c6574696f6e73_all_completions_0.eln

Probably because that happens before your modified value of
user-emacs-directory becomes in effect.

> If I do not set user-emacs-directory, native-comp-eln-load-path stays
> at its default value and the recompilation problem goes away.

Then please refrain from changing the value of user-emacs-directory.

> As an aside, shouldn't the default native-comp-eln-load-path be
> ~/.cache/emacs/eln-cache? Cache artifacts aren't meant to be generated in
> the configuration hierarchy.

Sorry, I don't understand the question.  What is "the configuration
hierarchy"?

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

From: Björn Lindqvist <bjourne <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77745 <at> debbugs.gnu.org
Subject: Re: bug#77745: Async native compilation runs every time I start Emacs
Date: Fri, 11 Apr 2025 23:08:16 +0200

> Why are you setting the value of user-emacs-directory?

Because I want the directory emacs packages throw random stuff in to
be distinct from my actual configuration directory. Ephemeral stuff
like ido.last does not belong in the same directory as init.el.

> Then please refrain from changing the value of user-emacs-directory.

I won't. But it is not really clear from the documentation that
user-emacs-directory is not user modifiable. If you google it you can
find plenty of examples of people overriding it in init.el to, for
example, install competing emacs environments (DoomEmacs +
SpacEmacs):

https://emacs.stackexchange.com/questions/4253/how-to-start-emacs-with-a-custom-user-emacs-directory

I assume the same holds true for native-comp-eln-load-path and you are
not supposed to touch that variable either?

> Sorry, I don't understand the question.  What is "the configuration
> hierarchy"?

It's from the XDG Base Directory specification. It stipulates that to
make it easier for users and programs to find files the configuration
files of a program should be stored in ~/.config/<progname> and
"user-specific non-essential (cached) data" should be stored in
~/.cache/<progname>.  The advantage of this scheme is that if you want
to reclaim disk space you can simply rm -rf ~/.cache/<progname> and if
you want to reset a program to its factory default rm -rf
~/.config/<progname>.


-- 
mvh/best regards Björn Lindqvist

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Björn Lindqvist <bjourne <at> gmail.com>
Cc: 77745 <at> debbugs.gnu.org
Subject: Re: bug#77745: Async native compilation runs every time I start Emacs
Date: Sat, 12 Apr 2025 09:39:13 +0300

> From: Björn Lindqvist <bjourne <at> gmail.com>
> Date: Fri, 11 Apr 2025 23:08:16 +0200
> Cc: 77745 <at> debbugs.gnu.org
> 
> > Why are you setting the value of user-emacs-directory?
> 
> Because I want the directory emacs packages throw random stuff in to
> be distinct from my actual configuration directory. Ephemeral stuff
> like ido.last does not belong in the same directory as init.el.
> 
> > Then please refrain from changing the value of user-emacs-directory.
> 
> I won't. But it is not really clear from the documentation that
> user-emacs-directory is not user modifiable. If you google it you can
> find plenty of examples of people overriding it in init.el to, for
> example, install competing emacs environments (DoomEmacs +
> SpacEmacs):
> 
> https://emacs.stackexchange.com/questions/4253/how-to-start-emacs-with-a-custom-user-emacs-directory
> 
> I assume the same holds true for native-comp-eln-load-path and you are
> not supposed to touch that variable either?

People who modify user-emacs-directory in their init files should read
the manual very carefully, and should really understand what they are
doing.  Here are some facts that you probably knew, but perhaps never
considered together to realize what would be the effect of what you
are doing:

  . user-emacs-directory is determined by the startup code, as a side
    effect of looking for your init files
  . the startup code then loads the init files and executes their code
  . native-comp-eln-load-path is computed by the startup code, and it
    has the value of user-emacs-directory pushed onto the list

What this means is that if your init files load packages, directly or
indirectly, before they modify user-emacs-directory, the native
compilation will start for those packages using the value of
native-comp-eln-load-path that is not what your session will
subsequently use.  And packages compiled after user-emacs-directory is
modified will have their *.eln files deposited in another directory.

IOW, the order in which you modify user-emacs-directory and load
packages that need native compilation matters _a_lot_, as you have
discovered.

So, if you really _must_ modify user-emacs-directory, you should do it
in early-init file, and do it the very first thing there.  (Of course,
this means that all the other init files should then live in the
directory which is the updated value of user-emacs-directory.)  We
recommend not to modify the value of user-emacs-directory, because
doing that might break various initializations Emacs performs during
startup.

> > Sorry, I don't understand the question.  What is "the configuration
> > hierarchy"?
> 
> It's from the XDG Base Directory specification. It stipulates that to
> make it easier for users and programs to find files the configuration
> files of a program should be stored in ~/.config/<progname> and
> "user-specific non-essential (cached) data" should be stored in
> ~/.cache/<progname>.  The advantage of this scheme is that if you want
> to reclaim disk space you can simply rm -rf ~/.cache/<progname> and if
> you want to reset a program to its factory default rm -rf
> ~/.config/<progname>.

The eln cache Emacs uses is not really a "cache" XDG spec had in mind.
The *.eln files are not "non-essential", since we want them to
persist, and removing that directory will make the next startup of
Emacs significantly longer and more expensive.  Therefore, we decided
to have the cache under user-emacs-directory, as Emacs generally does
for all of its files.

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

From: Björn Lindqvist <bjourne <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77745 <at> debbugs.gnu.org
Subject: Re: bug#77745: Async native compilation runs every time I start Emacs
Date: Sat, 12 Apr 2025 19:08:05 +0200

Hello again,

I tried setting native-comp-eln-load-path explicitly in init.el

    (setq native-comp-eln-load-path
      (list (expand-file-name "~/tmp/")
            "/opt/emacs/lib/emacs/31.0.50/native-lisp/"))

and this works much better. The native compiler only
writes to ~/tmp/31.0.50-859de2ee/. Not in any directory under
~/.config/emacs. Only the files warnings-28e75f4d-f0ade81c.eln,
icons-eafe82eb-47a1ab50.eln, and cl-lib-8b938900-6d6e9142.eln gets
recompiled on startup.

> What this means is that if your init files load packages, directly or
> indirectly, before they modify user-emacs-directory, the native
> compilation will start for those packages using the value of
> native-comp-eln-load-path that is not what your session will
> subsequently use.  And packages compiled after user-emacs-directory is
> modified will have their *.eln files deposited in another directory.

> IOW, the order in which you modify user-emacs-directory and load
> packages that need native compilation matters _a_lot_, as you have
> discovered.

The first sexp of my init.el is

    (setq user-emacs-directory "~/.config/emacs/lisp/")

which is (?) executed *before* the native compiler kicks in. Unless
something odd happens during *parsing* of init.el, but that seems
far-fetched.

What I think happens is that the native compiler builds the
native-comp-eln-load-path based on the value of user-emacs-directory
before init.el is loaded. Then user-emacs-directory gets modified and
this changes the path it *writes* to, but does nothing to the paths it
*reads* from. So it compiles the files and writes them to a directory
it won't read from the next time I start Emacs. Indeed, if I log
native-comp-eln-load-path I can see that the value is:

    (~/.config/emacs/eln-cache/ /opt/emacs/lib/emacs/31.0.50/native-lisp/)

but the native compiler writes to ~/.config/emacs/lisp/eln-cache/
(note: /lisp/), contradicting the manual: "By default,
asynchronous native compilation writes the *.eln files it produces to
a subdirectory of the first writable directory specified by the
native-comp-eln-load-path variable".

So it must be a bug that setting user-emacs-directory updates the path
the native compiler writes to, but not the path(s) it reads from.

> We recommend not to modify the value of user-emacs-directory,
> because doing that might break various initializations Emacs
> performs during startup.

Are there technical reasons user-emacs-directory can't be changed?
Isn't code that relies on user-emacs-directory having a specific value
or to never change is buggy?

> The eln cache Emacs uses is not really a "cache" XDG spec had in mind.
> The *.eln files are not "non-essential", since we want them to
> persist, and removing that directory will make the next startup of
> Emacs significantly longer and more expensive.

I think what you're describing is exactly what a cache does and
exactly how other programs use $XDG_CACHE_HOME. Of course a program
would take longer to start after you blow up its cache.


--
mvh/best regards Björn Lindqvist

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

From: Ship Mints <shipmints <at> gmail.com>
To: Björn Lindqvist <bjourne <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77745 <at> debbugs.gnu.org
Subject: Re: bug#77745: Async native compilation runs every time I start Emacs
Date: Sat, 12 Apr 2025 13:34:59 -0400

[Message part 1 (text/plain, inline)]

On Sat, Apr 12, 2025 at 1:09 PM Björn Lindqvist <bjourne <at> gmail.com> wrote:

> Hello again,
>
> I tried setting native-comp-eln-load-path explicitly in init.el
>
>     (setq native-comp-eln-load-path
>       (list (expand-file-name "~/tmp/")
>             "/opt/emacs/lib/emacs/31.0.50/native-lisp/"))
>
> and this works much better. The native compiler only
> writes to ~/tmp/31.0.50-859de2ee/. Not in any directory under
> ~/.config/emacs. Only the files warnings-28e75f4d-f0ade81c.eln,
> icons-eafe82eb-47a1ab50.eln, and cl-lib-8b938900-6d6e9142.eln gets
> recompiled on startup.
>
> > What this means is that if your init files load packages, directly or
> > indirectly, before they modify user-emacs-directory, the native
> > compilation will start for those packages using the value of
> > native-comp-eln-load-path that is not what your session will
> > subsequently use.  And packages compiled after user-emacs-directory is
> > modified will have their *.eln files deposited in another directory.
>
> > IOW, the order in which you modify user-emacs-directory and load
> > packages that need native compilation matters _a_lot_, as you have
> > discovered.
>
> The first sexp of my init.el is
>
>     (setq user-emacs-directory "~/.config/emacs/lisp/")
>
> which is (?) executed *before* the native compiler kicks in. Unless
> something odd happens during *parsing* of init.el, but that seems
> far-fetched.
>
> What I think happens is that the native compiler builds the
> native-comp-eln-load-path based on the value of user-emacs-directory
> before init.el is loaded. Then user-emacs-directory gets modified and
> this changes the path it *writes* to, but does nothing to the paths it
> *reads* from. So it compiles the files and writes them to a directory
> it won't read from the next time I start Emacs. Indeed, if I log
> native-comp-eln-load-path I can see that the value is:
>
>     (~/.config/emacs/eln-cache/ /opt/emacs/lib/emacs/31.0.50/native-lisp/)
>
> but the native compiler writes to ~/.config/emacs/lisp/eln-cache/
> (note: /lisp/), contradicting the manual: "By default,
> asynchronous native compilation writes the *.eln files it produces to
> a subdirectory of the first writable directory specified by the
> native-comp-eln-load-path variable".
>
> So it must be a bug that setting user-emacs-directory updates the path
> the native compiler writes to, but not the path(s) it reads from.
>
> > We recommend not to modify the value of user-emacs-directory,
> > because doing that might break various initializations Emacs
> > performs during startup.
>
> Are there technical reasons user-emacs-directory can't be changed?
> Isn't code that relies on user-emacs-directory having a specific value
> or to never change is buggy?
>
> > The eln cache Emacs uses is not really a "cache" XDG spec had in mind.
> > The *.eln files are not "non-essential", since we want them to
> > persist, and removing that directory will make the next startup of
> > Emacs significantly longer and more expensive.
>
> I think what you're describing is exactly what a cache does and
> exactly how other programs use $XDG_CACHE_HOME. Of course a program
> would take longer to start after you blow up its cache.
>

setq is incorrect for overriding native-comp-eln-load-path.  Call
startup-redirect-eln-cache only in your early-init.el file.

As far as overriding user-emacs-directory is concerned, for best results
you should use the --init-directory command-line argument if you can't live
with the default.  The default does respect XDG_CONFIG_HOME and defaults to
XDG_CONFIG_HOME/emacs or ~/.config/emacs then the more traditional
locations, in that priority.  This assumes you do not specify --user.  If
you don't use this method, you'll have to do a census of the variables
dependent on user-emacs-directory and fix them all.  There currently is no
function that does that, and even if there were, if you ran it too late in
your startup cycle, external packages would be tainted with the old value.

[Message part 2 (text/html, inline)]

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

From: Björn Lindqvist <bjourne <at> gmail.com>
To: Ship Mints <shipmints <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77745 <at> debbugs.gnu.org
Subject: Re: bug#77745: Async native compilation runs every time I start Emacs
Date: Sat, 12 Apr 2025 20:14:50 +0200

> setq is incorrect for overriding native-comp-eln-load-path.  Call startup-redirect-eln-cache only in your early-init.el file.
>
> As far as overriding user-emacs-directory is concerned, for best results you should use the --init-directory command-line argument if you can't live with the default.  The default does respect XDG_CONFIG_HOME and defaults to XDG_CONFIG_HOME/emacs or ~/.config/emacs then the more traditional locations, in that priority.  This assumes you do not specify --user.  If you don't use this method, you'll have to do a census of the variables dependent on user-emacs-directory and fix them all.  There currently is no function that does that, and even if there were, if you ran it too late in your startup cycle, external packages would be tainted with the old value.

The manual says that you can modify native-comp-eln-load-path directly:

    Sometimes there could be a need to prevent the native compilation
    from writing its results, the *.eln files, into a subdirectory of
    user-emacs-directory (see The Init File). You can do that by
    either changing the value of native-comp-eln-load-path (see
    Native-Compilation Variables) or by temporarily pointing the HOME
    environment variable to a non-existing directory.

Regardless, it doesn't matter. Having

    (startup-redirect-eln-cache (expand-file-name "~/.cache/emacs/eln/"))

in early-init.el is exactly equivalent to having

    (setq native-comp-eln-load-path
      (list (expand-file-name "~/tmp/")
            "/opt/emacs/lib/emacs/31.0.50/native-lisp/"))

in init.el. The native compiler correctly reads and writes most files
in ~/.cache/emacs/eln/ *except* for warnings-28e75f4d-f0ade81c.eln,
icons-eafe82eb-47a1ab50.eln, and cl-lib-8b938900-6d6e9142.eln which it
keeps recompiling every time I start emacs. The only way I've found to
get it to not recompile warnings, icons, and cl-lib is to keep the
default ~/.config/emacs/eln-cache path.


-- 
mvh/best regards Björn Lindqvist

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

From: Ship Mints <shipmints <at> gmail.com>
To: Björn Lindqvist <bjourne <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77745 <at> debbugs.gnu.org
Subject: Re: bug#77745: Async native compilation runs every time I start Emacs
Date: Sat, 12 Apr 2025 14:49:41 -0400

[Message part 1 (text/plain, inline)]

On Sat, Apr 12, 2025 at 2:15 PM Björn Lindqvist <bjourne <at> gmail.com> wrote:

> > setq is incorrect for overriding native-comp-eln-load-path.  Call
> startup-redirect-eln-cache only in your early-init.el file.
> >
> > As far as overriding user-emacs-directory is concerned, for best results
> you should use the --init-directory command-line argument if you can't live
> with the default.  The default does respect XDG_CONFIG_HOME and defaults to
> XDG_CONFIG_HOME/emacs or ~/.config/emacs then the more traditional
> locations, in that priority.  This assumes you do not specify --user.  If
> you don't use this method, you'll have to do a census of the variables
> dependent on user-emacs-directory and fix them all.  There currently is no
> function that does that, and even if there were, if you ran it too late in
> your startup cycle, external packages would be tainted with the old value.
>
> The manual says that you can modify native-comp-eln-load-path directly:
>
>     Sometimes there could be a need to prevent the native compilation
>     from writing its results, the *.eln files, into a subdirectory of
>     user-emacs-directory (see The Init File). You can do that by
>     either changing the value of native-comp-eln-load-path (see
>     Native-Compilation Variables) or by temporarily pointing the HOME
>     environment variable to a non-existing directory.
>
> Regardless, it doesn't matter. Having
>
>     (startup-redirect-eln-cache (expand-file-name "~/.cache/emacs/eln/"))
>
> in early-init.el is exactly equivalent to having
>
>     (setq native-comp-eln-load-path
>       (list (expand-file-name "~/tmp/")
>             "/opt/emacs/lib/emacs/31.0.50/native-lisp/"))
>

Of course.  But you run the risk of incompatibilities later on.

in init.el. The native compiler correctly reads and writes most files
> in ~/.cache/emacs/eln/ *except* for warnings-28e75f4d-f0ade81c.eln,
> icons-eafe82eb-47a1ab50.eln, and cl-lib-8b938900-6d6e9142.eln which it
> keeps recompiling every time I start emacs. The only way I've found to
> get it to not recompile warnings, icons, and cl-lib is to keep the
> default ~/.config/emacs/eln-cache path.
>

I apologize that I missed what you're trying to accomplish.  If you want to
avoid compiler warnings, perhaps suppress warnings in early init, and then
reenable them in init where it makes sense if you want warnings for
external packages but not core packages?

The load logic is, I think, find the elc file (or make it, if byte
compilation isn't inhibited) along load-path, and if found, probe the eln
cache and swap the eln, if found.

As far as icons and cl-lib recompiles, not sure here.  I also redirect my
eln cache into user-emacs-directory/var/eln-cache and I start Emacs
sessions gobs of times per day both 30 and 31/master and I don't see this
behavior.  What platform are you on and does your build have icons and
cl-lib in its pre-compiled directory?  Are you building Emacs without aot?

[Message part 2 (text/html, inline)]

Previous Next

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