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

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

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