Re: Finalizing 'inhibit-automatic-native-compilation'

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org,  Andrea Corallo <akrl@sdf.org>,  Lars Ingebrigtsen
>  <larsi@gnus.org>,  Rob Browning <rlb@defaultvalue.org>
> Date: Fri, 27 Jan 2023 18:57:20 -0500
> 
> AFAICT the main issue is how to handle the case where the home directory
> is not writable (or doesn't exist).  I think the Debian packaging needs
> mostly stem from this.

The Debian use case has other solutions, which don't require disabling
native-compilation.  I never understood why they insisted on
disabling, instead of, say, redirecting the eln-cache to some suitable
place, whether a throwaway directory like /tmp or some other
directory.  I hope maybe Rob will respond now and we could finally
understand why they want to disable the compilation, or they will
understand why disabling is not needed.  Or maybe they do use the
redirect-eln-cache solution after all, and we just don't know?

In any case, inhibit-automatic-native-compilation, as implemented now,
doesn't actually disable compiling the trampolines, it just writes
them to /tmp.  So if that is okay with Debian, why isn't it okay to
tweak native-comp-eln-load-path to do the same to begin with, I
wonder?

> For "normal" compilation, we should just make sure that in the absence
> of a writable eln cache Emacs still behaves correctly, i.e. it should
> just load the `.elc` file and move on (without native-compiling it).

That is already happening, and either native-comp-deferred-compilation
or inhibit-automatic-native-compilation will disable the following
async compilation.  We had this through the entire Emacs 28 release
cycle, and the only new issue that came up was with the trampolines
that are still being compiled and written to the eln-cache.

> For trampolines, in the short term we should probably add a fallback to
> use an eln-cache in the `temporary-file-directory` (i.e. use the code
> we currently use when `inhibit-automatic-native-compilation` is non-nil).

This have two problems:

  . it cleans up only on Posix platforms
  . it is fundamentally broken, since it doesn't actually prevent
    native-compilation, so if the system cannot natively compile at
    all (e.g., if Binutils are not available), this will still signal
    errors

The only solution we could come up with for the latter part is not to
compile trampolines at all, and it has another adverse effect: advices
for primitives will not work.  I don't see any way around these two
problems, we could only make comp-enable-subr-trampolines a variable
that has more than just 2 boolean values, so that people could tweak
the behavior to whatever problems they have with trampolines.

> I think together this should let Debian get the behavior they want, by
> setting HOME to /doesntexist.  And that should make both
> `inhibit-automatic-native-compilation` and
> `EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION` unnecessary.

Such a solution was proposed, but for some reason Debian didn't like
it, or at least that was my impression.

And again, why should we only consider the Debian use case?

> - There's of course the problem of needing to compile trampolines when
>   GCC is absent.  The current `make trampolines` kind of solves that,
>   but it's ridiculously inefficient (the code for the trampolines is
>   trivially small, compared to the size of the generated `.eln`
>   trampoline files).

Why is that a problem? if we leave the compilation of trampolines to
run time, we will produce those same small files, right?  And if you
think about having a single .eln file with all the trampolines, that
is inefficient in another sense: we'd be wasting memory by loading
trampolines which are not actually needed.  So I'm not sure I see a
significant problem here or a significantly better solution for it.