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

[Eli Zaretskii]

> From: Aymeric Agon-Rambosson <aymeric.agon@yandex.com>
> Cc: spwhitton@spwhitton.name, monnier@iro.umontreal.ca, emacs-devel@gnu.org,
>  akrl@sdf.org, larsi@gnus.org, rlb@defaultvalue.org
> Date: Tue, 07 Feb 2023 04:39:09 +0100
> 
> > I don't think I understand: the output of that function depends on
> > native-comp-eln-load-path, so why tweaking that is not enough?
> 
> For this specific problem, if the trampoline has not already been 
> compiled, and can therefore be found in none of the directories in 
> the `native-comp-eln-load-path' list, being able to tweak the 
> variable does us no good.

I don't think I follow: why not?

But maybe this is again because of some special requirements of
mocking-out primitives for testing purposes, in which case stranger
issues could happen.

> If we assume that all trampolines have been compiled beforehand by 
> a mechanism similar to "make trampolines", then we can find the 
> trampolines in the system eln cache directory, but we still need 
> to ensure that this system eln cache directory is the first in the 
> variable `native-comp-eln-load-path'.

Why do you need it to be the first directory?

> However, the docstring says "The last directory of this list is
> assumed to be the system one.".

Are you sure you interpret this correctly? what do you think being a
"system one" means for the purposes of your situation, and why is that
important in the first place?

> This projectile case is very specific, I admit, but just to give 
> you an idea of why we might want to avoid all of this and simply 
> disable trampoline compilation, either globally (which we did not 
> have to do until now) or a specific number of primitives (see the 
> list of my last message).

It is fine with me to disable trampoline compilation; the ability to
do so existed (albeit for different reasons) before
inhibit-automatic-native-compilation was introduced.

> `inhibit-automatic-native-compilation' is not exactly the negation 
> of 
> `native-comp-deferred-compilation'. `inhibit-automatic-native-compilation' 
> also disables the outputting of the result of trampoline 
> compilation to the file system, which solves the other problems 
> related to unwritable $HOME mentioned earlier. This new variable 
> allows for three behaviours :
> - Not compiling trampolines (`comp-enable-subr-trampolines' set to 
>   nil)
> - Compiling them, but not outputting them to the filesystem 
>   (`comp-enable-subr-trampolines' set to non-nil, and 
>   `inhibit-automatic-native-compilation' set to non-nil)
> - Compiling them and outputting them to the filesystem 
>   (`comp-enable-subr-trampolines' set to non-nil, and 
>   `inhibit-automatic-native-compilation' set to nil)
> 
> By contrast, `native-comp-deferred-compilation' and 
> `comp-enable-subr-trampolines' only allowed for the first and the 
> third behaviour.

We intend to modify comp-enable-subr-trampolines so that it could
accept a string value, which would be interpreted as the directory to
place compiled trampolines.  Would that be good enough?

The problem I'm trying to solve is that a boolean variable,
inhibit-automatic-native-compilation, has a two effects that cannot be
separated.  I'd like to have two variables instead (which is basically
what we had in Emacs 28), and add to one of them the ability to accept
a string value.

> > I understand the convenience, but once again, my primary audience
> > is the Emacs users, and they rarely need to handle such convoluted
> > situations.  Some relative inconvenience aside, I see no reason
> > why you couldn't make do without the environment variable, but via
> > some automatically-loaded init files or somesuch.
> 
> I think there was some worry about whether an extra eval would 
> arrive "soon enough", that is before any native compilation would 
> have been attempted. In contrast, the value of the environment 
> variable is obtained at very beginning of `normal-top-level', that 
> is before any native compilation could possibly happen.

You could do this in the early-init file, which is processed
approximately at the same place in normal-top-level.