Re: Native compilation: the bird-eye view

[Andrea Corallo]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> This is OK but doubles the length of the effective `load-path`.
> Another option would be to use
>
>     ~/.emacs.d/eln-cache/eln-x86_64-pc-linux-gnu-d241bf45dde51f21/<HASH>.eln
>
> where <HASH> is a hash of the corresponding .el(c) file name.  Similarly, 
> instead of
>
>     /bar/foo.el => /bar/eln-x86_64-pc-linux-gnu-d241bf45dde51f21/foo.eln
>
> we would store those compiled files to a "global eln-cache"
>
>     /bar/foo.el => 
> /usr/lib/eln-cache/eln-x86_64-pc-linux-gnu-d241bf45dde51f21/<HASH>.eln
>
> So we'd have a `eln-cache-path` where to search for those files and when
> loading a file we'd first look for the .el file in `load-path` and once
> found, we'd look inside `eln-cache-path` to see if that file has
> a compiled version available.  `eln-cache-path` would be expected to be
> short (2 entries in the typical case).

This is a good idea.  My concerns are on how the user would interact
with this cache ex: searching if a given eln exists, what's its date,
removing one eln etc.

Should the user goes always through an API we provide?  Or do we want have
everything 100% transparent?

  Andrea

-- 
akrl@sdf.org