all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Adam Porter <adam@alphapapa.net>
To: 71725@debbugs.gnu.org
Subject: bug#71725: Emacs emacs-disable-jit-compilation.patch prevents native compilation of packages installed outside of Guix?
Date: Sat, 22 Jun 2024 18:31:54 -0500	[thread overview]
Message-ID: <49f7c34f-38ff-4b4d-be57-1d35c5871df6@alphapapa.net> (raw)

Hello,

I've been installing and running Emacs through Guix as a foreign distro 
for a few years now, and since native compilation was added in Emacs 28 
(before it was even released), I've enjoyed using it to the full, 
including having Elisp packages which are installed directly inside 
Emacs (i.e. not through Guix) be native compiled on-demand.

I just noticed the patch file "emacs-disable-jit-compilation.patch", 
which was added to the Emacs package definition fairly recently, and 
disables the option `native-comp-jit-compilation' by default.  The patch 
includes this warning in the docstring:

"Notably, Guix removes the hashes that prevent inadvertent shadowing
frm the file names of compiled libraries in order to facilitate grafts.
Enable at your own risk!"

So, 1. I would ask that this warning be expanded and clarified.  For 
those of us users who aren't experts in all aspects of Guix, I don't 
understand exactly what this means.  (I do understand what grafts are, 
and I understand how Emacs's ELN files are named to facilitate loading 
correct libraries, but I don't know what Guix is doing with the 
filenames, and I don't know the implications of that.)

For example, if I enable this variable in my configuration so that 
packages not installed through Guix are native-compiled, is that now 
expected to break something?  Before the patch and accompanying changes 
were added, I experienced no problems using native-compilation, 
including making use of built-in, ahead-of-time native-compiled 
libraries, as well as JIT native-compiled libraries installed with 
Emacs's package system.

While I admire Guix's end goal of encompassing everything, I don't want 
to install Elisp packages via Guix.  (For one, being a developer of 
them, it would be impractical.  Even otherwise, not every library is 
going to be available or up-to-date in Guix, and I don't want to have to 
give up native-compilation for them.)  I also don't want to be 
restricted from using native compilation for non-built-in libraries.

Also, 2. I would ask, if indeed enabling that option is now expected to 
break something, that this be remedied in some way.  To expect Guix 
Emacs users to forego native compilation for Elisp packages installed 
from within Emacs would be...well, it would simply be impractical, 
because, as I said, it's not practical (or even desirable) to install 
all Elisp packages with Guix.

To impose such a limitation on users would be reason enough to abandon 
installing Emacs through Guix, even for serious Guix users.  And that 
would be a shame, because this is one of Guix's great strengths, to 
provide up-to-date software, regardless of the underlying system, with 
simplicity and reliability.  If I were to have to go back to building 
and installing Emacs manually, what a regression that would be.

I do want to express my appreciation for the work that was done to get 
to this point.  I looked through, e.g. 
<https://issues.guix.gnu.org/67260>, and I realize that it took a lot of 
hard work to thoroughly integrate Guix with Emacs's native compilation 
features.  Nevertheless, while the current packaging may be ideal for 
the most dedicated Guix users, it seems to have regressed for those of 
us who are less "pure" Guix users, who need more flexibility, and who 
have enjoyed such in the past.

Thanks,
Adam Porter




             reply	other threads:[~2024-06-22 23:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-22 23:31 Adam Porter [this message]
2024-06-23 10:27 ` bug#71725: Emacs emacs-disable-jit-compilation.patch prevents native compilation of packages installed outside of Guix? Liliana Marie Prikler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49f7c34f-38ff-4b4d-be57-1d35c5871df6@alphapapa.net \
    --to=adam@alphapapa.net \
    --cc=71725@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.