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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Liliana Marie Prikler <liliana.prikler@gmail.com>
>> Cc: Andrea Corallo <akrl@sdf.org>, Lars Ingebrigtsen <larsi@gnus.org>, 
>>  Stefan Monnier <monnier@iro.umontreal.ca>, Rob Browning
>>  <rlb@defaultvalue.org>
>> Date: Sat, 04 Feb 2023 18:48:34 +0100
>> 
>> Since I am on the Guix team for Emacs packaging, I'll try to lay out
>> some concerns both from the perspective of a user and a downstream
>> packager.  I hope I'm not too late to the party.
>
> Thank you for your feedback.
>
>> >   . Do people actually use 'inhibit-automatic-native-compilation' or
>> >     the corresponding environment variable?  If so, for what reasons,
>> >     and why tweaking 'native-comp-eln-load-path' to direct the *.eln
>> >     files to some other place, including the temporary-file
>> > directory,
>> >     was not enough?
>> On Guix, I want my Emacs packages to either (1) already have been
>> natively compiled when using `guix install some-emacs-package' or (2)
>> to not natively compile anything and clutter my user-emacs-directory. 
>> Now the concern about clutter is somewhat secondary to Emacs spending
>> time that some other Emacs could have spent on CI.  (We don't do native
>> compilation on CI *yet*, but imho it would be worth doing for some
>> packages)
>
> That's fine.  Disabling native compilation will continue be supported,
> of course, for any number of reasons.
>
>> >   . What do we want to do about compiling trampolines when
>> >     native-compilation is disabled?
>> In my opinion, there should be a way to generate these trampolines
>> ahead of time in a known location (e.g. $package-trampolines.so) for
>> the emacs package $package.  If no such trampoline is found and native-
>> compilation is disabled, no compilation should take place.
>
> Andrea, I think comp-compile-all-trampolines fits this bill?

Yes I believe so.

> That is,
> if I load a package, then invoke that function, it will compile all
> the trampolines that are not already compiled?

Yes, it will compile all trampolines that are needed *and* are not found
to be already compiled.  If comp-compile-all-trampolines was used before
all trampolines are already available and no trampoline compilation will
be performed.

>> >   . Do we want to keep the EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION
>> >     environment variable?
>> > 
>> >     I dislike having environment variables that alter Emacs behavior,
>> >     because environment variables are inherited by sub-processes.  So
>> >     having this variable set runs the risk of affecting all the
>> >     sub-processes, something that could be unexpected and is not easy
>> >     to prevent.  We had similar problems with EMACSLOADPATH, for
>> >     example, which is especially painful when building another
>> > version
>> >     of Emacs from a shell buffer inside Emacs.  This causes some
>> >     hard-to-debug problems.
>> >     So if this environment variable is largely unused, maybe we
>> > should
>> >     remove it, even if we keep 'inhibit-automatic-native-
>> > compilation'.
>> I don't think a variable is needed necessarily.  What is needed is a
>> method of enabling it reliably on the command line (i.e. a switch like
>> --no-native-compilation would work, but so would --eval '(setq inhibit-
>> automatic-native-compilation t)'), and reliably as a user editing just
>> Emacs configuration files (in particular, early-init.el seems like the
>> place I would naturally place it in).
>
> We already have (and will keep supporting) a way of disabling native
> compilation, and/or the compilation of trampolines, via --eval.
>
> Thanks.
>

Andrea