emacs-devel
[Top][All Lists]
Advanced

[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: Sun, 12 Feb 2023 20:58:15 +0100
User-agent: mu4e 1.6.10; emacs 28.1


Le dimanche 12 février 2023 à 18:55, Eli Zaretskii <eliz@gnu.org> a écrit :

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: Sun, 12 Feb 2023 17:47:13 +0100

Being able to do (setq comp-enable-subr-trampolines 'compile-but-no-output) would be quite practical. The temporary file would be created by `make-temp-file', according to the value of `temporary-file-directory', and we wouldn't have to worry about specifying some exact location ourselves

Why is it a problem that you provide the location?
"/tmp/SOME-DIRECTORY" is always a possibility, and you can delete the
entire directory when you are done would then get rid of all the
leftovers, something that test runs and installations routinely do.
Why isn't this good enough?

If we have to provide the location, we have to ensure the directory exists. I guess it is not necessarily an issue, but I figured that if the semantic of nil as last argument of `comp--native-compile' and the underlying mechanism of temporary files is already there, and is supposed to stay, we might as well use it.

The current meaning of `inhibit-automatic-native-compilation' is a current "good" state that allowed a large number of build failures to disappear, and it would be reassuring to be able to reproduce that state exactly, before eventually migrating to providing the location ourselves, if we see that we can do so without errors.




reply via email to

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