Re: Native compilation: the bird-eye view

[Stefan Monnier]

> 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
> ...

Looks good.

> 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.

Long file names are annoying, so removing that level of directory would
make it worse in my book.

> 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').

Good.

> 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.

Fine.  We might want to introduce an `eln-load-path` for that.

> 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?

I don't like this idea (and symlinks are problematic under w32).

> This way we could save one file look-up and simplify the code given we
> would point always and only to the user directory.

A loop around `eln-load-path` seems like a fairly small price to pay and
the extra lookup is likely to be negligible compared to all the lookups we
do to find the `.elc` file anyway.


        Stefan