unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: Adam Porter <adam@alphapapa.net>, 71725@debbugs.gnu.org
Subject: bug#71725: Emacs emacs-disable-jit-compilation.patch prevents native compilation of packages installed outside of Guix?
Date: Sun, 23 Jun 2024 12:27:20 +0200	[thread overview]
Message-ID: <cd42faca4e9cd0805561c0c0ccf6614957ea88f7.camel@gmail.com> (raw)
In-Reply-To: <49f7c34f-38ff-4b4d-be57-1d35c5871df6@alphapapa.net>

Hello,

Am Samstag, dem 22.06.2024 um 18:31 -0500 schrieb Adam Porter:
> […T]he patch file "emacs-disable-jit-compilation.patch" […] 
> disables the option `native-comp-jit-compilation' by default [and]
> 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!"
Well, that's a typo I didn't notice before.

> 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.
Well, the short answer is "I don't know".  The long answer is "Even
without disabling this flag, we use the fact that the same file name
points somewhere else for security updates.  Thus, there is a
legitimate use case, but I don't know what specific mess you sign
yourself up to if you do enable this flag on your machine."  In short,
enable this at your own risk.

> 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.
That's understandable, but why do you then need Emacs itself from
Guix?🤔️
If you want to do traditional package management, there ought to be
enough to serve your purpose, perhaps even on your foreign distro.  If
not, you can use an .scm file to define an Emacs without this patch.  I
don't know whether that's desirable for your use case – for us as Guix
the expectation is rather that our own packages work as expected, i.e.
with graftable native-compilation.

> 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.
Sorry, but none of that follows.  We have an importer and updater for
Elisp, so even the packages that are not yet in Guix or out-of-date
ought to be easy to use regardless.  Even outside of Emacs, we have
this whole "Build it with Guix" thing going on – you might want to
consider using a guix.scm for your Emacs packages, particularly if you
need newer versions of things that are not yet in Guix.  Or
contributing.

Cheers




      reply	other threads:[~2024-06-23 10:29 UTC|newest]

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

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=cd42faca4e9cd0805561c0c0ccf6614957ea88f7.camel@gmail.com \
    --to=liliana.prikler@gmail.com \
    --cc=71725@debbugs.gnu.org \
    --cc=adam@alphapapa.net \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).