Re: Finalizing 'inhibit-automatic-native-compilation'

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

> 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).

I believe that's the biggest issue here.  As you have very well
explained 'inhibit-automatic-native-compilation' simply doesn't really
inhibit native compilation.  This is source of user confusion and
issues.

As we can't provide a good command that really disables native
compilation it's better for me to have the two original knobs, one for
jit compilation and one for trampolines.  I personally strongly prefer
no abstraction over a broken one.

I'm very curious about reading the anwers about if
'inhibit-automatic-native-compilation' is used and particularly why.

The only functonality that 'inhibit-automatic-native-compilation'
introduced is to leave the eln cache clean by trampoline files.  IMO if
targetting a tmp directory is not a sufficiently good option we probably
should have controlled this clean-up mechanism with a new value in
`comp-enable-subr-trampolines'.

Best Regards

  Andrea