Re: Suppressing native compilation (short and long term)

[Lars Ingebrigtsen]

Rob Browning <rlb@defaultvalue.org> writes:

>   - We'd prefer to still be able to set HOME=/does-not-exist, which I
>     assume would mean that we'd need some other way to redirect *all* of
>     the eln file writes (including trampolines).

I think this should work, but there may be regressions, of course.
Let's see...  I tried it now, and I got the warning below, but things
otherwise seem to work fine:

Warning (initialization): Unable to create `user-emacs-directory' (~/.emacs.d/).
Any data that would normally be written there may be lost!
If you never want to see this message again,
customize the variable `user-emacs-directory-warning'.

>   - If we are going to have "some other way" to redirect the eln files,
>     then for us an environment variable might be easier, so that we can
>     just export it before we start the relevant build/test/etc. and then
>     it'll affect all invocations of emacs in that environment.  I
>     suspect an environment variable might also make it easier to
>     establish the setting "early enough" in the emacs startup process,
>     but don't know that.

Emacs 29 now has the `inhibit-automatic-native-compilation' variable and
and `EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION' environment variables
to inhibit writing to ~/.emacs.d/eln-cache...

>   - As an aside, I suspect Emacs may eventually want to have some way to
>     restore the ability to tolerate an unwritable filesystem.  I have
>     more than once in the past launched emacs from an emergency shell to
>     fix a broken host where the filesystem was read-only and /home might
>     not be mounted (and if it were on NFS and there's no network yet,
>     could not be).

Emacs should work with an unwritable file system, but there's probably
code that bugs out in that situation -- but those things should be
fixed.

If you have a test case that demonstrates the problem, please open a bug
report for that, so that we can get fixin'.