Re: Native compilation: the bird-eye view

[Andrea Corallo]

Hi all,

so I did some experimentation on moving the eln into a cache directory.

ATM I've something that works this way:

Compiling Emacs elns are produced into a dedicate folder in the source
tree as emacs/eln-cache

Inside there is another directory level to disambiguate triplet and
Emacs configuration:

~/emacs$ ls eln-cache/
x86_64-pc-linux-gnu-f618cbdb0cd39c5f

Inside we have the eln files:

~/emacs$ ls eln-cache/x86_64-pc-linux-gnu-f618cbdb0cd39c5f/
4Corner-6622083dd2e93eda9a23ab8fb261bfd716e557cd3f955484db09a43143948f77.eln
5x5-cf035056577934b61cfe135fec6b6c67af96dd8378fa341ecd6a1b68ee789f48.eln
abbrev-e1c1055cee82bacc9771ef6694dd80578cd97e869a489b42ff5b74ca8e00cbb6.eln
abbrevlist-9cb12f8701f1f34beea0fbf333c35a3643bdec0691490b8fd70579ec26904723.eln
add-log-4a4d094c86ae3143226b9e64aab356b7ced423a8c9b72b2156f75117b4ae1a66.eln
...

I left the original name for comodity at the beginning and the hash
afterwards.  We could enconde in this hash also triplet and
configuration to remove one directory layer but I thought is more handy
for the user to have the eln divided this way.

Anyway, these elns are the one produced during the build, so the one
that will be installed in a sys directory.  As a consequence I've added
a second eln-cache directory for the compilations produced during normal
use placed like ~/.emacs.d/eln-cache (well the exact value is computed
using `user-emacs-directory').

This implies that during a load we check if the file exists first in the
eln user directory and then if necessary in the system one.

I'd like to get some feedback if you guys think this schema makes sense
or you see some issues.

Another question I have: do you think would be accettable at (first)
startup to create the eln user directory and populate it with sym links
for each eln file pointing to the eln in the system eln-cache directory?
This way we could save one file look-up and simplify the code given we
would point always and only to the user directory.

Thanks!

  Andrea

--
akrl@sdf.org