Re: Native compilation: the bird-eye view

[Eli Zaretskii]

> From: Andrea Corallo <address@hidden>
> Date: Sat, 16 May 2020 12:58:11 +0000
> Cc: address@hidden
> 
> > If so, they will have
> > to be generated on the end-user machines, or perhaps by whoever
> > prepares the Emacs binary distributions -- assuming that the binary
> > distributions are sufficiently compatible to allow that,
> > notwithstanding the differences between the system where the *.eln
> > files were generated and the system where they will be installed and
> > used.  (I don't know what is the granularity of the binary distros wrt
> > machine architecture and OS versions -- will that allow to be sure the
> > *.eln files are compatible with the target system?)
> 
> Given .eln are just shareds with (almost) no dependecies [1] their
> degree of compatibility should be higher then the Emacs binary itself.

Well, the "almost" part means we aren't actually sure about this.
E.g., what about the dependencies related to the GCC version used to
build libgccjit and compile the .eln files?

> > The next question is whether we want the *.eln files to exist up front
> > for all the Lisp files on the end-user system, or we want them to be
> > generated in JIT-like manner, whenever the corresponding Lisp library
> > is loaded on demand?  The answer to this question might then influence
> > the place where the *.eln files are kept -- the JIT alternative would
> > suggest to have some kind of cache directory where we put the compiled
> > files, similar to what Guile does.
> 
> I suspect that for the average user the best is to have the distribution
> do all the compilation upfront for him and have deferred compilation
> handling only additional libraries and packages.

And for the "non-average" user, who builds Emacs from sources?  AFAIU,
native compilation of all Lisp files takes many hours even on fast
machines -- won't this be an annoyance if we don't come up with a JIT
mechanism?