Re: Native compilation: the bird-eye view

[Andrea Corallo <akrl@sdf.org>]

Eli Zaretskii <eliz@gnu.org> writes:

> Maybe this was already discussed (in which case please point me to
> that discussion), but if not: how will this feature be integrated into
> the Emacs distribution and usage patterns?

I don't think this was discussed already.

> First, we cannot bundle the *.eln files with the source tarball of the
> Emacs release, because these files are too specific to the
> architecture (and perhaps also to the versions of the OS and the libc)
> of the system where they were produced.  Right?

Correct.

> 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.
Who is preparing the Emacs binary should be able to compile and
distribute the eln files too.

> 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 finally, what about the *.elc files and their relation to the
> corresponding *.eln files?  Do we always load a .eln file if
> available, do we let the user specify their preferences, something
> else?

I'd say: if the .eln is present and the suffix is not forced, this
should be preferred to the .elc in the same way now we prefer the .elc
to the .el.


  Andrea


[1] This is what an .eln dynamically link against on GNU/Linux:

====
$ ldd test.eln
        linux-vdso.so.1 (0x00007fff6d215000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3f9bb7a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3f9c16f000)
====
--
akrl@sdf.org