[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#72406] [PATCH emacs-team WIP 0/4] Simplify creation of emacs packag
From: |
Liliana Marie Prikler |
Subject: |
[bug#72406] [PATCH emacs-team WIP 0/4] Simplify creation of emacs package variants |
Date: |
Thu, 01 Aug 2024 06:32:26 +0200 |
User-agent: |
Evolution 3.48.4 |
Am Mittwoch, dem 31.07.2024 um 23:23 -0400 schrieb Suhail Singh:
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>
> > With this series, we can make natively-compiled Emacs packages
> > substitutable just like their byte-compiled alternatives – to this
> > end, we also make plain emacs the default for emacs-build-system
>
> I don't follow. What's the advantage to making `emacs' the default
> for emacs-build-system as opposed to `emacs-minimal' ? If this is to
> enable native-compilation, could that not be done via `emacs-no-x'
> instead? `emacs' seems to bring in a number of additional inputs, and
> it's not clear to me that they make a better default.
>
> I propose that the patch to change the defaults for the
> emacs-build-system should perhaps be tackled in a different issue
> than the patch series that provides procedures to create variants of
> packages.
None of the emacsen are native-comp-compatible to each other.
By design: they have different feature sets, so they get different
tags.
For package naming, "emacs" should mean "emacs", not "emacs-minimal" or
"emacs-no-x".
> > and provide procedures to create emacs-next-*, emacs-minimal-*, and
> > emacs-pgtk-* variants of packages.
>
> These seem useful. However, it may help to have an example of one of
> these being used.
Example: I am personally using emacs-pgtk.
> If you split the patch series such that the current issue doesn't
> alter the default for the emacs-build-system, then it might help to
> only provide the procedure for creating an emacs-no-x-* variant
> (since they are pretty similar), and use it for a package like emacs-
> org and/or emacs-magit.
Sure, we could provide that procedure – for now I only provided those
that I'd plan to build on CI.
> > What's still left to do in this series is actually defining all of
> > them. There's quite a number of packages to go over, not all of
> > which build using emacs-build-system.
>
> For the packages that don't use the emacs-build-system today, is the
> idea to switch them to using it? If so, it might help to review that
> list.
No, they would have to be special-cased. There's a bunch of things
emacs-build-system can't account for, which are solved by a simple
Makefile. If anything, we'd extend the procedure to also capture
those.
> > And of course, building N variants of every Emacs package will not
> > make the load for CI lighter, so let's keep N small, shall we? :)
>
> If I am understanding correctly, it seems N can be 1 most of the time
> (corresponding to one of the "current" variants). Sometimes we may
> need a "next" variant, but in those cases a "current" variant likely
> wouldn't suffice.
N should be the number of Emacsen in practical use by the Guix
community, which is currently >= 2.
Cheers
- [bug#72406] [PATCH emacs-team WIP 0/4] Simplify creation of emacs package variants,
Liliana Marie Prikler <=