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

[Eli Zaretskii <eliz@gnu.org>]

> From: Aymeric Agon-Rambosson <aymeric.agon@yandex.com>
> Cc: akrl@sdf.org, spwhitton@spwhitton.name, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org, larsi@gnus.org, rlb@defaultvalue.org
> Date: Tue, 14 Feb 2023 11:36:15 +0100
> 
> >From what I understand, passing nil as last argument to 
> `comp--native-compile' only means that a temporary file will be 
> created in `temporary-file-directory' to store the output of the 
> native compilation process.

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

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.  So why do we need a subtle feature of depositing *.eln files in
a temporary directory (which on many systems is ephemeral, or is
regularly purged)?

> So something like (setq comp-enable-subr-trampolines 
> 'compile-but-no-output) would *only* mean : output to a temporary 
> file in `temporary-file-directory'. It wouldn't also mean "and 
> remove it afterwards". This meaning is perfectly compatible with 
> the removal of the deletion after loading logic.

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.