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

[Eli Zaretskii]

> 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?  That is,
if I load a package, then invoke that function, it will compile all
the trampolines that are not already compiled?

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