Suppressing native compilation (short and long term)

[Rob Browning <rlb@defaultvalue.org>]

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?

[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
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4