bug#58509: 29.0.50; Synchronous nativecomp

[Eli Zaretskii <eliz@gnu.org>]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 58509@debbugs.gnu.org
> Date: Fri, 14 Oct 2022 21:40:06 +0000
> 
> to get practical I think what Lars'd like to have is: at the end of
> 'maybe_swap_for_eln', in case the .eln is not found, a syncronous
> invocation of the native compiler to produce and use the .eln file
> (indeed only when this flag is used).
> 
> In principal as decribed it should be relatively easy, the only
> technical caveat I can think of now are potential circular dependecies
> generated by loading comp.el.

Exactly.  Couldn't this cause an infinite recursion, if compiling a
file needs to load some other file that also needs to be compiled,
etc. etc.?  For example, if some primitive is advised, we'd need to
compile the same trampoline, recursively, no?  How do we break such
vicious circles?

> The comment I have is that we could have this mode capable of being used
> also in interactive sessions, in case I think we should really think of
> a better name for the flag, something like --native-compile-sync?  Or
> anyway something that highlights the "synchronousness" of the enabled
> mechanism.

I don't think the synchronous part is important here.  What is
important is that the Lisp code is natively-compiled before it is
loaded into Emacs.  So something like native-compile-before-load,
perhaps?

Which also suggests a way out of the circular dependency thing: we
could start the compilation in a subprocess and wait for it to finish.
Then any circular dependencies would be solved in the subprocess --
which will run with --batch, so it will simply use byte-compiled Lisp
for its compilation when the corresponding .eln files aren't
available.  Of course, this means when the "main" Emacs loads the
just-produced .eln file, it will find that dependency .el files were
not yet compiled, and will have to stop and wait for their
compilation.  But that is inevitable, I think, and will simply mean we
are serializing the recursion in a brute-force manner.

Does this make sense?