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

Previous Next

Full log

Message #17 received at 73681 <at> debbugs.gnu.org (full text, mbox):

From: "Martin Edström" <meedstrom <at> runbox.eu>
To: "Liliana Marie Prikler" <liliana.prikler <at> gmail.com>
Cc: 73681 <73681 <at> debbugs.gnu.org>
Subject: Re: Maybe partly undo the patch on Elisp comp-el-to-eln-filename
Date: Tue, 08 Oct 2024 12:41:26 +0200 (CEST)

On Tue, 08 Oct 2024 06:32:32 +0200, Liliana Marie Prikler <liliana.prikler <at> gmail.com> wrote:

> Could you keep track of modifications to org-node-parser and recompile
> that on change?  Or is it part of your package already – if the latter,
> then we should already have it compiled as a package.

It comes as part of the package. I don't want to assume that it has been compiled, since it's fairly performance-sensitive. That's why I'll either use a previously existing compiled object or make a new one.

What I'm getting from this is that it might be safer to just compile the object into /tmp and use that, regardless of what may already exist.  At the moment, that's necessary for keeping the option open of using an .eln on Guix.

So let's ignore my package, it is just an example of a downstream use of `comp-el-to-eln-filename` that relied on its hashing functionality.

Let's just discuss that function.

I have to point out that the emacs `load-path` does not include any native paths.  When I inspect the value on my non-Guix emacs, I see no references to .../eln-cache/..., just references to directories where there are .elc and .el files.

I infer that Emacs starts with finding a library in load-path, then converts the path with `comp-el-to-eln-filename`, and checks if that file exists, then loads it.

And crucially, it is not just about the filepath, the function hashes the file contents as well. That ensures that the output path is always different if the source file changes.

Since Guix has a patch that removes this effect, it seems like a package could be upgraded many, many times, without the .eln path ever changing, and so the user would stay on that very outdated file.

Is that not a regression/bug?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.