Re: Add a configure option for NATIVE_FULL_AOT?

[Eli Zaretskii <eliz@gnu.org>]

> From: Tom Gillespie <tgbugs@gmail.com>
> Date: Tue, 17 Aug 2021 14:52:10 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>
> 
> Short version: I think concerns about NATIVE_FULL_AOT are
> orthogonal from issues with having native comp enabled at all.

I agree (and never said anything to the contrary).  I was only talking
about the former, if it is treated as the main or even very important
paradigm.

> Indeed, however, the presence of the native-lisp/*/preloaded folder
> means that the
> concerns you raised in the other thread are present regardless of whether
> NATIVE_FULL_AOT is set. For example, trying to modify files.el and get those
> changes to propagate for an invocation of emacs -q is currently not possible due
> to fact that the /preloaded/ els will always be present and will take
> priority when
> native compilation is enabled (removing files-*.eln from preloaded will also
> leave Emacs in a completely broken state as I had the misfortune to learn).

Modification of preloaded Lisp files requires re-dumping Emacs,
always did.  In general, you cannot easily do that without having the
source tree and rebuilding there, not unless you know very well what
to do.  If you do know what to do, the presence of the *.eln files in
preloaded/ doesn't prevent you from rebuilding Emacs: you just need to
replace files*.eln with the newly-compiled one, and re-dump, which is
basically what happens during a re-build.

> One outstanding question is whether eln-cache always has priority
> over native-lisp

It does, except when Emacs knows the particular .eln file should be
put in preloaded/.

> > I didn't invest any thought in it, FWIW.  For me, it was always a "you
> > are on your own" option.  I didn't even try it, as all of the efforts
> > went into making the JIT compilation working well and reliably.
> 
> I think that that will pay off in either case because the underlying
> compilation process is identical (if confusingly named). JIT -> async
> AOT, and FULL AOT just skipping the async bit for the core and doing
> it all at the same time.

I wish it were that simple.  It isn't.  Adding natively-compiled files
raises quite a few issues that didn't exist before, and up to now,
when I thought about these issues, I always considered the JIT modus
operandi, and it alone -- if things sounded right with JIT, I
considered the issue closed.