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

[Aymeric Agon-Rambosson <aymeric.agon@yandex.com>]

Le lundi 6 février 2023 à 16:29, Eli Zaretskii <eliz@gnu.org> a 
écrit :

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

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'. However, the docstring says 
"The last directory of this list is assumed to be the system 
one.".

So for the variable `native-comp-eln-load-path', in order to 
respect that assumption and solve our projectile problem, we can 
either have :

("/usr/lib/emacs/<version>/native-lisp")

or

("/usr/lib/emacs/<version>/native-lisp" <arbitrary number of user 
eln cache directories> "/usr/lib/emacs/<version>/native-lisp")

The first solution works only if we are sure not to have to load 
any native-compiled elisp from user cache directories, and we 
don't have to native-compile any elisp (if we assume emacs running 
as unpriviledged user).

The second solution could work, I'm not sure whether the same 
value being present twice would create problems.

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

> If those can help you solve your problem, I think that's "good 
> enough"
> for something that needs to be done in a test suite.  My primary
> target audience, in contrast, is Emacs users.

I agree. For this specific case, disabling trampoline compilation 
on the relevant primitives by modifying 
`native-comp-never-optimize-functions' works (see 
https://github.com/bbatsov/projectile/commit/e18ad4d6111eb9e975ccce028baf5e4bb786bfcf), 
and is also the least intrusive way. And since it is not specific 
to our build system, we can reproduce with the upstream sources 
under specific circumstances, those can eventually be patched.

> A similar solution could have solved your problem even if
> inhibit-automatic-native-compilation didn't exist at all,and we 
> only
> had comp-enable-subr-trampolines and 
> native-comp-deferred-compilation,
> right?

`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. This second behaviour is the one we use by 
default now. The trampolines are used in the test (except in the 
pathological cases where they make emacs error or make the test 
fail), but we do not worry about where to output them, because we 
don't.

> Why do you need this to be done together with disabling native
> compilation? why not do it with two separate settings?

We could do it with two separate settings, but if it is decided 
not to get rid of environment variables, that would mean two of 
them.

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

Other than that, I agree that this is mainly a question of 
convenience for us. So much so that, as Sean said, we would 
probably patch it back should it be removed. On top of that, the 
delta corresponding to the environment variable specifically is 
negligible (1 line in normal-top-level) when compared to the delta 
needed to implement the underlying 
`inhibit-automatic-native-compilation'.

Thanks !