Re: Suppressing native compilation (short and long term)

[Andrea Corallo]

Hi Rob,

Rob Browning <rlb@defaultvalue.org> writes:

> 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.

This is what `native-comp-deferred-compilation' does.  Well except for
trampolines but this is extremly light as cpu/energy cost.

> 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))
>       ...))

A native compiled Emacs needs to compile a trampoline each time a
primitive is redefined or advised.  If we disable this mechanism ATM we
cannot guarantee Emacs to function correctly.

> 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)?

IMO the suggested change is not okay for the reason mentioned above
sorry :/

>
>   - 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?
>
> [1] For add-on packages (e.g. elpa-*, etc.), we want to explicitly build
>     the local .elc files (at least) during the install, but we don't
>     want to write to any other unexpected locations.
>
> Thanks

IIUC the issue is when Emacs is run as root (I didn't know Debian does
that for installing packages!).  The workaround I'd suggest is to target
a temporary HOME and clean it afterwards with its eln-cache (if this is
viable).

Best Regards

  Andrea