[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: |
Thu, 09 Feb 2023 09:40:35 +0100 |
User-agent: |
mu4e 1.6.10; emacs 28.1 |
Le mardi 7 février 2023 à 14:49, Eli Zaretskii <eliz@gnu.org> a
écrit :
I don't think I follow: why not?
Why do you need it to be the first directory?
What I am going to describe is true only in the specific setting I
am presenting, projectile.
After the advice of `file-exists-p' so as to make it always return
t, implemented by this line :
(spy-on 'file-exists-p :and-return-value t)
Whenever we enter the function `comp-subr-trampoline-install', for
instance when we advise another primitive, we will enter the
function `comp-trampoline-search' if :
- we have trampoline compilation enabled
- AND the primitive has not been excluded from trampoline
compilation
- AND the trampoline is not already installed
we will try to install the trampoline, by either finding it on the
filesystem, or if we don't find it, by compiling it.
If `file-exists-p' has been advised as to always return t,
`comp-trampoline-search' will *always* return a filename of the
form :
<first directory returned by
comp-eln-load-path-eff>/subr--trampoline-<hash>_<primitive
name>.eln (or something like this)
*Regardless* of whether said file actually exists, and in
particular even when it should really return nil because the file
does not exist.
So if this file that `comp-trampoline-search' assures us to exist
does not, we reach the error.
So the point was, in order not to reach the error, we need :
- the file subr--trampoline-<hash>_<primitive name>.eln to already
exist.
- AND for it to be in the first directory returned by
`comp-eln-load-path-eff'.
This was just to show that avoiding the problem without resorting
to deactivating trampoline compilation for this specific primitive
is too complicated to bother with.
I hope this answers your first two questions.
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?
I just meant that maybe this assumption of the last directory in
the list being /usr/lib/emacs/<version>/native-lisp was used
somewhere else, and that we should not violate it.
In fact, I seem to remember that a function to prune eln cache
directories from stale eln files was discussed on emacs-devel and
even implemented. This function was later patched as to exclude
the system eln cache from such pruning, for some reason I do not
remember. The "system" eln cache was identified by its being the
last in the list. So there is in fact at least one place in emacs
where this assumption is used, and maybe Andrea or Lars or Stefan
could find others.
But again, this was just part of the hypothetical thinking of
"what should we do if we want to avoid this specific problem
without resorting to disabling primitive trampoline
compilation". That was confusing rather than clarifying, my
mistake.
All the more since we agree on the necessity to be able to disable
trampoline compilation.
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?
So if I follow, we would have these different possible values for
`comp-enable-subr-trampolines' :
- nil means not compiling trampolines (no change with now)
- t means compiling them, and outputting them in the location
either pointed by `native-compile-target-directory' if it
exists, the first valid directory returned by
`comp-eln-load-path-eff' if not (no changes with now)
- a string value means compiling them, and outputting them in the
location pointed by the string (error if unwritable, or fallback
to `native-compile-target-directory' or `comp-eln-load-path-eff'
possibly ?) (this is new)
Would it possible to add a constant value, like
'compile-but-no-output, that would have exactly the second
behaviour I was mentioning before, that is compiling trampolines
but not even trying to output them anywhere, by passing nil as the
last argument of `comp--native-compile' ?
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
That's perfectly reasonable. We would just like to be able to
replicate with these two variables exactly what
`inhibit-automatic-native-compilation' did.
You could do this in the early-init file, which is processed
approximately at the same place in normal-top-level.
If I am not mistaken, the early init file's name is fixed, and is
looked for in various places in the user's home. We do not have an
existing home in our build environment.
Best,
Aymeric
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, 2023/02/07
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/02/07
- Re: Finalizing 'inhibit-automatic-native-compilation',
Aymeric Agon-Rambosson <=
- 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
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/02/11
- Re: Finalizing 'inhibit-automatic-native-compilation', Aymeric Agon-Rambosson, 2023/02/12