GNU bug report logs - #70632
[PATCH 1/2] aux-files: comp-integrity: Adjust for newer emacs.

Previous Next

To reply to this bug, email your comments to 70632 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Morgan Smith <Morgan.J.Smith <at> outlook.com>
To: guix-patches <at> gnu.org
Cc: Morgan Smith <Morgan.J.Smith <at> outlook.com>
Subject: [PATCH 1/2] aux-files: comp-integrity: Adjust for newer emacs.
Date: Sun, 28 Apr 2024 13:07:23 -0400

* gnu/packages/aux-files/emacs/comp-integrity.el (expect-help): Update with
new terms for function descriptions.  Also return the description instead of
'nil' on failure to aid in debugging.

Change-Id: I63a3644c91dd7817a72ab11ae87ec4fc8fdb2c1b
---

Hello!

Trying to build the latest Emacs from source fails because they changed the
names of this stuff.  I was able to successfully build the latest Emacs with this patch.

Thanks,

Morgan

 gnu/packages/aux-files/emacs/comp-integrity.el | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/aux-files/emacs/comp-integrity.el b/gnu/packages/aux-files/emacs/comp-integrity.el
index abe7e7c0c9..d969f58622 100644
--- a/gnu/packages/aux-files/emacs/comp-integrity.el
+++ b/gnu/packages/aux-files/emacs/comp-integrity.el
@@ -16,10 +16,16 @@
                 (let ((desc (substring-no-properties
                              (with-output-to-string
                                (help-fns-function-description-header ',fun)))))
-                  (cond ((string-search "native-compiled" desc) 'native)
-                        ((string-search "byte-compiled" desc) 'byte)
-                        ((string-search "built-in" desc) 'built-in)
-                        (t nil))))))))
+                  (cond ((or (string-search "native-compiled" desc) ;; Emacs <= 29
+                             (string-search "subr-native-elisp" desc)) ;; Emacs >= 30
+                         'native)
+                        ((or (string-search "byte-compiled" desc) ;; Emacs <= 29
+                             (string-search "compiled-function" desc)) ;; Emacs >= 30
+                         'byte)
+                        ((or (string-search "built-in" desc) ;; Emacs <= 29
+                             (string-search "primitive-function" desc)) ;; Emacs >= 30
+                         'built-in)
+                        (t desc))))))))
 
   (defmacro expect-native (fun &optional feature)
     `(progn (expect-help ,fun native ,feature)))

base-commit: 9f183c3627a006e8fd3bb9708448bc05a6204e6d
-- 
2.41.0

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

From: Morgan Smith <Morgan.J.Smith <at> outlook.com>
To: 70632 <at> debbugs.gnu.org
Cc: Morgan Smith <Morgan.J.Smith <at> outlook.com>
Subject: [PATCH 2/2] teams: Register the comp-integrity.el file to the Emacs
 team.
Date: Sun, 28 Apr 2024 13:18:06 -0400

* etc/teams.scm (emacs): Add the
"gnu/packages/aux-files/emacs/comp-integrity.el" file to the scope of the Emacs
team.

Change-Id: I66014b94e73fd87eeb3aceaf5f61f08abc875c44
---
 etc/teams.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/etc/teams.scm b/etc/teams.scm
index d537e83efc..73f57d7f1e 100755
--- a/etc/teams.scm
+++ b/etc/teams.scm
@@ -273,6 +273,7 @@ (define-team emacs
         #:description "The extensible, customizable text editor and its
 ecosystem."
         #:scope (list "gnu/packages/aux-files/emacs/guix-emacs.el"
+                      "gnu/packages/aux-files/emacs/comp-integrity.el"
                       (make-regexp* "^gnu/packages/emacs(-.+|)\\.scm$")
                       "gnu/packages/tree-sitter.scm"
                       "guix/build/emacs-build-system.scm"
-- 
2.41.0

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

From: Morgan Smith <Morgan.J.Smith <at> outlook.com>
To: 70632 <at> debbugs.gnu.org
Cc: Morgan Smith <Morgan.J.Smith <at> outlook.com>
Subject: [PATCH v2] aux-files: comp-integrity: Adjust for newer emacs.
Date: Sun, 28 Apr 2024 13:40:51 -0400

* gnu/packages/aux-files/emacs/comp-integrity.el (expect-help): Update with
new terms for function descriptions.  Also return the description instead of
'nil' on failure to aid in debugging.

Change-Id: I63a3644c91dd7817a72ab11ae87ec4fc8fdb2c1b
---

I apologize.  Two hours before I sent the original patch they changed the
descriptions once again.  This patch is the same as before except instead of
"compiled-function" we now have "byte-code-function".

 gnu/packages/aux-files/emacs/comp-integrity.el | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/aux-files/emacs/comp-integrity.el b/gnu/packages/aux-files/emacs/comp-integrity.el
index abe7e7c0c9..0c11100d22 100644
--- a/gnu/packages/aux-files/emacs/comp-integrity.el
+++ b/gnu/packages/aux-files/emacs/comp-integrity.el
@@ -16,10 +16,16 @@
                 (let ((desc (substring-no-properties
                              (with-output-to-string
                                (help-fns-function-description-header ',fun)))))
-                  (cond ((string-search "native-compiled" desc) 'native)
-                        ((string-search "byte-compiled" desc) 'byte)
-                        ((string-search "built-in" desc) 'built-in)
-                        (t nil))))))))
+                  (cond ((or (string-search "native-compiled" desc) ;; Emacs <= 29
+                             (string-search "subr-native-elisp" desc)) ;; Emacs >= 30
+                         'native)
+                        ((or (string-search "byte-compiled" desc) ;; Emacs <= 29
+                             (string-search "byte-code-function" desc)) ;; Emacs >= 30
+                         'byte)
+                        ((or (string-search "built-in" desc) ;; Emacs <= 29
+                             (string-search "primitive-function" desc)) ;; Emacs >= 30
+                         'built-in)
+                        (t desc))))))))
 
   (defmacro expect-native (fun &optional feature)
     `(progn (expect-help ,fun native ,feature)))

base-commit: 9f183c3627a006e8fd3bb9708448bc05a6204e6d
-- 
2.41.0

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

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Morgan Smith <Morgan.J.Smith <at> outlook.com>, 70632 <at> debbugs.gnu.org
Cc: Katherine Cox-Buday <cox.katherine.e+guix <at> gmail.com>,
 Andrew Tropin <andrew <at> trop.in>
Subject: Re: [bug#70632] [PATCH 1/2] aux-files: comp-integrity: Adjust for
 newer emacs.
Date: Mon, 29 Apr 2024 20:44:52 +0200

Hi,

Am Sonntag, dem 28.04.2024 um 13:07 -0400 schrieb Morgan Smith:
> * gnu/packages/aux-files/emacs/comp-integrity.el (expect-help):
> Update with new terms for function descriptions.  Also return the
> description instead of 'nil' on failure to aid in debugging.
> 
> Change-Id: I63a3644c91dd7817a72ab11ae87ec4fc8fdb2c1b
> ---
> 
> Hello!
> 
> Trying to build the latest Emacs from source fails because they
> changed the names of this stuff.  I was able to successfully build
> the latest Emacs with this patch.
> 
> Thanks,
> 
> Morgan
> 
>  gnu/packages/aux-files/emacs/comp-integrity.el | 14 ++++++++++----
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/gnu/packages/aux-files/emacs/comp-integrity.el
> b/gnu/packages/aux-files/emacs/comp-integrity.el
> index abe7e7c0c9..d969f58622 100644
> --- a/gnu/packages/aux-files/emacs/comp-integrity.el
> +++ b/gnu/packages/aux-files/emacs/comp-integrity.el
> @@ -16,10 +16,16 @@
>                  (let ((desc (substring-no-properties
>                               (with-output-to-string
>                                 (help-fns-function-description-header
> ',fun)))))
> -                  (cond ((string-search "native-compiled" desc)
> 'native)
> -                        ((string-search "byte-compiled" desc) 'byte)
> -                        ((string-search "built-in" desc) 'built-in)
> -                        (t nil))))))))
> +                  (cond ((or (string-search "native-compiled" desc)
> ;; Emacs <= 29
> +                             (string-search "subr-native-elisp"
> desc)) ;; Emacs >= 30
> +                         'native)
> +                        ((or (string-search "byte-compiled" desc) ;;
> Emacs <= 29
> +                             (string-search "compiled-function"
> desc)) ;; Emacs >= 30
> +                         'byte)
> +                        ((or (string-search "built-in" desc) ;;
> Emacs <= 29
> +                             (string-search "primitive-function"
> desc)) ;; Emacs >= 30
> +                         'built-in)
> +                        (t desc))))))))
>  
>    (defmacro expect-native (fun &optional feature)
>      `(progn (expect-help ,fun native ,feature)))
> 
> base-commit: 9f183c3627a006e8fd3bb9708448bc05a6204e6d

the change itself LGTM, but I think it should be accompanied by a
change to Emacs 30 and also we should really try to version it because
it rebuilds Emacs as a whole.  The emacs-team branch hasn't been used
for a while and I think there's nothing big there; and neither is there
a need to exercise it if we just add another file and replace the
phase.

Cheers

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

From: Morgan Smith <morgan.j.smith <at> outlook.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: Katherine Cox-Buday <cox.katherine.e+guix <at> gmail.com>, 70632 <at> debbugs.gnu.org,
 Andrew Tropin <andrew <at> trop.in>
Subject: Re: [bug#70632] [PATCH 1/2] aux-files: comp-integrity: Adjust for
 newer emacs.
Date: Mon, 29 Apr 2024 16:43:06 -0400

[Message part 1 (text/plain, inline)]

Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:

> Hi,
>
> the change itself LGTM, but I think it should be accompanied by a
> change to Emacs 30 and also we should really try to version it because
> it rebuilds Emacs as a whole.  The emacs-team branch hasn't been used
> for a while and I think there's nothing big there; and neither is there
> a need to exercise it if we just add another file and replace the
> phase.
>
> Cheers

I think some people might want to build newer Emacs's before the 30
release.  Like how people wanted the pgtk and tree-sitter features
early.  People might want to try the new GC that's being developed.

I'm not a fan of adding another file so I came up with this solution.
See attached patch.

If we believe that a core-updates merge will occur before Emacs 30 then
I would like to see my original patch applied there.

Thanks,

Morgan

[0001-gnu-emacs-next-minimal-Update-to-30.0.50-3.ccb49ac.patch (text/x-patch, attachment)]

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

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Morgan Smith <morgan.j.smith <at> outlook.com>
Cc: Katherine Cox-Buday <cox.katherine.e+guix <at> gmail.com>, 70632 <at> debbugs.gnu.org,
 Andrew Tropin <andrew <at> trop.in>
Subject: Re: [bug#70632] [PATCH 1/2] aux-files: comp-integrity: Adjust for
 newer emacs.
Date: Mon, 29 Apr 2024 23:38:22 +0200

Am Montag, dem 29.04.2024 um 16:43 -0400 schrieb Morgan Smith:
> Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
> 
> > Hi,
> > 
> > the change itself LGTM, but I think it should be accompanied by a
> > change to Emacs 30 and also we should really try to version it
> > because it rebuilds Emacs as a whole.  The emacs-team branch hasn't
> > been used for a while and I think there's nothing big there; and
> > neither is there a need to exercise it if we just add another file
> > and replace the phase.
> > 
> > Cheers
> 
> I think some people might want to build newer Emacs's before the 30
> release.  Like how people wanted the pgtk and tree-sitter features
> early.  People might want to try the new GC that's being developed.
That's fair and we aim to support that case.

> I'm not a fan of adding another file so I came up with this solution.
> See attached patch.
Hmm, I'm a bit torn on the solution.  On one hand, it is a local
solution with just a phase, on the other having the file makes it
easier to just mv it.

> If we believe that a core-updates merge will occur before Emacs 30
> then I would like to see my original patch applied there.
It'd be only emacs-team, not core-updates, but we could do this
"quickly" either way.  But the point behind those is to keep them small
and manageable in a sense, so core-updates is typically not concerned
with leaves or leaf-like stuff.

Cheers

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

From: Morgan Smith <morgan.j.smith <at> outlook.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: Katherine Cox-Buday <cox.katherine.e+guix <at> gmail.com>, 70632 <at> debbugs.gnu.org,
 Andrew Tropin <andrew <at> trop.in>
Subject: Re: [bug#70632] [PATCH 1/2] aux-files: comp-integrity: Adjust for
 newer emacs.
Date: Wed, 01 May 2024 12:32:19 -0400

Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:

> Am Montag, dem 29.04.2024 um 16:43 -0400 schrieb Morgan Smith:
>> Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
>> 
>> I'm not a fan of adding another file so I came up with this solution.
>> See attached patch.
> Hmm, I'm a bit torn on the solution.  On one hand, it is a local
> solution with just a phase, on the other having the file makes it
> easier to just mv it.

I don't understand the trade-offs here.  I'm a fan of keeping data as
close to where it's used as possible (so ideally in emacs.scm).  I'm not
sure what advantages putting it in a file gives over this solution.

Just to be clear: what do you mean by adding another file?  I assume you
mean adding a comp-integrity-next.el file which is almost identical to
comp-integrity.el with these small changes in place.

>> If we believe that a core-updates merge will occur before Emacs 30
>> then I would like to see my original patch applied there.
> It'd be only emacs-team, not core-updates, but we could do this
> "quickly" either way.  But the point behind those is to keep them small
> and manageable in a sense, so core-updates is typically not concerned
> with leaves or leaf-like stuff.

I don't think I understand how our branch development stuff works.  I
thought we put large dependency changes on core-updates so that the CI
could chew through everything and make sure it's good before merging.

Regardless, I trust the team to do the proper procedures.  I simply
believe we might do more package fiddling before Emacs 30 and that
potential problems might be assuaged if the comp-integrity file was more
forgiving and supported every Emacs equally.  Thus, I would encourage it
to be applied in the appropriate place now to avoid potential headache
but if we wish to wait for Emacs 30 that would also be a valid choice.

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

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Morgan Smith <morgan.j.smith <at> outlook.com>
Cc: Katherine Cox-Buday <cox.katherine.e+guix <at> gmail.com>, 70632 <at> debbugs.gnu.org,
 Andrew Tropin <andrew <at> trop.in>
Subject: Re: [bug#70632] [PATCH 1/2] aux-files: comp-integrity: Adjust for
 newer emacs.
Date: Wed, 01 May 2024 18:46:23 +0200

Am Mittwoch, dem 01.05.2024 um 12:32 -0400 schrieb Morgan Smith:
> Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
> 
> > Am Montag, dem 29.04.2024 um 16:43 -0400 schrieb Morgan Smith:
> > > Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
> > > 
> > > I'm not a fan of adding another file so I came up with this
> > > solution.  See attached patch.
> > Hmm, I'm a bit torn on the solution.  On one hand, it is a local
> > solution with just a phase, on the other having the file makes it
> > easier to just mv it.
> 
> I don't understand the trade-offs here.  I'm a fan of keeping data as
> close to where it's used as possible (so ideally in emacs.scm).  I'm
> not sure what advantages putting it in a file gives over this
> solution.
The advantage lies in only rebuilding Emacs 30.

> Just to be clear: what do you mean by adding another file?  I assume
> you mean adding a comp-integrity-next.el file which is almost
> identical to comp-integrity.el with these small changes in place.
Yes.

> > > If we believe that a core-updates merge will occur before Emacs
> > > 30 then I would like to see my original patch applied there.
> > It'd be only emacs-team, not core-updates, but we could do this
> > "quickly" either way.  But the point behind those is to keep them
> > small and manageable in a sense, so core-updates is typically not
> > concerned with leaves or leaf-like stuff.
> 
> I don't think I understand how our branch development stuff works.  I
> thought we put large dependency changes on core-updates so that the
> CI could chew through everything and make sure it's good before
> merging.
Most stuff is now organized within teams that have "smaller"
responsibilities.  I'm responsible for getting Emacs and Gnome updates
way later than we could…

> Regardless, I trust the team to do the proper procedures.  I simply
> believe we might do more package fiddling before Emacs 30 and that
> potential problems might be assuaged if the comp-integrity file was
> more forgiving and supported every Emacs equally.  Thus, I would
> encourage it to be applied in the appropriate place now to avoid
> potential headache but if we wish to wait for Emacs 30 that would
> also be a valid choice.
There are tradeoffs to be made here.  In principle, we could support
"every Emacs ever", in practice, it hardly makes sense.  If you need an
old Emacs in the future, you might as well use the built-in time
machine.

The right place is a new comp-integrity.el.  We can just mv it over the
old one once Emacs 30 is the default Emacs.  We don't yet know how the
help changes for 31, so we can't really ask a crystal ball to insert
the right check.

Cheers

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

From: Morgan Smith <morgan.j.smith <at> outlook.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: Katherine Cox-Buday <cox.katherine.e+guix <at> gmail.com>, 70632 <at> debbugs.gnu.org,
 Andrew Tropin <andrew <at> trop.in>
Subject: Re: [bug#70632] [PATCH 1/2] aux-files: comp-integrity: Adjust for
 newer emacs.
Date: Wed, 01 May 2024 16:06:59 -0400

Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:

> Am Mittwoch, dem 01.05.2024 um 12:32 -0400 schrieb Morgan Smith:
>> Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
>> 
>> > Am Montag, dem 29.04.2024 um 16:43 -0400 schrieb Morgan Smith:
>> > > Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
>> > > 
>> > > I'm not a fan of adding another file so I came up with this
>> > > solution.  See attached patch.
>> > Hmm, I'm a bit torn on the solution.  On one hand, it is a local
>> > solution with just a phase, on the other having the file makes it
>> > easier to just mv it.
>> 
>> I don't understand the trade-offs here.  I'm a fan of keeping data as
>> close to where it's used as possible (so ideally in emacs.scm).  I'm
>> not sure what advantages putting it in a file gives over this
>> solution.
> The advantage lies in only rebuilding Emacs 30.
>
I still feel like I'm conceptually missing something here.  Emacs 30
doesn't actually exist, right?  We are currently on Emacs 29.
emacs-next is the closest thing we have to Emacs 30.  Regardless of if
we create a new file or use my phase I sent, we will only be rebuilding
the emacs-next stuff.  The current emacs (29) is being left alone.

>> Regardless, I trust the team to do the proper procedures.  I simply
>> believe we might do more package fiddling before Emacs 30 and that
>> potential problems might be assuaged if the comp-integrity file was
>> more forgiving and supported every Emacs equally.  Thus, I would
>> encourage it to be applied in the appropriate place now to avoid
>> potential headache but if we wish to wait for Emacs 30 that would
>> also be a valid choice.
> There are tradeoffs to be made here.  In principle, we could support
> "every Emacs ever", in practice, it hardly makes sense.  If you need an
> old Emacs in the future, you might as well use the built-in time
> machine.
>
> The right place is a new comp-integrity.el.  We can just mv it over the
> old one once Emacs 30 is the default Emacs.  We don't yet know how the
> help changes for 31, so we can't really ask a crystal ball to insert
> the right check.

Ok I think I now sort of see your point.  You don't want a build up of
legacy support code in our files.  I do understand and support that and
will send a patch of that nature if you would like.  However, I do think
at least supporting all of the current Emacs packages in guix is a nice
thing to do.

In guix/build/emacs-utils.scm:emacs-generate-autoloads, there is a
condition to support emacs 28.  I don't think we ever use that path
anymore but it is nice to have a robust function that "just works".
Espiaclly back when we did have emacs 28 and 29 packages in guix.

It is my personal opinion, that we should have the file support Emacs 29
and 30 for simplicity sake.  But again, if you disagree with me (which
is valid), I'll send you a patch creating a new file.

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

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Morgan Smith <morgan.j.smith <at> outlook.com>
Cc: Katherine Cox-Buday <cox.katherine.e+guix <at> gmail.com>, 70632 <at> debbugs.gnu.org,
 Andrew Tropin <andrew <at> trop.in>
Subject: Re: [bug#70632] [PATCH 1/2] aux-files: comp-integrity: Adjust for
 newer emacs.
Date: Thu, 02 May 2024 06:24:00 +0200

Am Mittwoch, dem 01.05.2024 um 16:06 -0400 schrieb Morgan Smith:
> 
> I still feel like I'm conceptually missing something here.  Emacs 30
> doesn't actually exist, right?  We are currently on Emacs 29.
> emacs-next is the closest thing we have to Emacs 30.  Regardless of
> if we create a new file or use my phase I sent, we will only be
> rebuilding the emacs-next stuff.  The current emacs (29) is being
> left alone.
> 
> > 
> [...]
> Ok I think I now sort of see your point.  You don't want a build up
> of legacy support code in our files.  I do understand and support
> that and will send a patch of that nature if you would like. 
> However, I do think at least supporting all of the current Emacs
> packages in guix is a nice thing to do.
> 
> It is my personal opinion, that we should have the file support Emacs
> 29 and 30 for simplicity sake.  But again, if you disagree with me
> (which is valid), I'll send you a patch creating a new file.
TL;DR: If we do a new file or a phase, we only rebuild emacs-next.  If
we modify the file in-place, we rebuild emacs, because it uses it. 
Between a phase and a new file, a new file is preferable, because we
can then 'mv' it over the old one.

> In guix/build/emacs-utils.scm:emacs-generate-autoloads, there is a
> condition to support emacs 28.  I don't think we ever use that path
> anymore but it is nice to have a robust function that "just works".
> Espiaclly back when we did have emacs 28 and 29 packages in guix.
This is somewhat legacy code that has grown that way back when Emacs 29
was emacs-next.  There was no good reason to drop it with the switch,
but come Emacs 30, 31, and maintainability might be one.

Cheers

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

From: Morgan Smith <morgan.j.smith <at> outlook.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: Katherine Cox-Buday <cox.katherine.e+guix <at> gmail.com>, 70632 <at> debbugs.gnu.org,
 Andrew Tropin <andrew <at> trop.in>
Subject: Re: [bug#70632] [PATCH 1/2] aux-files: comp-integrity: Adjust for
 newer emacs.
Date: Wed, 08 May 2024 14:48:55 -0400

[Message part 1 (text/plain, inline)]

Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:

> Am Mittwoch, dem 01.05.2024 um 16:06 -0400 schrieb Morgan Smith:
> TL;DR: If we do a new file or a phase, we only rebuild emacs-next.  If
> we modify the file in-place, we rebuild emacs, because it uses it. 
> Between a phase and a new file, a new file is preferable, because we
> can then 'mv' it over the old one.

I apologize.  In my mind we where talking about two different changes at
the same time.  A change to emacs-next right now, and a change that
would rebuild all of emacs but live on a branch for now.

I still think that's the optimal route.  Apply the phase patch right now
to main, and then the file modification to some branch.

On a related note, I do have two changes I'd like to make when we
rebuild all of emacs.  I've attached the changes to this mail despite it
not being quite the right place to send them.  Also I didn't actually
test them because I don't really want to rebuild all of that myself.

>> In guix/build/emacs-utils.scm:emacs-generate-autoloads, there is a
>> condition to support emacs 28.  I don't think we ever use that path
>> anymore but it is nice to have a robust function that "just works".
>> Espiaclly back when we did have emacs 28 and 29 packages in guix.
> This is somewhat legacy code that has grown that way back when Emacs 29
> was emacs-next.  There was no good reason to drop it with the switch,
> but come Emacs 30, 31, and maintainability might be one.

My issue isn't that you're wrong, but rather I would argue "it's not a
big deal".  To maintain clean minimal code we should remove that
condition and so I see your point.  But also, it is such a small
addition of code that adds significant backwards compatibility to the
function.

[0001-build-system-emacs-Allow-usage-of-allowed-disallowed.patch (text/x-patch, attachment)]

[0002-guix-emacs-utils-Be-more-verbose-in-build-phase.patch (text/x-patch, attachment)]

Previous Next

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