[bug#72406] [PATCH emacs-team WIP 0/4] Simplify creation of emacs package variants

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

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