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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org,  akrl@sdf.org,  larsi@gnus.org,  rlb@defaultvalue.org
> Date: Sat, 28 Jan 2023 12:00:57 -0500
> 
> > 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?
> 
> IIUC the problem is that they need to control this "higher up in the
> scripts" and have it take effect in many Emacs invocations underneath,
> so using an env-var (like $HOME) is an easier solution.  Otherwise they
> may need to tweak many build scripts in many different packages.
> 
> > 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?
> 
> Because one can be controlled via an env-var?

Sorry, I don't buy the "easier" argument.  Distros are not users, they
can do things even if they aren't "easy".

> >> 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
> 
> Yup.  I hope it's "good enough" for our immediate needs, tho.

Not from my POV, no.

> No: what I'm suggesting is to pregenerate the trampolines before we know
> if we'll need them (a bit like `make trampolines`), but to place them
> alongside the code that might need it, so there's no additional "small"
> files containing nothing but a trampoline.  Instead we add tiny chunks
> of code (the trampolines) to other `.eln` files and we do it at a time
> where we know we have GCC at hand.

What do you mean by "alongside"?  The code which needs trampolines is
the code which advises primitives, and that is written in C.  Where
would "alongside" be in that case?

> > 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.
> 
> Actually, I don't know if that would be a problem: while the sum of the
> trampoline files is large, the concatenation of all the trampolines into
> a single `.eln` file should be *much* smaller.

Smaller or not, most of it will be wasted in most sessions.