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

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: emacs-devel@gnu.org,  Lars Ingebrigtsen <larsi@gnus.org>,  Stefan
>  Monnier <monnier@iro.umontreal.ca>,  Rob Browning <rlb@defaultvalue.org>
> Date: Mon, 13 Feb 2023 12:05:09 +0000
> 
> Hello all,
> 
> at feature/inhibit-native-comp-cleanup I've pushed the branch I'm
> testing that:
> 
>   . removes the EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION environment
>     variable
>   . removes `inhibit-automatic-native-compilation' variable and uses
>     `native-comp-deferred-compilation', with or without
>     `comp-enable-subr-trampolines' (as needed), instead
>   . adds a third possible value to `comp-enable-subr-trampolines', a
>     string that specifies a directory in which to deposit the JIT
>     compiled trampolines
>   . updates the doc string of `native-comp-never-optimize-functions' to
>     mention its effect on trampolines
>   . updates some do doc here and there accordingly 

Thanks, I will take a look shortly.

> - I think renaming `native-comp-deferred-compilation' to
>   `native-comp-jit-compilation' might be more descriptive to the user
>   but I guess we are late now? :/
> 
> - If `comp-enable-subr-trampolines' is meant to be used by the user we
>   should probably rename it into `native-comp-enable-subr-trampolines'?
>   I guess we are late as well?

We can add new names, and make the old ones obsolete aliases.  Then we
could remove the obsolete aliases in some future release.

> - I left the piece of code that, when removing an eln file on windows,
>   guards for errors.  This to be extra cautious, I'm not aware of any
>   exection path were we should remove an eln while loaded now, but maybe
>   we could remove that piece of code only on the emacs-30 branch.

Agreed.

> Last question for my knowledge: what's the exact reason why we want a
> third possible value for `comp-enable-subr-trampolines' and we can use
> `native-comp-eln-load-path' to redirect the trampoline compilation?  Is
> this to support packagers wanting to produce eln files only for packages
> but not for trampolines?

That's one treason, AFAIR.  Another is that a single scalar variable
is easier to modify without screwing up than a list of directories,
especially since one of those directories must be the last one...