Emacs-Packages should contain native-compiled files

Emacs can interpret/load at least four kinds of source files.

Listed with increasing performance:

- Emacs-Lisp source code: *.el

- Byte-compiled Emacs-Lisp: *.elc

- Native-compiled Emacs-Lisp: *.eln

- Shared-object files: *.so

Guix installs el- and elc-files into ~/.guix-profile/share/emacs/site-lisp which is added to the

environment-variable EMACSLOADPATH. eln-files are installed into

~/.guix-profile/lib/emacs/native-site-lisp which is added to

EMACSNATIVELOADPATH. For Emacs-related so-files, Guix currently

does not have any convention; see

https://issues.guix.gnu.org/63987.

If I understand correctly, it is only the following Emacs-packages that ship with eln-files when installed with Guix, because they specify `#:emacs ,emacs` in the package declaration, so that native-compilation is available during build-time which is used if it's available: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/emacs-utils.scm?h=6d0b3684628fe24555055d4a97d703a1b0b59660#n144

emacs-auctex

emacs-citeproc-el

emacs-zig-mode

emacs-flycheck-grammalecte

emacs-sudo-edit

emacs-elquery

emacs-cov

emacs-pos-tip

emacs-posframe

emacs-xelb

emacs-exwm

emacs-xelb-no-x-toolkit

emacs-exwm-no-x-toolkit

emacs-exwm-x

emacs-jabber

emacs-ement

emacs-circe

emacs-esxml

emacs-nov-el

emacs-wordgen

emacs-picpocket

emacs-lsp-mode

emacs-jsdoc

emacs-tramp

emacs-elpher

emacs-telega

So, if my understanding is correct, and assuming that we want to ship eln-files, Emacs-packages should all be built with a package of Emacs that supports native-compilation.

Hi Mekeor,

Am Mittwoch, dem 12.07.2023 um 18:19 +0000 schrieb Mekeor Melire:

You are correct, but unlike other language ecosystems (e.g. Python or

Common Lisp), we don't have a convenient "package-with-emacs" as of

yet. This is basically step 3 of https://issues.guix.gnu.org/63984#0

of which only step 1 has been concluded so far. (In fact, I need to

merge 29.0.92 into emacs-team, but that shouldn't be as difficult as

the rest in there.) If you want things to happen faster, just tag your

patches with emacs-team and we will review them :)

Cheers

Hi,

On Wed, 12 Jul 2023 at 21:36, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

Just to point that a kind of ’package-with-emacs’ had been discussed in

#41732 [1] and my current understanding is that some corner cases are

annoying.

Emacs packages use 3 variants for “compiling“: emacs-minimal, emacs-no-x

and emacs; see #:emacs in arguments field.

(And I let aside emacs-no-x-toolkit. :-))

Therefore, it does not appear to me easy to have some generic

package-with-emacs for rewriting the “compiler” of the Emacs packages.

Somehow, a profile containing Emacs packages has these packages not

necessary built with the same Emacs build-system compiler but still work

together; contrary to Python, Common Lisp, OCaml or others.

And I do not know what could be an handy way to declare Emacs package

variants. Any idea?

1: https://issues.guix.gnu.org/issue/41732

Cheers,

simon

Hi,

Am Mittwoch, dem 23.08.2023 um 17:37 +0200 schrieb Simon Tournier:

The plan would have been to address those, but we were caught with our

panties down and are behind the latest Emacs release. Oh well, guess

those nice things have to be delayed a little longer.

I don't think there'd be that many cases to consider. You can either

adjust #:emacs (when using emacs-build-system) or you have it as

native-input (when using any other build system). For both cases, you

can add some logic to make that emacs the one used as the argument to

the hypothetical package-with-emacs function.

I'd have to investigate that myself. My basic idea would have been to

copy what Common Lisp is doing and introduce consistent naming, i.e.

have emacs-minimal-org, emacs-no-x-toolkit-org, etc. That being said,

I consider some variants to be more important than others, particularly

regular emacs-PACKAGE > emacs-any-other-variant-PACKAGE. Which ones to

build on CI will imho be much rather a political discussion than a

technical one.

Cheers