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

Previous Next

Full log

View this message in rfc822 format

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: bug#73681: Maybe partly undo the patch on Elisp comp-el-to-eln-filename
Date: Fri, 18 Oct 2024 18:55:10 +0200 (CEST)

In case anyone reads this, I believe I have the right
algorithm now.

First, the trick to locate an .eln regardless of OS:

    (comp-lookup-eln (locate-library "my-library.el"))

Turns out I do not need the trick, because if an OS like Guix
has indeed shipped an .eln and set it up to be loaded,
then `symbol-file` should return that one.

TL;DR: it took a while to figure out, but the following
snippet is how my program chooses an .el, .elc or .eln that
corresponds to currently loaded Lisp definitions, so that we
know the file is safe to be executed by a subprocess.

If the current definitions come from an .el, then it
opportunistically builds an .eln and returns that instead.
    
    (let ((loaded-file
           (or (ignore-errors
                 (symbol-file 'a-func-from-my-library nil t))
               (symbol-file 'a-func-from-my-library))))
      (if (string-suffix-p ".el" loaded-file)
          (let ((out (comp-el-to-eln-filename loaded-file)))
            (native-compile loaded-file out)
            out)
        loaded-file))

Previous Next

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