Finalizing 'inhibit-automatic-native-compilation'

[Eli Zaretskii]

The variable 'inhibit-automatic-native-compilation' was introduced in
last October, as result of various discussions on this list regarding
the need to disable async native-compilation in some situations.
Since its introduction was met with some opposition, in particular
from Andrea, the final decision about whether this variable should
stay in Emacs was deferred, with the purpose of collecting more data
points and user experience.

With the pretest of Emacs 29 just around the corner, I think now is
the time to make that final decision.  With that in mind, I will first
summarize the changes which this variable introduced into Emacs, and
then ask for opinions regarding some of its aspects.

This variable was introduced (under the name
'inhibit-native-compilation') in commit 5fec9182db.  In that commit:

  . comp-trampoline-compile was changed to avoid writing the
    trampolines to the eln-cache if this variable is non-nil (instead,
    it writes the trampolines to a temporary-file directory, and
    attempts to delete them after that, which on Posix platforms will
    cause their deletion when Emacs which produced them exits, and on
    Windows currently fails).
  . In normal-top-level, we set this variable if the environment
    variable EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION is set.
  . In several places this variable either replaces
    native-comp-deferred-compilation or has the same effect as the
    latter (modulo the opposite meaning of nil/t value), therefore
    disabling async compilation of *.el files that Emacs loads for
    which there are no corresponding *.eln files.

Here are the questions I think we want to be answered to finalize the
implementation and effects of 'inhibit-automatic-native-compilation':

  . Do people actually use 'inhibit-automatic-native-compilation' or
    the corresponding environment variable?  If so, for what reasons,
    and why tweaking 'native-comp-eln-load-path' to direct the *.eln
    files to some other place, including the temporary-file directory,
    was not enough?

  . What do we want to do about compiling trampolines when
    native-compilation is disabled?

    Currently, 'inhibit-automatic-native-compilation' doesn't really
    disable compilation of trampolines, it just causes them to be
    written to a temporary location, and hopefully deleted when the
    session ends.  This means that, for example, if the user has a
    broken installation of GCC and Binutils, loading Lisp code that
    uses advices will signal errors when Emacs compiles the
    trampolines (because the compilation fails).
    The alternative is to disable compilation of trampolines, but that
    has a downside that advices for primitives will not have effect.
    It is not clear to me which alternative is better, as they both
    have failure modes.  Note that the build process was augmented so
    you can say, after building Emacs as usual

       make trampolines

    and have all the trampolines for the built-in functions
    (a.k.a. "primitives") compiled and written to the build tree, from
    where they will be installed by "make install", thus minimizing
    potential problems with the need to build trampolines when running
    the installed Emacs.

    If we leave the current build-trampolines-then-delete-them
    machinery intact, is it a problem to have those trampolines not
    deleted on MS-Windows?  They will then be left in the temporary
    directory, and are supposed to be removed by system cleanup
    processes, or maybe remain there forever.  Or do we have to add a
    mechanism for deleting them at exit?

  . Do we want to keep the EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION
    environment variable?

    I dislike having environment variables that alter Emacs behavior,
    because environment variables are inherited by sub-processes.  So
    having this variable set runs the risk of affecting all the
    sub-processes, something that could be unexpected and is not easy
    to prevent.  We had similar problems with EMACSLOADPATH, for
    example, which is especially painful when building another version
    of Emacs from a shell buffer inside Emacs.  This causes some
    hard-to-debug problems.
    So if this environment variable is largely unused, maybe we should
    remove it, even if we keep 'inhibit-automatic-native-compilation'.

Relevant discussions, for those who want to refresh their memories:

  https://lists.gnu.org/archive/html/emacs-devel/2022-09/msg01911.html
  https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-10/msg01126.html

Please respond soon, so as not to delay the pretest of Emacs 29.

TIA