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: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
>> Date: Fri, 05 Nov 2021 15:49:03 +0000
>> 
>> Andrea Corallo <akrl@sdf.org> writes:
>> 
>> [...]
>> >> and why trying that causes this problem?
>> > Still unclear.
>> 
>> To summarize, apparently:
>> 
>> - `cl--generic-get-dispatcher' wants to bytecompile
>> - This requires the usage of `gv-get'
>> - We require comp.el to compile gv.el
>> - Something goes wrong
>
> So what's the road forward?  Do we add gv.el to the list of *.el files
> that need to be natively-compiled as part of the build?  Or are you
> still investigating the issue to figure out what "goes wrong" there?

Hi Eli,

sorry for taking that long.

This is what I reached after further investigation:

The function slot of `gv-setter' was *never* set when we signal the
error.

Here the lisp backtrace when we signal the error "Symbol’s function
definition is void: gv-setter":

Lisp Backtrace:
"gv-setter" (0xffff5248)
"gv-get" (0xffff57b0)
0xf4a1bb58 PVEC_COMPILED
"macroexpand" (0xffff5ea8)
"macroexp-macroexpand" (0xffff6088)
"macroexp--expand-all" (0xffff62a8)
"macroexp--all-forms" (0xffff6438)
"macroexp--expand-all" (0xffff6718)
"macroexp--all-forms" (0xffff6888)
"macroexp--expand-all" (0xffff6ad8)
"macroexp--all-forms" (0xffff6cb8)
"macroexp--expand-all" (0xffff6e98)
"macroexp--all-forms" (0xffff7008)
"macroexp--expand-all" (0xffff7258)
"macroexp--all-forms" (0xffff7438)
"macroexp--expand-all" (0xffff75e8)
"macroexpand-all" (0xffff7728)
"byte-compile-preprocess" (0xffff7898)
0xbda8c0 PVEC_SUBR
"byte-compile" (0xffff7c28)
"cl--generic-get-dispatcher" (0xffff7de8)
"cl--generic-make-next-function" (0xffff7f58)
"cl--generic-make-function" (0xffff8138)
"cl-generic-define-method" (0xffff8340)
"byte-code" (0xffff8750)
"require" (0xffff8c50)
"byte-code" (0xffff9010)
"require" (0xffff9510)
"byte-code" (0xffff9a70)
"defalias" (0xffffa100)
"gv-get" (0xffffa590)
0xf4a1bb58 PVEC_COMPILED
"macroexpand" (0xffffac88)
"macroexp-macroexpand" (0xffffae68)
"macroexp--expand-all" (0xffffb088)
"macroexp--all-forms" (0xffffb218)
"macroexp--expand-all" (0xffffb4f8)
"macroexp--all-forms" (0xffffb668)
"macroexp--expand-all" (0xffffb8b8)
"macroexp--all-forms" (0xffffba98)
"macroexp--expand-all" (0xffffbc78)
"macroexp--all-forms" (0xffffbde8)
"macroexp--expand-all" (0xffffc038)
"macroexp--all-forms" (0xffffc218)
"macroexp--expand-all" (0xffffc3c8)
"macroexpand-all" (0xffffc508)
"byte-compile-preprocess" (0xffffc678)
0xbda8c0 PVEC_SUBR
"byte-compile" (0xffffca08)
"cl--generic-get-dispatcher" (0xffffcbc8)
"cl--generic-make-next-function" (0xffffcd38)
"cl--generic-make-function" (0xffffcf18)
"cl-generic-define-method" (0xffffd120)
"byte-code" (0xffffd500)
0xf4bc8898 PVEC_SUBR
"tty-find-type" (0xffffdb78)
"tty-run-terminal-initialization" (0xffffdd18)
"command-line" (0xffffdec0)
"normal-top-level" (0xffffdf50)

Note that in the stack we have two `gv-get'.  The first one is the one
(as mentioned in my prev mail) that is causing comp.el to be required.
This is really a dependency issue.

I guess option 1 is to native compile gv.el AOT as you've suggested.

Option 2 would be to postpone the native compiler load (if needed) to a
point were we are sure it can be loaded.

If we know gv.el is the only file causing this I'd say the least
impacting solution would be option 1.  But I'm happy also to implement
option 2 if we prefer it and we define where to perform the check and
load of comp.el if needed.

Best Regards

  Andrea