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

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

[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
-- 
2.41.0

[bug#70632] [PATCH v2] aux-files: comp-integrity: Adjust for newer emacs.

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

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

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

[Liliana Marie Prikler]

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

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

[Morgan Smith]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-emacs-next-minimal-Update-to-30.0.50-3.ccb49ac.patch --]
[-- Type: text/x-patch, Size: 3433 bytes --]

From 0440fff5e554d442a113579fbc1330c05da98f6a Mon Sep 17 00:00:00 2001
Message-ID: <0440fff5e554d442a113579fbc1330c05da98f6a.1714423314.git.Morgan.J.Smith@outlook.com>
From: Morgan Smith <Morgan.J.Smith@outlook.com>
Date: Mon, 29 Apr 2024 15:27:59 -0400
Subject: [PATCH] gnu: emacs-next-minimal: Update to 30.0.50-3.ccb49ac.

* gnu/packages/emacs.scm (emacs-next-minimal): Update to 30.0.50-3.ccb49ac.
(emacs->emacs-next): Adjust 'validate-comp-integrity phase for newer Emacs.

Change-Id: Ib191d6044a4a3b56931f893c71dc998fc748245e
---
 gnu/packages/emacs.scm | 34 ++++++++++++++++++++++++++++++----
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 411bea3ab6..022aac416f 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -553,8 +553,8 @@ (define-public emacs-wide-int
         #~(cons "--with-wide-int" #$flags))))))
 
 (define-public emacs-next-minimal
-  (let ((commit "170c6557922dad7e6e9bc0d6dadf6c080108fd42")
-        (revision "2"))
+  (let ((commit "ccb49acd2afb8cec9cec1afba16e16420b9f9261")
+        (revision "3"))
    (package
     (inherit emacs-minimal)
     (name "emacs-next-minimal")
@@ -567,7 +567,7 @@ (define-public emacs-next-minimal
              (commit commit)))
        (file-name (git-file-name name version))
        (sha256
-        (base32 "04carva3b6h9fnlzazrsxsj41hcnjc26kxjij07l159azi40l6sk"))
+        (base32 "1hxwaqjm596yykq42wl28jicd0b8rqcabyb5xp958sirr3yi884b"))
        (patches
         (search-patches "emacs-next-exec-path.patch"
                         "emacs-fix-scheme-indent-function.patch"
@@ -585,7 +585,33 @@ (define* (emacs->emacs-next emacs #:optional name
                                   (string-drop (package-name emacs)
                                                (string-length "emacs"))))))
     (version version)
-    (source source)))
+    (source source)
+    (arguments
+     (substitute-keyword-arguments (package-arguments emacs)
+       ((#:phases phases)
+        #~(modify-phases #$phases
+            (replace 'validate-comp-integrity
+              (lambda* (#:key outputs #:allow-other-keys)
+                #$(cond
+                   ((%current-target-system)
+                    #~(display "Cannot validate native-comp on cross builds.\n"))
+                   ((member (%current-system) '("armhf-linux" "i686-linux"))
+                    #~(display "Integrity test is broken on armhf.\n"))
+                   (else
+                    #~(begin
+                        (copy-file #$(local-file
+                                      (search-auxiliary-file "emacs/comp-integrity.el"))
+                                   "comp-integrity.el")
+                        (substitute* "comp-integrity.el"
+                          (("\"native-compiled\"") "\"subr-native-elisp\"")
+                          (("\"byte-compiled\"") "\"byte-code-function\"")
+                          (("\"built-in\"") "\"primitive-function\""))
+                        (invoke
+                         (string-append (assoc-ref outputs "out") "/bin/emacs")
+                         "--batch"
+                         "--load"
+                         "comp-integrity.el"
+                         "-f" "ert-run-tests-batch-and-exit"))))))))))))
 
 (define-public emacs-next (emacs->emacs-next emacs))
 (define-public emacs-next-pgtk (emacs->emacs-next emacs-pgtk))
-- 
2.41.0

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

[Liliana Marie Prikler]

Am Montag, dem 29.04.2024 um 16:43 -0400 schrieb Morgan Smith:
> Liliana Marie Prikler <liliana.prikler@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

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

[Morgan Smith]

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

> Am Montag, dem 29.04.2024 um 16:43 -0400 schrieb Morgan Smith:
>> Liliana Marie Prikler <liliana.prikler@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.

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

[Liliana Marie Prikler]

Am Mittwoch, dem 01.05.2024 um 12:32 -0400 schrieb Morgan Smith:
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
> > Am Montag, dem 29.04.2024 um 16:43 -0400 schrieb Morgan Smith:
> > > Liliana Marie Prikler <liliana.prikler@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

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

[Morgan Smith]

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

> Am Mittwoch, dem 01.05.2024 um 12:32 -0400 schrieb Morgan Smith:
>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>> 
>> > Am Montag, dem 29.04.2024 um 16:43 -0400 schrieb Morgan Smith:
>> > > Liliana Marie Prikler <liliana.prikler@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.

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

[Liliana Marie Prikler]

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

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

[Morgan Smith]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-build-system-emacs-Allow-usage-of-allowed-disallowed.patch --]
[-- Type: text/x-patch, Size: 5128 bytes --]

From bfb0492b28dddd69bc894de278b5ccbd0d12bd33 Mon Sep 17 00:00:00 2001
Message-ID: <bfb0492b28dddd69bc894de278b5ccbd0d12bd33.1715193630.git.Morgan.J.Smith@outlook.com>
From: Morgan Smith <Morgan.J.Smith@outlook.com>
Date: Wed, 8 May 2024 14:37:46 -0400
Subject: [PATCH 1/2] build-system/emacs: Allow usage of
 #:{allowed/disallowed}-references key

* guix/build-system/emacs.scm (emacs-build): Pass #:allowed-references and

Change-Id: Ib9a35a7b2115365b96675fb7ca3914b0ae7e67c7
#:disallowed-references keys to builder.
---
 guix/build-system/emacs.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/guix/build-system/emacs.scm b/guix/build-system/emacs.scm
index ebf97a5344..35910e1b6d 100644
--- a/guix/build-system/emacs.scm
+++ b/guix/build-system/emacs.scm
@@ -95,7 +95,9 @@ (define* (emacs-build name inputs
                       (imported-modules %emacs-build-system-modules)
                       (modules '((guix build emacs-build-system)
                                  (guix build utils)
-                                 (guix build emacs-utils))))
+                                 (guix build emacs-utils)))
+                      allowed-references
+                      disallowed-references)
   "Build SOURCE using EMACS, and with INPUTS."
   (define builder
     (with-imported-modules imported-modules

base-commit: 7b7f299bb493e485c5534b8c554e51d4f3a8c026
prerequisite-patch-id: 228487164337ccc7df5633c5c6a91fcca993b88a
prerequisite-patch-id: 15497860d4d342179c53c716ebc7039f9c34d785
prerequisite-patch-id: de0d348f5e8f8548bafba10339481a08bd63bcb8
prerequisite-patch-id: 1c516a9ffd4f230d1a0c8a0d32081a6861bfe1de
prerequisite-patch-id: dbf0d15c2b5f4155a322232b2433782721fb6c3d
prerequisite-patch-id: 1034b52682613afdb7b6e71bb33b2a1f99e2051f
prerequisite-patch-id: b3f97a6754c429c6968a861e59c5855e9a0e4984
prerequisite-patch-id: 00a8699a27f340aa6a6e97c4fb45d9ce429cb9d5
prerequisite-patch-id: df520101f3206f576f42f59d7eed65970f7c7775
prerequisite-patch-id: 5123f0e53dedcef03247a9f2eb18479f51808ef2
prerequisite-patch-id: 63c4a90f4de15b5691cff8dbfd570e11725f2a8d
prerequisite-patch-id: 620d07a109a9a819b12bd25b61e36e30a505bc1e
prerequisite-patch-id: cce126a37582a0dd422cb6901c2f36779d53bfbf
prerequisite-patch-id: 4447b1e254600ae044ea29df1a783f41330386b6
prerequisite-patch-id: 44393351676575acadd16c4149722ba56c988c39
prerequisite-patch-id: d9d591e4b630a837ac018d805a0cdd064be5aa65
prerequisite-patch-id: 6f2fa68451c4831841049b9b165a12b98225323c
prerequisite-patch-id: 6a28c36a2bffb2a3fa99cbc7519bc7be2c2e827e
prerequisite-patch-id: f43ed73b1dc78274f954fe053efdd0b424b002ae
prerequisite-patch-id: 4f5110050cc3c6cd44f35e8bdebf413049f362c7
prerequisite-patch-id: 06a0dab6f112fc8bb4859f13f3c943591bc86ca6
prerequisite-patch-id: ac371cc420806e0184e7320260f3aecc795507ad
prerequisite-patch-id: 5218f162fa865cfe23712a8afb9a97c6e00d9a5b
prerequisite-patch-id: 3421e0a088add352ff230c1471bc7d4097fc33f6
prerequisite-patch-id: 59dfcf7314edd1ced95cfa18ad97da01190abd37
prerequisite-patch-id: 088ad347566bb575087253465ff649417de83031
prerequisite-patch-id: 47a3a11659aef5d170e3dd9c8fb174e301087627
prerequisite-patch-id: 45614401deda5bdcd1527f6d7ebb1a916a31d0ff
prerequisite-patch-id: 1cb26e4ca3aec0777e82c362f85102058914eec9
prerequisite-patch-id: be89334a48e8fc0aa033760be7b6bc2a497fcdf5
prerequisite-patch-id: 1fee8851c9fc5ed4f8acf135db668bbeb04d807b
prerequisite-patch-id: 337bc190dcef601af64b7f226acf560d2aff7c4f
prerequisite-patch-id: a6302f36dd276abd7e732cea41a5e94f67e8b87a
prerequisite-patch-id: c5c17c43c0cb139d0bcb28a115fd7d66eb59ee0f
prerequisite-patch-id: faef782b5cd6da66afcbdfaffa5d581d8836f1e3
prerequisite-patch-id: 9fd04d5512c103a3c8ef4992532623351a2e4086
prerequisite-patch-id: d0c9c90f1945b7fa46097290f4e6b30814b8d3c2
prerequisite-patch-id: 9c1eb832e0192fcaf56d2c230bda51a8f72e6c3b
prerequisite-patch-id: b99154be37a07d694e347f158694c366acd71717
prerequisite-patch-id: fe1b89029f914c8de80bf84dedb53f6ae55af562
prerequisite-patch-id: 9e7035825b1a294f8bfccc4714439909ce0e784a
prerequisite-patch-id: 339a1f2719cb4ca7b706070dd2a4632881de9629
prerequisite-patch-id: e721b9f14d8941d07e1eed5071746aa89bf95a37
prerequisite-patch-id: d926e4b96a404967a7bb24e88492444e70ec9c2c
prerequisite-patch-id: 10e91de6d462fbddad8e89980cd628fdd2073b9d
prerequisite-patch-id: 8979df3aeb9fa4996f1d4d8c34bbed0dcdfcc8d6
prerequisite-patch-id: 06831e794460e54dad3ef7991f21800e224530da
prerequisite-patch-id: 85ba9aa78b62a407797db3a27c0d66eb2b92aa2d
prerequisite-patch-id: cb22185b66d1456076d0c6c6e59b2137a102997b
prerequisite-patch-id: 89da8c9f2a3b60756e28b3918543e29b32ea7c03
prerequisite-patch-id: 9e803b98dd169a0902db29b216cb7e284c16b943
prerequisite-patch-id: e4ec309b8a417ffba697c237da4dbe85ccac4e7e
prerequisite-patch-id: 6e46d6b7fc279117848c0e3a0247c1d84ce58505
prerequisite-patch-id: cef5c8dde54b1d3790e6f84fdeafde5a9d8e619b
prerequisite-patch-id: 24f395af4ad8c74bf144c9e2ac0c92c10c77892f
prerequisite-patch-id: cfb34c2a0bbebd6aedb495953cd65a3111b5125f
prerequisite-patch-id: 9084b91d673b95025583ba97f4f33c83c9591f53
prerequisite-patch-id: 4fee8738e04e83ab9952e0a05be51dca05314653
-- 
2.41.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-guix-emacs-utils-Be-more-verbose-in-build-phase.patch --]
[-- Type: text/x-patch, Size: 1311 bytes --]

From 32ba147bbccaa21524487f2fa216cf1f4a18d884 Mon Sep 17 00:00:00 2001
Message-ID: <32ba147bbccaa21524487f2fa216cf1f4a18d884.1715193630.git.Morgan.J.Smith@outlook.com>
In-Reply-To: <bfb0492b28dddd69bc894de278b5ccbd0d12bd33.1715193630.git.Morgan.J.Smith@outlook.com>
References: <bfb0492b28dddd69bc894de278b5ccbd0d12bd33.1715193630.git.Morgan.J.Smith@outlook.com>
From: Morgan Smith <Morgan.J.Smith@outlook.com>
Date: Wed, 8 May 2024 14:40:00 -0400
Subject: [PATCH 2/2] guix: emacs-utils: Be more verbose in build phase.

* guix/build/emacs-utils.scm (emacs-compile-directory): Display the filename
of each file before compiling.

Change-Id: I275a086ed92f7cfb2907aea9b4feb59012cc8dd5
---
 guix/build/emacs-utils.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/guix/build/emacs-utils.scm b/guix/build/emacs-utils.scm
index aeb364133a..f35d9e690f 100644
--- a/guix/build/emacs-utils.scm
+++ b/guix/build/emacs-utils.scm
@@ -146,6 +146,7 @@ (define* (emacs-compile-directory dir)
                       'comp--write-bytecode-file)))))
        (mapc
         (lambda (file)
+          (message "Compiling `%s'")
           (let (byte-to-native-output-buffer-file
                 ;; First entry is the eln-cache of the homeless shelter,
                 ;; second entry is the install directory.
-- 
2.41.0

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

[Liliana Marie Prikler]

Am Mittwoch, dem 08.05.2024 um 14:48 -0400 schrieb Morgan Smith:
> Liliana Marie Prikler <liliana.prikler@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.
I've recently pushed an update to master that has a new integrity check
for emacs-next; using emacs-next intrinsics rather than going through
help-fns.

Thus marking this as done.

> 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.
Sorry for the late review on those, but you might want to revisit them
and send them as a new patch series.

> +          (message "Compiling `%s'")
That doesn't look right.

> [PATCH 1/2] build-system/emacs: Allow usage of
>  #:{allowed/disallowed}-references key
> 
> * guix/build-system/emacs.scm (emacs-build): Pass #:allowed-
> references and
> 
> Change-Id: Ib9a35a7b2115365b96675fb7ca3914b0ae7e67c7
> #:disallowed-references keys to builder.
The references are actually being ignored here.

Cheers