Le vendredi 4 août 2023 à 11:53, Sean Whitton
<spwhit...@spwhitton.name> a écrit :
My conception of the environment variable is a bit broader than
just
this particular bug: I think that it is a good idea to be able
to switch
off native compilation in the way this environment variable
permits.
Except... The patches do no such thing.
The patches do *not*, I repeat, do *not* switch off native
compilation.
The *only* thing these patches do is :
- If inhibit-automatic-native-compilation (very misleading
variable name indeed) is t, then trampolines are output in a
temporary file.
- If inhibit-automatic-native-compilation is nil, then trampolines
are output in the first available candidate directory, OR in a
temporary directory if no suitable candidate was found.
This is *all* they do, despite the name of the variable that seems
to promise so much more. You see what I mean when I say they are
useless. With or without the patch, in our build environment, we
end up doing the exact same thing : outputting our trampolines to
a file somewhere in /tmp.
You can check this by looking at all the places where the content
of this variable is actually used. You will find that it is only
used in the function comp--trampoline-abs-filename, to do what I
described you it does previously.
Now, if you want to "switch off native compilation", which I agree
is a convenient thing to be able to do, you have two variables
that *really* do something :
- native-comp-jit-compilation, that controls whether loaded .elc
files are asynchronously compiled. Note that this does *not*
include trampolines : even if this variable is nil, trampolines
are still compiled.
- native-comp-enable-subr-trampolines, that controls whether or
not the trampolines are compiled, and where they are
output. Sean, this is the variable I discussed the semantic of
with Andrea. Now, we do *not* want to disable trampoline
compilation, lest we accept to render all advices on primitive
functions null and void (which will cause quite a lot of FTBFS
bugs, many packages advise primitives as part of their
testbed). The docstring of this variable explains this in more
detail.
Controlling these two variables with environment variables
requires only a patch like the following :
diff --git a/lisp/startup.el b/lisp/startup.el
index d6e1c23fa28..3f89df0f119 100644
--- a/lisp/startup.el
+++ b/lisp/startup.el
@@ -595,6 +595,9 @@ It is the default value of the variable `top-level'."
(setq user-emacs-directory
(startup--xdg-or-homedot startup--xdg-config-home-emacs nil))
+ (setq native-comp-jit-compilation (getenv "DEBIAN_ENABLE_NATIVE_COMP_JIT"))
+ (setq native-comp-enable-subr-trampolines (getenv "DEBIAN_ENABLE_NATIVE_COMP_TRAMPOLINES"))
+
(when (featurep 'native-compile)
(unless (native-comp-available-p)
;; Disable deferred async compilation and trampoline synthesis
Which is much simpler than the ones we have now, and actually does
what we want to do.
We would then simply have :
$ENV{'DEBIAN_ENABLE_NATIVE_COMP_JIT'} = 'nil';
in the relevant emacsen-common scripts instead of the current :
$ENV{'EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION'} = 't';
Sean, this is what I meant when I said we should let upstream
focus on the semantic of elisp variables, and just add our tiny
patch on top to be able to control those elisp variables from
environment variables. In fact, after the discussion we've had in
February, they implemented more or less the semantic we wanted. We
need not change it, only give ourselves the means to control it.
I hope I have clarified some misunderstandings.
Best,
Aymeric
