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

Previous Next

Full log

Message #20 received at 72406 <at> debbugs.gnu.org (full text, mbox):

From: Suhail Singh <suhailsingh247 <at> gmail.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: 72406 <at> debbugs.gnu.org, gemmaro.dev <at> gmail.com,
 cox.katherine.e+guix <at> gmail.com, andrew <at> trop.in
Subject: Re: [bug#72406] [PATCH emacs-team WIP 0/4] Simplify creation of
 emacs package variants
Date: Wed, 31 Jul 2024 23:23:36 -0400

Liliana Marie Prikler <liliana.prikler <at> 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.

> 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.

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.

> 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.

> 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.

It's not clear that there's much utility in having multiple "current"
variants, but perhaps that can be discussed at a later date (when and if
such a change is introduced).

-- 
Suhail

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.