GNU bug report logs - #67260
[PATCH emacs-team 0/2] Think ahead when compiling

Previous Next

Full log

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

From: Suhail <suhail <at> bayesians.ca>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: cox.katherine.e+guix <at> gmail.com, 67260 <at> debbugs.gnu.org,
 Suhail <suhail <at> bayesians.ca>, andrew <at> trop.in
Subject: Re: [bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH.
Date: Sat, 27 Jan 2024 15:36:05 +0000

Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:

> If you compile with emacs-minimal, that's the expected results. 

It was compiled with emacs-minimal=emacs.  For reference, I have inlined
the manifest file that was used (with the --no-grafts CLI option to
guix-package) towards the end of this email.  I'm sharing the one that
was actually used, but it could be minimized.

I believe there are two issues (not including the spurious entry in
native-comp-eln-load-path which may already have been resolved in v7 of
the series).  All my observations below are based on v6 patch series.

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.
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.

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:

> 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

Thank you for your continued work on this!

-- 
Suhail

This email is not an offer capable of acceptance, does not evidence an
intention to enter into an agreement, has no operative effect until a
definitive agreement is signed in writing by both parties, and that no
party should act in reliance on the email or any representations of the
sender until a definitive agreement is signed in writing by both
parties.

Previous Next

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