Re: Building a release tarball generates trampoline files in eln-cache

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> Date: Tue, 09 Nov 2021 21:55:03 +0000
>> 
>> Option 2 would be to postpone the native compiler load (if needed) to a
>> point were we are sure it can be loaded.
>
> You mean, bind no-native-compile to a non-nil value until after some
> point in startup.el?

I was thinking to something a little different like recording what we
wanted to compile when it was not possible cause too early in the
startup.

When startup is finished if this list of pending files is not empty we
should load comp.el (and its dependencies) and then consume the list of
pending .el files to be compiled (possibly including comp.el as well).

> That could work (I actually tried that, but
> under the assumption that xterm.el was the problem, so it didn't
> help).  But why do you think this problem happens only early during
> startup?  Suppose we cross that bridge, and then Emacs needs to load
> some Lisp file that wasn't natively-compiled -- won't we have the same
> problem and for the same reason?  The first gv-get in the backtrace is
> called as part of compiling, so it sounds like every compilation is in
> the danger of triggering this problem, because compiling needs
> gv-setter again.  Or what am I missing?

The first `gv-get' is part of a byte compilation.  With the proposed
mechanism it should go through postponing the comp.el load to say when
we return to `normal-top-level'.

That's not a trivial problem, I might be missing something I don't see
ATM.

  Andrea