Re: Suppressing native compilation (short and long term)

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi Eli,

Am Mittwoch, dem 28.09.2022 um 14:35 +0300 schrieb Eli Zaretskii:
> 
> What do you mean by "disable native compilation" here, and what
> exactly are the use cases for this?  Are we talking about users who
> installed Emacs with some *.eln files, and from time to time load
> *.elc files that have no corresponding *.eln files?  Or are we
> talking about something else?  If the former, why do these users
> install Emacs with native-compilation to begin with?
> 
> More generally, we never expected people who have Emacs with native
> compilation available to want to disable it.  It made no sense to us
> during development of Emacs 28, and frankly, it still doesn't, at
> least to me.  It is so easy to install Emacs without these
> capabilities and never look back that we thought providing a
> build-time option should be enough.  (Well, except for MS-Windows
> users, where more is needed, but that's not your worry.)
> 
> Therefore, if we need to discuss introduction of run-time features
> for disabling native-compilation, we need to have a broader view of
> the relevant use cases and user needs.  This includes at least the
> following aspects that need to be discussed and clarified:
> 
>   . What does "disable native-compilation" mean, exactly?  There are
>     several possible interpretations of that.  Do people want to
>     prevent Emacs from looking for and loading the *.eln files, and
>     use the *.elc files instead?  Or do people only want to prevent
>     Emacs from compiling new *.eln files?  Or do people want that
>     *.eln files be produced only by an explicit user command, not
>     transparently and asynchronously?  Or something else?
> 
>   . When and why would people want any of the above to be possible?
> 
>   . How and why would downstream distros want to support such
>     capabilities?
In GNU Guix, we observe certain packages breaking when trying to
compile them natively.  While some of that is on us for messing up the
package descriptions, one could also encounter genuine bugs in native
compilation that one wants to work around by disabling it.  (For added
trouble, whether or not your package breaks could depend on the CPU due
to being *native* compilation; thus the "no-native-compile" local
variable is insufficient to address this generally.)

In GNU Guix, we default to not compiling packages ahead-of-time,
instead using a minimal emacs that can only do byte compilation for
most packages.  Users can however pretty easily switch to ahead-of-time
compilation by swapping out the emacs package (using what Guix calls
package transformations).  This is also important because apart from
the current Emacs we typically provide an emacs-next package for
upcoming versions, as well as some other variants that the user might
want to use instead.  Again, we assume that users who want to opt in to
native compilation do so via a transformation.

In this context, the default of compiling everything that has hitherto
only been byte-compiled is an ill-advised choice.  Now, there is a
chance that the user meant to do this anyway, but I think they rather
a) use whatever the distro default is without caring either way or b)
actually didn't want this package natively compiled.  Due to some
packages breaking, we had a lot of b) in our mailing lists in the past
few days.

As for loading, I think there could be a case made to restrict loading
to certain directories managed by "trusted entities", but I think
native-comp-eln-load-path already accomplishes this.  If one wanted to
disable loading altogether, I'm pretty sure one could set it to nil and
be done (with perhaps the exception that deferred compilation breaks if
there's no path to store binaries in).

Thus, I think the issue is really only one of inadvertently launching
deferred compilation when all the packages the user *expects* to be
natively compiled are already ensured to be compiled ahead-of-time.  I
admit that this is taking a rather conservative stance, in which the
users don't want to have anything natively compiled that they don't
know of (and as a side result are happy to run that as bytecode or
interpreted code).

I hope this answers some of the questions raised.  In short, we believe
that users might want to control not only from where native shared
libraries will be loaded, but also whether to generate them at runtime,
and that (distro) package managers should enable them to compile all
such shared libraries ahead of time – and better yet, in a reproducible
manner, but this hits other bugs I do not want to discuss in detail at
the moment.

Cheers