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



reply via email to

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