Re: Suppressing native compilation (short and long term)

[Eli Zaretskii]

> From: Rob Browning <rlb@defaultvalue.org>
> Cc: monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org,
>  akrl@sdf.org
> Date: Sun, 02 Oct 2022 13:21:54 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But Emacs should not "crash" if the *.el files aren't available, it
> > should simply refuse to load any *.eln files and load the *.elc files
> > instead.  That produces many warnings, of course, but I hope your
> > users don't consider that "crashing".
> 
> I believe it was *crashing*.  I can't recall if that one was a segfault,
> or something a bit less drastic, but I'll try to remember to track it
> down later.

If it's a real crash, I'd appreciate bug reports, TIA.

> > It isn't a bug, but intended behavior.  If we want to remove this
> > dependency, some non-trivial ideas about reworking the current load
> > procedure should emerge.  I don't thin we have any such ideas at this
> > time.
> 
> OK, so we should consider that a hard dependency now, i.e. the emacs-el
> package can't be optional anymore, at least not on architectures where
> we can enable native compilation, and so probably just "everywhere" for
> simplicity, if nothing else.

More accurately, emacs-el cannot be optional when the installed Emacs
supports native compilation.  Emacs can still be built without native
compilation, and I presume those of your users who want the minimal
possible package will want that, since it removes several significant
dependencies, like libgccjit itself.  When Emacs is built without
native compilation, it can work without the *.el files.