[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Native compilation: the bird-eye view
From: |
Andrea Corallo |
Subject: |
Re: Native compilation: the bird-eye view |
Date: |
Sat, 16 May 2020 12:58:11 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Eli Zaretskii <address@hidden> 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)
====
--
address@hidden
- Native compilation: the bird-eye view, Eli Zaretskii, 2020/05/16
- Re: Native compilation: the bird-eye view,
Andrea Corallo <=
- Re: Native compilation: the bird-eye view, Paul Eggert, 2020/05/16
- Re: Native compilation: the bird-eye view, Eli Zaretskii, 2020/05/16
- Re: Native compilation: the bird-eye view, Andrea Corallo, 2020/05/16
- Re: Native compilation: the bird-eye view, Eli Zaretskii, 2020/05/16
- Re: Native compilation: the bird-eye view, Andrea Corallo, 2020/05/16
- Re: Native compilation: the bird-eye view, Eli Zaretskii, 2020/05/16
- Re: Native compilation: the bird-eye view, Andrea Corallo, 2020/05/16
- Re: Native compilation: the bird-eye view, Eli Zaretskii, 2020/05/16
- Re: Native compilation: the bird-eye view, Andrea Corallo, 2020/05/16
- Re: Native compilation: the bird-eye view, Andrea Corallo, 2020/05/18