bug#53497: 29.0.50; native-compile after restarting Emacs

[Andrea Corallo]

Andrea Corallo <akrl@sdf.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Arash Esbati <arash@gnu.org>
>>> Cc: Eli Zaretskii <eliz@gnu.org>,  53497@debbugs.gnu.org,  larsi@gnus.org
>>> Date: Fri, 28 Jan 2022 10:24:01 +0100
>>>
>>> Emacs native-compiles a series of files upon start, I skipped opening my
>>> .tex file and re-started Emacs, and it native-compiles the files again,
>>> and this cycle goes on and on.  I'm attaching the results further below.
>>
>> Andrea, I see something similar as well in "emacs -Q -nw" on
>> GNU/Linux: subr-x.el and gv.el are natively-compiled each time I
>> restart Emacs, even though the previously-compiled *.eln files with
>> exactly the same 2 hashes in their names are already present in the
>> ~/.emacs.d/eln-cache/.  Don't you see this on your system?  Perhaps
>> the -nw switch is needed to trigger this, but other than that, I need
>> nothing to reproduce the problem.
>
> I can see it now with "emacs -Q -nw" thanks, I'll look into that.
>
> BR
>
>   Andrea

Okay, I think this is an unrelated issue to the circular dependency one
(that appears to be solved).

I see that when subr-x is required (see following stacktrace)...

"require" (0xffff9ef8)
"byte-code" (0xffffa3e0)
"byte-compile-eval" (0xffffa678)
0xc53bd8 PVEC_COMPILED
"byte-compile-recurse-toplevel" (0xffffad88)
0xb6da60 PVEC_COMPILED
"macroexpand" (0xffffb5a8)
"macroexp-macroexpand" (0xffffb828)
"macroexp--expand-all" (0xffffbbb8)
"macroexp--all-forms" (0xffffbe28)
"macroexp--expand-all" (0xffffc148)
"macroexpand-all" (0xffffc2a8)
"byte-compile-preprocess" (0xffffc428)
0xb82c50 PVEC_SUBR
"byte-compile" (0xffffc7d8)
"cl--generic-get-dispatcher" (0xffffc9a8)
"cl--generic-make-next-function" (0xffffcb28)
"cl--generic-make-function" (0xffffcd18)
"cl-generic-define-method" (0xffffcec8)
"byte-code" (0xffffd3d0)
0xf4b5d448 PVEC_SUBR
"tty-find-type" (0xffffdb28)
"tty-run-terminal-initialization" (0xffffdcd8)
"command-line" (0xffffde90)
"normal-top-level" (0xffffdf20)

...we do not find the coprresponding .eln even if present because
'Vnative_comp_eln_load_path' has still to be updated with the eln-cache
directory of the user.  In my case the content there is only:

("/home/akrl/emacs2/src/../native-lisp/")

Given the .eln is not found we native compile it again.

I suspect this is related to the recent changes of where
`native-comp-eln-load-path' is set, maybe Lars can comment.

Note that I'm on bf695b937e so I should have the very latest changes.

Best Regards

  Andrea