[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Aymeric Agon-Rambosson
Subject: Re: Finalizing 'inhibit-automatic-native-compilation'
Date: Tue, 07 Feb 2023 04:39:09 +0100
User-agent: mu4e 1.6.10; emacs 28.1

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" <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,

`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 !

reply via email to

[Prev in Thread] Current Thread [Next in Thread]