[Top][All Lists]

[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: Wed, 03 Jun 2020 14:23:21 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]