Re: Suppressing native compilation (short and long term)

[Eli Zaretskii <eliz@gnu.org>]

> From: Rob Browning <rlb@defaultvalue.org>
> Date: Tue, 27 Sep 2022 20:04:24 -0500
> 
> 
> Perhaps relevant in other contexts, but at least in the context of
> Debian work, we'd like to be able to suppress all native compilation in
> some contexts, or more specifically all writes to HOME (or really, to
> avoid any implicit file manipulations[1]).
> 
> One key case is package builds and package installs (whether the emacs
> packages themselves, or any of the various emacs add-on packages
> (e.g. elpa-*)).
> 
> For package builds, HOME is typically set to /nonexistent (or similar),
> and for package installs we don't want the install commands (preinst,
> postinst, etc.), which are running as root, to write anything to /root/.
> 
> It's also been suggested by some users that they might like to have a
> supported way to disable native compilation (even when it's the system
> default), in order to avoid the unpredictable cpu and/or battery cost
> sometimes.  Of course, assuming we eventually augment debian's current
> emacs infrastructure to generate system-level .eln files during (add-on)
> package installs, in addition to the .elc files it currently produces,
> much of that concern for debian and its derivatives might recede.
> 
> In any case, I noticed that there is a no-native-compile variable, and
> wondered if (in the short term), I might be able to craft a (possibly
> debian-specific for now) way to disable native compilation across the
> board.
> 
> Just to see, I changed no-native-compile to default to
> 
>   (getenv "DEBIAN_EMACS_DISABLE_NATIVE_COMPILATION")
> 
> instead of nil, and then set that in the environment, but the ebib
> package tests (which set HOME=/nonexistent) still crashed (as had been
> originally reported here https://bugs.debian.org/1020191).
> 
> The crash was in comp-trampoline-compile, and after a bit of
> investigation I wondered if it might be possible to fix the problem (at
> least approximately) by adding a no-native-compile clause to the
> comp-subr-trampoline-install guard like this:
> 
>   (defun comp-subr-trampoline-install (subr-name)
>     "Make SUBR-NAME effectively advice-able when called from native code."
>     (unless (or no-native-compilation     ; this is new
>                 (null comp-enable-subr-trampolines)
>                 (memq subr-name native-comp-never-optimize-functions)
>                 (gethash subr-name comp-installed-trampolines-h))
>       ...))
> 
> That did allow the package tests to run successfully.
> 
> So two questions:
> 
>   - As possibly just a short term, debian-specific fix, do those changes
>     sound plausible, or are there other things we're missing (I might
>     guess yes)?
> 
> 
>   - Longer term, might it make sense to have some emacs-proper way to
>     completely disable native compilation from the outside, either via
>     environment variable, argument, or something else, for situations
>     like this?

I admit that I lost you somewhere near the beginning of your post.  I
think what's missing here is some more detailed explanation of the
problems you are trying to solve.  Without them, it is hard to give
you intelligent answers.  Here are some inline questions I'd like to
be answered:

> Perhaps relevant in other contexts, but at least in the context of
> Debian work, we'd like to be able to suppress all native compilation in
> some contexts, or more specifically all writes to HOME (or really, to
> avoid any implicit file manipulations[1]).

What do you mean by "writes to HOME"?  Native-compilation doesn't
write to HOME, it writes to directories in native-comp-eln-load-path.
So basically, you already have a way to redirect stuff to wherever you
want it.

> For package builds, HOME is typically set to /nonexistent (or similar),
> and for package installs we don't want the install commands (preinst,
> postinst, etc.), which are running as root, to write anything to /root/.

By "package installs" do you mean when end-users install a prebuilt
Emacs?  If so, how come that should ever need to write something
outside of the installation tree?  The Emacs "make install" procedure
doesn't, so why do your "package installs" somehow do?

Also, AFAIR installing an ELPA package doesn't produce any *.eln files
until the first time Emacs 'load's their *.elc files.  So why is this
a problem?

OTOH, installing a package from ELPA does write stuff to the user's
directories, so how is the behavior of native-compilation different
here?

> It's also been suggested by some users that they might like to have a
> supported way to disable native compilation (even when it's the system
> default), in order to avoid the unpredictable cpu and/or battery cost
> sometimes.

What do you mean by "disable native compilation" here, and what
exactly are the use cases for this?  Are we talking about users who
installed Emacs with some *.eln files, and from time to time load
*.elc files that have no corresponding *.eln files?  Or are we talking
about something else?  If the former, why do these users install Emacs
with native-compilation to begin with?

More generally, we never expected people who have Emacs with native
compilation available to want to disable it.  It made no sense to us
during development of Emacs 28, and frankly, it still doesn't, at
least to me.  It is so easy to install Emacs without these
capabilities and never look back that we thought providing a
build-time option should be enough.  (Well, except for MS-Windows
users, where more is needed, but that's not your worry.)

Therefore, if we need to discuss introduction of run-time features for
disabling native-compilation, we need to have a broader view of the
relevant use cases and user needs.  This includes at least the
following aspects that need to be discussed and clarified:

  . What does "disable native-compilation" mean, exactly?  There are
    several possible interpretations of that.  Do people want to
    prevent Emacs from looking for and loading the *.eln files, and
    use the *.elc files instead?  Or do people only want to prevent
    Emacs from compiling new *.eln files?  Or do people want that
    *.eln files be produced only by an explicit user command, not
    transparently and asynchronously?  Or something else?

  . When and why would people want any of the above to be possible?

  . How and why would downstream distros want to support such
    capabilities?

Armed with this information, we could then see which use cases are
something we'd like to support in the core and how.

Thanks.