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

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

Le mardi 14 février 2023 à 15:51, Eli Zaretskii <eliz@gnu.org> a 
écrit :

> When will this be useful, and why the existing features don't 
> already
> support whatever use case you had in mind?

The use case we want to have supported is for instance when there 
is no writable home directory, like in the bug report Sean posted 
in the other branch of this conversation.

> As people here pointed out just recently, if Emacs cannot write 
> a .eln
> file, it will still work correctly by using the corresponding 
> .elc
> file.

I could be wrong, but it does not seem to be the case for 
trampolines. In the current state of master, if no writable 
directory can be found for the output of the .eln file containing 
the trampoline, emacs errors out.

> So why do we need a subtle feature of depositing *.eln files in
> a temporary directory

The temporary directory ("/tmp/" on POSIX systems) can potentially 
be the only user-writable directory. So being able to write there 
as a last resort can guarantee that a trampoline compilation will 
not produce an error.

> (which on many systems is ephemeral, or is
> regularly purged)?

(In the case of POSIX systems at least, a program can still expect 
the content of /tmp to be preserved for the duration of its 
current invocation, according to 
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.html). I 
admit I do not know the semantics of the equivalent for Windows.

> By the very nature of temporary files and directories created by
> Emacs, you cannot know their exact name, and so putting a file 
> there
> would be almost completely useless.  So I'm asking when will 
> this be
> useful.  I'd like to avoid adding features whose usability is 
> not well
> understood and whose justification is not solid enough.  We have 
> too
> many subtle knobs in native-compilation already.

The commit added by Andrea (ce4a066ed1e) on the 
inhibit-native-comp-cleanup branch implements the following 
behaviour : if no writable directory is found in either 
`native-comp-target-directory' or in the output of 
`comp-eln-load-path-eff', a filename in the directory 
`temporary-file-directory' is returned. This file is guaranteed to 
be creatable, which is what we wanted to ensure, and we know its 
exact name (you had a good point there). This is I guess 
equivalent to what I wanted to ensure with 'compile-but-no-output, 
so personnally I'm good. But what actually matters are the results 
of Sean's tests, of course.