[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")
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 !
Re: Finalizing 'inhibit-automatic-native-compilation', Sean Whitton, 2023/02/02
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/02/02
- Re: Finalizing 'inhibit-automatic-native-compilation', Sean Whitton, 2023/02/02
- Re: Finalizing 'inhibit-automatic-native-compilation', Aymeric Agon-Rambosson, 2023/02/06
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/02/06
- Re: Finalizing 'inhibit-automatic-native-compilation',
Aymeric Agon-Rambosson <=
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/02/07
- Re: Finalizing 'inhibit-automatic-native-compilation', Aymeric Agon-Rambosson, 2023/02/09
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/02/09
- Re: Finalizing 'inhibit-automatic-native-compilation', Sean Whitton, 2023/02/09
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/02/10
- Re: Finalizing 'inhibit-automatic-native-compilation', Aymeric Agon-Rambosson, 2023/02/10
- Re: Finalizing 'inhibit-automatic-native-compilation', Andrea Corallo, 2023/02/10
- Re: Finalizing 'inhibit-automatic-native-compilation', Aymeric Agon-Rambosson, 2023/02/10
- Re: Finalizing 'inhibit-automatic-native-compilation', Andrea Corallo, 2023/02/11
- Re: Finalizing 'inhibit-automatic-native-compilation', Aymeric Agon-Rambosson, 2023/02/11