Re: Suppressing native compilation (short and long term)

[Eli Zaretskii]

> From: Rob Browning <rlb@defaultvalue.org>
> Cc: david@tethera.net, emacs-devel@gnu.org, akrl@sdf.org
> Date: Sun, 02 Oct 2022 13:12:01 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Theoretically, yes.  But I don't yet see why the particular context
> > described by Rob is different to the degree that it would need special
> > procedures.
> 
> While I'm not sure where we'll end up, I do think others may put more
> weight on some of the concerns.  For example, across the broader
> world/users-of-debian-and-derivative packages, I suspect there are some
> who care more about storage space.
> 
> As mentioned elswhere, we get regular requests to make emacs-nox even
> smaller.  And my eln-cache is currently 40MB, which is storage space
> we'd thought we might not have to duplicate across the emacs users on a
> system in the common case (Of course I know the duplication rate would
> vary depending on which users use which things, but unless the sets were
> disjoint, there'd be duplication that didn't seem necessary.)

IMO, this is actually an argument _against_ compiling everything AOT.

Whether the duplication is significant can only be decided based on
actual usage figures.  It is incorrect to assess this based on the
*.elc files, since those are independent of almost everything.
There's high probability of wrong decisions based on that analogy.
There are many factors that affect compatibility of *.eln files to
Emacs binaries; for example, it's enough to add or remove a primitive,
and you will need a whol;e new set of *.eln files.  Thus, it is quite
possible that duplication will be smaller and OTOH waste of disk space
due to unnecessarily compiled *.eln files will be higher than you
envision.  Only practice will show the real situation.