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

[Eli Zaretskii]

> From: Aymeric Agon-Rambosson <aymeric.agon@yandex.com>
> Cc: spwhitton@spwhitton.name, monnier@iro.umontreal.ca, emacs-devel@gnu.org,
>  akrl@sdf.org, larsi@gnus.org, rlb@defaultvalue.org
> Date: Thu, 09 Feb 2023 09:40:35 +0100
> 
> 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'.

So the problem happens because the advice uses the first directory
returned by comp-eln-load-path-eff, for the value it returns, is that
right?  If so, could this then be fixed by changing the advice?

> I hope this answers your first two questions.

It does, thanks.

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

The main reason of having the system directory last is so that
packages could override *.eln files installed in the 'system" eln
directory, which came with Emacs.

> > 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)

Yes.  If the directory pointed to by the value of
comp-enable-subr-trampolines is not writable, I think Emacs should
signal an error.  Andrea, WDYT?

> 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' ?

Argh, the last argument to comp--native-compile is not documented.
AFAIR, setting it to nil means the trampoline will be written to
temporary-file-directory, right?  Because I don't think we can compile
a trampoline without writing it to some file, from which we will
thereafter load it.  (Andrea, please correct me if I'm wrong.)  If so,
we could assume Lisp programs will use temporary-file-directory if
they need this, would that be good enough?

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

Emacs 29 has the --init-directory command-line argument, which you
could use to tell it to look for early-init file in a non-default
place.