[bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH.

[Liliana Marie Prikler]

Am Samstag, dem 27.01.2024 um 15:36 +0000 schrieb Suhail:
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> […]
> For emacs-htmlize, I believe the issue may stem from the fact that
> some .eln files are available from entries in native-comp-eln-load-
> path only via symlinks and the .eln loader may not be able to load
> symlinks.  
Would you care to debug this a bit more and report your findings?

> Packages such as ox-html are available from two locations in the
> native-comp-eln-load-path.  In one location they are symlinked, but
> (presumably because org is a builtin package) it is also available
> from another location in the native-comp-eln-load-path and in the
> latter location it's not symlinked in.  I believe this difference is
> why for some packages natively-compiled versions are loaded (e.g.
> org, ox-html, etc) whereas for others it's not the case.
Well, as pointed out in the deleted code, dlopen has a "one shared
library per file name" limitation.  I don't think we're hit by that
thanks to unique hashes in the store directory, but I might be wrong
about that.  Maybe we have to do java-style FQDNs instead.

> In addition, I believe there's another issue.  Some packages' names
> are getting  truncated.  For instance, instead of uniquify.eln, I
> observe niquify.eln.  In this case, the .eln isn't symlinked
> (presumably because it's a builtin), but due to the name being messed
> up (perhaps too aggressive a truncation of hashes?) the natively
> compiled version is not available:
I am not truncating any hashes, I'm not even computing them in the
first place.  The functions I'm modifying are publicly callable, namely
comp-el-to-eln-rel-filename for the relative file names, and
comp-el-to-eln-filename for the absolute ones.

There could be an off-by-one error hidden in the stripping of the
BOGUS_DIRS, however.  Let's investigate that.

> > uniquify-item-p is a byte-compiled Lisp function in `uniquify.el'.
> 
> The manifest file that was used is below.
> 
> #+begin_src scheme
>   (use-modules (guix transformations)
>                (gnu packages))
> 
>   (define transform1
>     (options->transformation
>      '((with-input . "emacs-minimal=emacs")
>        (without-tests . "emacs-clojure-mode"))))
> 
>   (packages->manifest
>     (list (transform1 (specification->package "bash"))
>           (transform1 (specification->package "coreutils"))
>           (transform1 (specification->package "git"))
>           (transform1 (specification->package "make"))
>           (transform1 (specification->package "emacs"))
>           (transform1 (specification->package "emacs-org"))
>           (transform1
>             (specification->package "emacs-org-contrib"))
>           (transform1
>             (specification->package "emacs-citeproc-el"))
>           (transform1
>             (specification->package "emacs-engrave-faces"))
>           (transform1
>             (specification->package "emacs-haskell-mode"))
>           (transform1
>             (specification->package "emacs-htmlize"))
>           (transform1
>             (specification->package "emacs-markdown-mode"))
>           (transform1
>             (specification->package
>               "emacs-org-pandoc-import"))
>           (transform1 (specification->package "pandoc"))
>           ))
> #+end_src
Note, that you can map transform1, saving some typing overhead, and
since you are transforming all of your packages you could compose that
with specification->package.

Cheers