bug#73681: Maybe partly undo the patch on Elisp comp-el-to-eln-filename

[Martin Edström]

Hi, thanks for the prompt response!

On Mon, 07 Oct 2024 20:02:17 +0200, Liliana Marie Prikler 
<liliana.prikler@gmail.com> wrote:
> What about aggressive-recompilation-on-write?  

That works in the init.el case, because the user would be the one writing the 
file.  

In my package, the use case is instead that it starts sub-processes, each of 
which should load a file "org-node-parser.eln".  I could ahve made them just 
load the output of (locate-library "org-node-parser"), but for unrelated 
reasons, that seems it would only ever locate an .elc and not an .eln.

So I need to use `comp-el-to-eln-filename` to find the up-to-date .eln (or 
force it to be compiled).  Regardless of whether or not the rest of the package 
has already been native-compiled.

The worst-case scenario is using package version 1.4.1 in the main Emacs 
process, but 1.4.0 of org-node-parser.eln in the subprocesses.  That leads to 
unintended bugs.

I suppose the other way around could also happen - using package version 1.4.0 
but 1.4.1 in the subprocesses - but that'll be my own mess to figure out :)

> We write store paths to a subdirs.el – unless specifically prompted to
> reload that, Emacs will keep using old libraries.  This is by design,
> so that updating Emacs does not cause any issues with (byte) compiled
> files.

Let me know if I understand this correctly: updating a package compiles it at 
the same time, so we can have store paths like

/gnu/store/package-1.4.0/...{.elc,.el,.eln}
/gnu/store/package-1.4.1/...{.elc,.el,.eln}

which sounds like it will be all consistent.  An .eln in the second directory 
would never secretly be 1.4.0, for example.

But since you said we disabled the JIT compilation, and store dirs are 
read-only, where do the .eln actually end up, after the user starts Emacs and 
it does its async-native-compile thing?

(or does it not do any JIT compilation at all?)

I don't have a Guix machine at the moment, but is it a deterministic path like 
~/.emacs.d/eln-cache/29.4-HASH/package-HASH.eln ?  The user in my GitHub issue 
gets no such path from running `comp-el-to-eln-filename`, but maybe they're on 
an old Guix Emacs.