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

[Stefan Monnier]

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

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

AFAICT somewhere along the emacs-28 line, if your $HOME doesn't exist or
the eln-cache is not writable, Emacs failed with an error at startup.
I can't remember if we fixed this before or after Emacs-28.1.

> cycle, and the only new issue that came up was with the trampolines
> that are still being compiled and written to the eln-cache.

Indeed, and at that point if the eln-cache is not writable then we fail,
which is what still need(s|ed) to be fixed.

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

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

Right, that's the more general issue of not being able to generate the
trampolines, for which the only solution is to find a way to pregenerate
the trampolines.  We have not tried that hard enough yet, but I think
it's too late to do that for Emacs-29.

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

Indeed, it's not a solution.

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

My understanding is that we didn't get a clear answer.  Until we have
such a clear answer I'd assume that it *does* solve their problem.

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

AFAIK it's the only request we've had.  All others were satisfied with
`native-comp-deferred-compilation` (except for the fact that it's not
sufficiently documented/discoverable, maybe).

>> - 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).
>
> If we leave the compilation of trampolines to run time, we will
> produce those same small files, right?

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.

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


        Stefan