Re: disable automatic native-compilation?

[Eli Zaretskii <eliz@gnu.org>]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Sat, 09 Jul 2022 09:49:59 -0700
> 
> I've just started using Emacs 28. I'm trying run the ada-mode test
> suite, which lauches a new Emacs instance for each test.
> 
> Now that instance also starts a native-compile process, which slows
> things down (a lot), and does not terminate cleanly when the Emacs
> instance does at the end of the test.

How does it not "terminate cleanly"? what uncleanliness is left?
Please do tell the details.

> I'm on Windows, so this pops up a dialog that I have to acknowledge
> eventually.

What dialog did pop up that you needed to acknowledge? what did it
say?

> The elisp manual section on native compilation does not say how to
> disable it.

That's because we don't see a need for disabling that, in a build that
supports native compilation.  The thought was that people who don't
want native compilation will build Emacs without it in the first
place.

> native-comp-deferred-compilation
> 
> The documentation for this variable says:
>     "If non-nil compile loaded .elc files asynchronously."
> 
> what happens if this is nil? the files are compiled synchronously, or
> not at all?

You will need to compile them by hand in that case.  Automatic native
compilation always works asynchronously, because otherwise it would
have wedged your session for many seconds, something that is
unthinkable.

> So, I suggest:
> 
> - There should be a simple way to completely disable native compilation;
> Emacs should never do anything that I can't control.

I don't necessarily agree.  Emacs doesn't do here anything different
from what it did before: it loads a compiled Lisp library when you
request that.  It only compiles it to native code the first time it is
loaded when no .eln file exists for it, that's all.  But that's a
side effect of loading the natively-compiled Lisp that you requested
in a build that _you_ built with natively-compilation support.

It sounds like you encountered problems in some very special
situation, where you are running tests using sub-processes, and your
test suite was not ready for native-compilation.  So I'm not sure we
should draw far-fetching conclusion from your use case.  But whether
this impression of mine is correct can only be established by
discussing the details of your scenario, which you didn't provide.  I
suggest to submit a detailed bug report.

> If setting native-comp-deferred-compilation nil is the right way to
> do this, it should be documented in the native compilation section
> of the elisp manual.

That variable is not a user variable, it exists for internal use
purposes.  The ELisp manual does document how to disable
native-compilation of a specific file (similarly to how you disable
byte-compilation of a file).

> - When native-comp-available-p returns nil, there should be no errors
> about libgccjit

Please tell the details and present a reproducible recipe (preferably
in a bug report), then we can discuss what happens in that specific
situation.  In general, you are not supposed to override that function
unless you know what you are doing.