Re: Suppressing native compilation (short and long term)

[Andrea Corallo]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Lars Ingebrigtsen [2022-10-03 15:29:40] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> AFAICT so far I've heard of two reasons to "disable automatic native
>>> compilation":
>>>
>>> A) Avoid the "uncontrolled" (mostly in terms of *when* it happens)
>>>    resource usage associated with it (e.g. battery).
>>>
>>> B) Avoid writing to $HOME.
>>>
>>> For (A), I think that (setq native-comp-deferred-compilation nil) seems
>>> perfectly sufficient (you can set it early in your (early) init file and if
>>> every blue moon some native compilation still happens because of a file
>>> loaded before that `setq` it shouldn't be a big deal).
>>
>> I've now introduced the new inhibit-native-compilation variable and
>> deprecated the native-comp-deferred-compilation variable, and also
>> initialised stuff from EMACS_INHIBIT_NATIVE_COMPILATION.
>> (And made trampolines not write to the cache in this case.)
>
> AFAICT for the case (A), we *do* want to save trampolines for the next
> time around, and those users probably do want to use native compilation
> (e.g. they would likely set `package-native-compile` to non-nil), just
> not the deferred kind, so the var name is a bit odd for them.

I find this name odd as well. `inhibit-native-compilation' is *not*
disabling native compilation for two reasons:

1- One can still inoke it manually
2- Trampoline automatic ocmpilation is still active

  Andrea