GNU bug report logs - #41732
Implement a wrapper so users can build the Emacs packages using a version of their choosing

Previous Next

To reply to this bug, email your comments to 41732 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: Fredrik Salomonsson <plattfot <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: issue with emacs-lua-mode and emacs-next
Date: Fri, 5 Jun 2020 20:14:17 -0700

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

Hi,

When I launch emacs (emacs-next) with the emacs-lua-mode package, I'm
getting this error
"Error (use-package): lua-mode/:catch: Unknown rx form ‘symbol’"

It works when I let emacs download it from melpa. I tried updating
emacs-lua-mode to 20200508, which is the same version as on melpa.

Still the same issue.

Could this be an issue that it's using emacs-minimal-26.3 to byte compile
the files? Where I'm using emacs-next aka emasc-27.0. Judging by this issue
[1] the rx package has gone through some changes in 27.0.

My emacs config is here: https://github.com/plattfot/dotemacs/tree/emacs27
I've attached the backtrace and the patch for the latest emacs-lua-mode.

Thanks

[1] https://github.com/immerrr/lua-mode/issues/153
-- 
s/Fred[re]+i[ck]+/Fredrik/g

[Message part 2 (text/html, inline)]

[emacs-lua-mode.backtrace (application/octet-stream, attachment)]

[0001-gnu-emacs-lua-mode-Update-to-20200508-0.35b6e4c.patch (text/x-patch, attachment)]

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

From: Fredrik Salomonsson via web <issues.guix.gnu.org <at> elephly.net>
To: 41732 <at> debbugs.gnu.org
Subject: issue with emacs-lua-mode and emacs-next
Date: Sat,  6 Jun 2020 05:17:36 +0200

Forgot to say which guix version I'm using:

guix (GNU Guix) ba6d3612550f5d978c4b5b1df122444f8fb29377

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

From: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
To: Fredrik Salomonsson <plattfot <at> gmail.com>
Cc: 41732 <at> debbugs.gnu.org
Subject: Re: bug#41732: issue with emacs-lua-mode and emacs-next
Date: Sat, 06 Jun 2020 10:10:05 +0200

Hello,

Fredrik Salomonsson <plattfot <at> gmail.com> writes:

> When I launch emacs (emacs-next) with the emacs-lua-mode package, I'm
> getting this error
> "Error (use-package): lua-mode/:catch: Unknown rx form ‘symbol’"
>
> It works when I let emacs download it from melpa. I tried updating
> emacs-lua-mode to 20200508, which is the same version as on melpa.
>
> Still the same issue.
>
> Could this be an issue that it's using emacs-minimal-26.3 to byte compile
> the files? Where I'm using emacs-next aka emasc-27.0. Judging by this issue
> [1] the rx package has gone through some changes in 27.0.

This seems to be reported upstream as 

             https://github.com/immerrr/lua-mode/issues/155

You may be right. Files byte-compiled with Emacs 26 may not be
compatible with Emacs 27.

I don't know what can be done on Guix's side, tho.

> I've attached the backtrace and the patch for the latest
> emacs-lua-mode.

Could you send another bug report for the package update?

Regards,

-- 
Nicolas Goaziou

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

From: zimoun <zimon.toutoune <at> gmail.com>
To: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Cc: 41732 <at> debbugs.gnu.org, Fredrik Salomonsson <plattfot <at> gmail.com>
Subject: Re: bug#41732: issue with emacs-lua-mode and emacs-next
Date: Sat, 6 Jun 2020 12:26:08 +0200

Dear Nicolas,

On Sat, 6 Jun 2020 at 10:11, Nicolas Goaziou <mail <at> nicolasgoaziou.fr> wrote:

> You may be right. Files byte-compiled with Emacs 26 may not be
> compatible with Emacs 27.
>
> I don't know what can be done on Guix's side, tho.

Somehow, one needs to change the Emacs version used by the Emacs
toolchain to bytecompile, right?
I do not know if it makes sense, but we could add something like
'package-with-emacs-next' similar to 'package-with-python2' or
'package-with-ocam4.07'.
WDYT?


All the best,
simon

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

From: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: 41732 <at> debbugs.gnu.org, Fredrik Salomonsson <plattfot <at> gmail.com>
Subject: Re: bug#41732: issue with emacs-lua-mode and emacs-next
Date: Sat, 06 Jun 2020 16:13:46 +0200

Hello,

zimoun <zimon.toutoune <at> gmail.com> writes:

> Somehow, one needs to change the Emacs version used by the Emacs
> toolchain to bytecompile, right?
> I do not know if it makes sense, but we could add something like
> 'package-with-emacs-next' similar to 'package-with-python2' or
> 'package-with-ocam4.07'.
> WDYT?

This sounds like serious overhead for a single package. Maybe we could
try to prevent byte-compilation for the package and see what happens?

Regards,

-- 
Nicolas Goaziou

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

From: zimoun <zimon.toutoune <at> gmail.com>
To: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Cc: 41732 <at> debbugs.gnu.org, Fredrik Salomonsson <plattfot <at> gmail.com>
Subject: Re: bug#41732: issue with emacs-lua-mode and emacs-next
Date: Sat, 6 Jun 2020 17:30:11 +0200

Dear Nicolas,

On Sat, 6 Jun 2020 at 16:13, Nicolas Goaziou <mail <at> nicolasgoaziou.fr> wrote:
> zimoun <zimon.toutoune <at> gmail.com> writes:

> > Somehow, one needs to change the Emacs version used by the Emacs
> > toolchain to bytecompile, right?
> > I do not know if it makes sense, but we could add something like
> > 'package-with-emacs-next' similar to 'package-with-python2' or
> > 'package-with-ocam4.07'.
> > WDYT?
>
> This sounds like serious overhead for a single package. Maybe we could
> try to prevent byte-compilation for the package and see what happens?

Maybe I miss the issue.  From my understanding, all the Emacs packages
are byte-compiled with the current Emacs.  Therefore, "guix install
emacs-next emacs-foo" and then "M-x foo" works by luck -- well because
the Emacs VM is stable. :-)
And I do not know how to rebuild all my Emacs packages using
'emacs-next' instead of the current Emacs.  Maybe I miss something.

Well, I am not suggesting to duplicate all the Emacs packages with
something like 'emacs-next-<package>' because it is too much.  I am
suggesting to provide 'package-with-emacs-next' and then for example
in my manifest file I would use this new procedure to generate
on-the-fly these next packages; as an expert Emacs mode.

I do not know if this proposal makes sense.  Probably not. :-)
(My regular Emacs is the current version and I very rarely use
emacs-next because I started Emacs with 23 therefore 24 was already a
so-nice improvement. :-))

All the best,
simon

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: 41732 <at> debbugs.gnu.org, Fredrik Salomonsson <plattfot <at> gmail.com>,
 Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Subject: Re: bug#41732: issue with emacs-lua-mode and emacs-next
Date: Sun, 07 Jun 2020 00:39:15 -0400

Hello,

zimoun <zimon.toutoune <at> gmail.com> writes:

> Dear Nicolas,
>
> On Sat, 6 Jun 2020 at 16:13, Nicolas Goaziou <mail <at> nicolasgoaziou.fr> wrote:
>> zimoun <zimon.toutoune <at> gmail.com> writes:
>
>> > Somehow, one needs to change the Emacs version used by the Emacs
>> > toolchain to bytecompile, right?
>> > I do not know if it makes sense, but we could add something like
>> > 'package-with-emacs-next' similar to 'package-with-python2' or
>> > 'package-with-ocam4.07'.
>> > WDYT?
>>
>> This sounds like serious overhead for a single package. Maybe we could
>> try to prevent byte-compilation for the package and see what happens?
>
> Maybe I miss the issue.  From my understanding, all the Emacs packages
> are byte-compiled with the current Emacs.  Therefore, "guix install
> emacs-next emacs-foo" and then "M-x foo" works by luck -- well because
> the Emacs VM is stable. :-)

That's a good description of the situation.  There's no warranty that
emacs-something works with emacs-next unless it was packaged to be
compiled specifically with emacs-next instead of the default emacs package
(currently 26.3).

> And I do not know how to rebuild all my Emacs packages using
> 'emacs-next' instead of the current Emacs.  Maybe I miss something.

Some people have been adding emacs-next-something packages (IIRC); I
think it's OK for the big, complicated packages that need effort to
port, but otherwise I wouldn't like seeing this happening for all
packages.

> Well, I am not suggesting to duplicate all the Emacs packages with
> something like 'emacs-next-<package>' because it is too much.  I am
> suggesting to provide 'package-with-emacs-next' and then for example
> in my manifest file I would use this new procedure to generate
> on-the-fly these next packages; as an expert Emacs mode.

That sounds like a good idea; provide a way for users to rewrite their
package at the level of their manifest file (which is already possible
IIUC).

> I do not know if this proposal makes sense.  Probably not. :-)
> (My regular Emacs is the current version and I very rarely use
> emacs-next because I started Emacs with 23 therefore 24 was already a
> so-nice improvement. :-))

It does make sense. For those who would like to see our base Emacs
package be updated to emacs-next, we need to iron out all the packages
currently failing to build with it.  It is easy to try, by modifying
slightly a local Guix checkout:

--8<---------------cut here---------------start------------->8---
1 file changed, 1 insertion(+), 1 deletion(-)
guix/build-system/emacs.scm | 2 +-

modified   guix/build-system/emacs.scm
@@ -52,7 +52,7 @@
   "Return the default Emacs package."
   ;; Lazily resolve the binding to avoid a circular dependency.
   (let ((emacs-mod (resolve-interface '(gnu packages emacs))))
-    (module-ref emacs-mod 'emacs-minimal)))
+    (module-ref emacs-mod 'emacs-next)))
 
 (define* (lower name
                 #:key source inputs native-inputs outputs system target

--8<---------------cut here---------------end--------------->8---

Maxim

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

From: zimoun <zimon.toutoune <at> gmail.com>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 41732 <at> debbugs.gnu.org, Fredrik Salomonsson <plattfot <at> gmail.com>,
 Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Subject: Re: bug#41732: issue with emacs-lua-mode and emacs-next
Date: Sun, 7 Jun 2020 11:31:41 +0200

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

Dear Maxim,

On Sun, 7 Jun 2020 at 06:39, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:

> Some people have been adding emacs-next-something packages (IIRC); I
> think it's OK for the big, complicated packages that need effort to
> port, but otherwise I wouldn't like seeing this happening for all
> packages.

I agree.  I am not suggesting to duplicate all the packages with
'emacs-next-something'.  There is already enough to do with the
current ones. :-)


> > Well, I am not suggesting to duplicate all the Emacs packages with
> > something like 'emacs-next-<package>' because it is too much.  I am
> > suggesting to provide 'package-with-emacs-next' and then for example
> > in my manifest file I would use this new procedure to generate
> > on-the-fly these next packages; as an expert Emacs mode.
>
> That sounds like a good idea; provide a way for users to rewrite their
> package at the level of their manifest file (which is already possible
> IIUC).

I propose to provide 'package-with-emacs-next' for the people in the
experimental mood. :-)  For example, the manifest looks like:

--8<---------------cut here---------------start------------->8---
(use-modules (guix build-system emacs)
             (gnu packages emacs)
             (gnu packages emacs-xyz))

(packages->manifest
 (cons emacs-next
       (map
        package-with-emacs-next
        (list
         emacs-lua-mode
         emacs-magit))))
--8<---------------cut here---------------end--------------->8---

Then the expert uses it with:

   guix package -m manifest.scm

Well, the attached patch does that.  And maybe, an entry to the
Cookbook could be worth.


> > I do not know if this proposal makes sense.  Probably not. :-)
> > (My regular Emacs is the current version and I very rarely use
> > emacs-next because I started Emacs with 23 therefore 24 was already a
> > so-nice improvement. :-))
>
> It does make sense. For those who would like to see our base Emacs
> package be updated to emacs-next, we need to iron out all the packages
> currently failing to build with it.  It is easy to try, by modifying
> slightly a local Guix checkout:
>
> --8<---------------cut here---------------start------------->8---
> 1 file changed, 1 insertion(+), 1 deletion(-)
> guix/build-system/emacs.scm | 2 +-
>
> modified   guix/build-system/emacs.scm
> @@ -52,7 +52,7 @@
>    "Return the default Emacs package."
>    ;; Lazily resolve the binding to avoid a circular dependency.
>    (let ((emacs-mod (resolve-interface '(gnu packages emacs))))
> -    (module-ref emacs-mod 'emacs-minimal)))
> +    (module-ref emacs-mod 'emacs-next)))
>
>  (define* (lower name
>                  #:key source inputs native-inputs outputs system target
>
> --8<---------------cut here---------------end--------------->8---

What I propose simplifies because it avoids to recompile all Guix and
to use ./pre-inst-env.
Well, I do not know.  It is an half-cooked proposal. :-)

And the added 'package-with-explicit-emacs' procedure allows to use
any Emacs as the VM, so for example, it could be cool to see what
happens with REmacs (which is not packaged but that's another story
:-)).
Or for example with Gccemacs.


All the best,
simon

ps:
Note that 'package-with-explicite-emacs' and
'package-with-explicit-python' should be refactored, another story.
:-)

[0001-DRAFT-build-system-emacs-Add-new-package-with-emacs-.patch (text/x-patch, attachment)]

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: 41732 <at> debbugs.gnu.org, Fredrik Salomonsson <plattfot <at> gmail.com>,
 Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Subject: Re: bug#41732: issue with emacs-lua-mode and emacs-next
Date: Wed, 17 Jun 2020 00:34:23 -0400

Hello Simon!

Sorry for my delayed answer.

zimoun <zimon.toutoune <at> gmail.com> writes:

> Dear Maxim,
>
> On Sun, 7 Jun 2020 at 06:39, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
>
>> Some people have been adding emacs-next-something packages (IIRC); I
>> think it's OK for the big, complicated packages that need effort to
>> port, but otherwise I wouldn't like seeing this happening for all
>> packages.
>
> I agree.  I am not suggesting to duplicate all the packages with
> 'emacs-next-something'.  There is already enough to do with the
> current ones. :-)
>
>
>> > Well, I am not suggesting to duplicate all the Emacs packages with
>> > something like 'emacs-next-<package>' because it is too much.  I am
>> > suggesting to provide 'package-with-emacs-next' and then for example
>> > in my manifest file I would use this new procedure to generate
>> > on-the-fly these next packages; as an expert Emacs mode.
>>
>> That sounds like a good idea; provide a way for users to rewrite their
>> package at the level of their manifest file (which is already possible
>> IIUC).
>
> I propose to provide 'package-with-emacs-next' for the people in the
> experimental mood. :-)  For example, the manifest looks like:
>
> (use-modules (guix build-system emacs)
>              (gnu packages emacs)
>              (gnu packages emacs-xyz))
>
> (packages->manifest
>  (cons emacs-next
>        (map
>         package-with-emacs-next
>         (list
>          emacs-lua-mode
>          emacs-magit))))
>
> Then the expert uses it with:
>
>    guix package -m manifest.scm
>
> Well, the attached patch does that.  And maybe, an entry to the
> Cookbook could be worth.

That's really nice!  Thank you for providing it.  I've tried it in my
manifest, by stitching a couple manifests objects together
`concatenate-manifests' like so:

--8<---------------cut here---------------start------------->8---
(concatenate-manifests
 (list
 ;;; Emacs packages.
  (packages->manifest
   (cons emacs-next
         (map package-with-emacs-next
              (map specification->package
                   '("emacs-auctex"
                     "emacs-bash-completion"
                     [...]
                     "emacs-yasnippet"
                     "emacs-yasnippet-snippets")))))

  ;; Other software.
  (specifications->manifest
   '("adb"
     [...]   
     "arc-icon-theme"
     "arc-theme"
     ...))))
--8<---------------cut here---------------end--------------->8---

And after a couple fixes on master, I was able to build my profile with
my Emacs packages collection built against Emacs 27!  I'm now having
some issues due to the apparent renaming of the generated autoload
files.  I haven't had the time to look for a fix yet.  It breaks at
least Helm (and probably others), as it cannot find its own autoload
file.

next-helm-autoloads.el ->
/gnu/store/fnwalhxi94fhr8h2dfg602zd9plarwx0-emacs-next-helm-3.6.2/share/emacs/site-lisp/next-helm-autoloads.el

(instead of helm-autoloads.el)

> Note that 'package-with-explicite-emacs' and
> 'package-with-explicit-python' should be refactored, another story.
> :-)

I wholly agree!  It seems these have much in common.  Perhaps (guix
packages) could be a new home for the factored out bits.

To be continued!

Maxim

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

From: zimoun <zimon.toutoune <at> gmail.com>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 41732 <at> debbugs.gnu.org, Fredrik Salomonsson <plattfot <at> gmail.com>,
 Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Subject: Re: bug#41732: New ’package-with-emacs-next’ procedure
Date: Wed, 16 Sep 2020 16:51:21 +0200

Dear Maxim,

On Wed, 17 Jun 2020 at 00:34, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
> zimoun <zimon.toutoune <at> gmail.com> writes:

> Sorry for my delayed answer.

Sorry, I have missed your answer.


>> I propose to provide 'package-with-emacs-next' for the people in the
>> experimental mood. :-)  For example, the manifest looks like:
>>
>> (use-modules (guix build-system emacs)
>>              (gnu packages emacs)
>>              (gnu packages emacs-xyz))
>>
>> (packages->manifest
>>  (cons emacs-next
>>        (map
>>         package-with-emacs-next
>>         (list
>>          emacs-lua-mode
>>          emacs-magit))))
>>
>> Then the expert uses it with:
>>
>>    guix package -m manifest.scm
>>
>> Well, the attached patch does that.  And maybe, an entry to the
>> Cookbook could be worth.
>
> That's really nice!  Thank you for providing it.  I've tried it in my
> manifest, by stitching a couple manifests objects together
> `concatenate-manifests' like so:
>
> (concatenate-manifests
>  (list
>  ;;; Emacs packages.
>   (packages->manifest
>    (cons emacs-next
>          (map package-with-emacs-next
>               (map specification->package
>                    '("emacs-auctex"
>                      "emacs-bash-completion"
>                      [...]
>                      "emacs-yasnippet"
>                      "emacs-yasnippet-snippets")))))
>
>   ;; Other software.
>   (specifications->manifest
>    '("adb"
>      [...]
>      "arc-icon-theme"
>      "arc-theme"
>      ...))))
>
> And after a couple fixes on master, I was able to build my profile with
> my Emacs packages collection built against Emacs 27!  I'm now having
> some issues due to the apparent renaming of the generated autoload
> files.  I haven't had the time to look for a fix yet.  It breaks at
> least Helm (and probably others), as it cannot find its own autoload
> file.
>
> next-helm-autoloads.el ->
> /gnu/store/fnwalhxi94fhr8h2dfg602zd9plarwx0-emacs-next-helm-3.6.2/share/emacs/site-lisp/next-helm-autoloads.el
>
> (instead of helm-autoloads.el)

What do you think to add this ’package-with-emacs-next’?
It should help when upgrading Emacs: detect which packages break, report
upstream or fix, etc.  Helm is a good example.

Couple of days before emacs-next becomes the new emacs, an announcement
of the coming soon switch on guix-devel and a call for testing and
report issues.

If it appears to you a good idea, I can rebase the patch and resubmit
it, and add an example to the Cooking book.


>> Note that 'package-with-explicite-emacs' and
>> 'package-with-explicit-python' should be refactored, another story.
>> :-)
>
> I wholly agree!  It seems these have much in common.  Perhaps (guix
> packages) could be a new home for the factored out bits.

The story is long. :-)

There is ’package-with-explicit-python’ and also
’package-with-explicit-ocaml’, I would like to have
’package-with-explicit-c-compiler’ too to rebuild C packages with any
version of GCC or even Clang.  One way to achieve is “package parameter”
but the consensus on the topic has not been reached.  Therefore
’package-with-explicit-<name-it>’ seems a working short term workaround
waiting something more “elegant“.  But yeah, maybe the 3
’package-with-explicit-{python,ocaml,emacs}’ could be refactored; I do
not know.


All the best,
simon

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

From: zimoun <zimon.toutoune <at> gmail.com>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 41732 <at> debbugs.gnu.org, Fredrik Salomonsson <plattfot <at> gmail.com>,
 Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Subject: Re: bug#41732: New ’package-with-emacs-next’ procedure
Date: Sat, 26 Sep 2020 18:12:47 +0200

Dear,

On Wed, 16 Sep 2020 at 16:51, zimoun <zimon.toutoune <at> gmail.com> wrote:

>>> I propose to provide 'package-with-emacs-next' for the people in the
>>> experimental mood. :-)  For example, the manifest looks like:
>>>
>>> (use-modules (guix build-system emacs)
>>>              (gnu packages emacs)
>>>              (gnu packages emacs-xyz))
>>>
>>> (packages->manifest
>>>  (cons emacs-next
>>>        (map
>>>         package-with-emacs-next
>>>         (list
>>>          emacs-lua-mode
>>>          emacs-magit))))
>>>
>>> Then the expert uses it with:
>>>
>>>    guix package -m manifest.scm
>>>
>>> Well, the attached patch does that.  And maybe, an entry to the
>>> Cookbook could be worth.

I withdraw the patch proposal since the patch set #43578 [1] fulfills
the request.  Now, for recompiling all the Emacs packages of one
manifest.scm file with the emacs-next package (changing the Emacs VM),
it is as easy as:

--8<---------------cut here---------------start------------->8---
guix build -m manifest.scm --with-input=emacs-minimal=emacs-next
--8<---------------cut here---------------end--------------->8---

Before closing, what do you think adding something in the manual or the
cookbook will be worth?  It could be useful when switching the Emacs
version –– for example the last 26 to 27.

[1] <http://issues.guix.gnu.org/issue/43578>

All the best,
simon

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

From: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: 41732 <at> debbugs.gnu.org, Fredrik Salomonsson <plattfot <at> gmail.com>,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#41732: New ’package-with-emacs-next’ procedure
Date: Sat, 26 Sep 2020 18:53:34 +0200

Hello,

zimoun <zimon.toutoune <at> gmail.com> writes:

> I withdraw the patch proposal since the patch set #43578 [1] fulfills
> the request.  Now, for recompiling all the Emacs packages of one
> manifest.scm file with the emacs-next package (changing the Emacs VM),
> it is as easy as:
>
> --8<---------------cut here---------------start------------->8---
> guix build -m manifest.scm --with-input=emacs-minimal=emacs-next
> --8<---------------cut here---------------end--------------->8---

Some Emacs packages rely on emacs package, not on emacs-minimal. IIUC,
the command above could give surprising results in this case. Maybe the
documentation/cookbook could warn about this caveat.

Regards,
-- 
Nicolas Goaziou

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Cc: 41732 <at> debbugs.gnu.org, Fredrik Salomonsson <plattfot <at> gmail.com>,
 zimoun <zimon.toutoune <at> gmail.com>
Subject: Re: bug#41732: New ’package-with-emacs-next’ procedure
Date: Sat, 26 Sep 2020 23:45:09 -0400

Hi Nicolas,

Nicolas Goaziou <mail <at> nicolasgoaziou.fr> writes:

> Hello,
>
> zimoun <zimon.toutoune <at> gmail.com> writes:
>
>> I withdraw the patch proposal since the patch set #43578 [1] fulfills
>> the request.  Now, for recompiling all the Emacs packages of one
>> manifest.scm file with the emacs-next package (changing the Emacs VM),
>> it is as easy as:
>>
>> --8<---------------cut here---------------start------------->8---
>> guix build -m manifest.scm --with-input=emacs-minimal=emacs-next
>> --8<---------------cut here---------------end--------------->8---
>
> Some Emacs packages rely on emacs package, not on emacs-minimal. IIUC,
> the command above could give surprising results in this case. Maybe the
> documentation/cookbook could warn about this caveat.

Perhaps then,

--8<---------------cut here---------------start------------->8---
guix build -m manifest.scm --with-input=emacs-minimal=emacs-next \
     --with-input=emacs=emacs-next
--8<---------------cut here---------------end--------------->8---

I haven't tried myself.

Maxim

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

From: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 41732 <at> debbugs.gnu.org, Fredrik Salomonsson <plattfot <at> gmail.com>
Subject: Re: bug#41732: New ’package-with-emacs-next’ procedure
Date: Sun, 27 Sep 2020 11:00:30 +0200

Hello,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Perhaps then,
>
> --8<---------------cut here---------------start------------->8---
> guix build -m manifest.scm --with-input=emacs-minimal=emacs-next \
>      --with-input=emacs=emacs-next
> --8<---------------cut here---------------end--------------->8---

Possibly. And then Magit uses emacs-no-x as an input, so we may need to
also add --with-input=emacs-no-x=emacs-next to the command.

I'm just pointing out that the process is not as straightforward as it
might seem. So, it doesn't sound right to simply suggest

  guix build -m manifest.scm --with-input=emacs-minimal=emacs-next

in the manual/cookbook without caution.

Or maybe `package-with-emacs-next' could be more high-level, and handle
all of these cases. I don't know.

Regards,
-- 
Nicolas Goaziou

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Cc: 41732 <at> debbugs.gnu.org, Fredrik Salomonsson <plattfot <at> gmail.com>
Subject: Re: bug#41732: New ’package-with-emacs-next’ procedure
Date: Sun, 27 Sep 2020 23:03:40 -0400

Hello,

Nicolas Goaziou <mail <at> nicolasgoaziou.fr> writes:

> Possibly. And then Magit uses emacs-no-x as an input, so we may need to
> also add --with-input=emacs-no-x=emacs-next to the command.
>
> I'm just pointing out that the process is not as straightforward as it
> might seem. So, it doesn't sound right to simply suggest
>
>   guix build -m manifest.scm --with-input=emacs-minimal=emacs-next
>
> in the manual/cookbook without caution.
>
> Or maybe `package-with-emacs-next' could be more high-level, and handle
> all of these cases. I don't know.

Yeah, that would probably me more convenient/robust to use, if it was
covering for all the weird cases one might forget.  I'd still be in
favor of having such a helper procedure.

Maxim

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

From: zimoun <zimon.toutoune <at> gmail.com>
To: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Cc: 41732 <at> debbugs.gnu.org, Fredrik Salomonsson <plattfot <at> gmail.com>,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#41732: New ’package-with-emacs-next’ procedure
Date: Mon, 28 Sep 2020 10:29:27 +0200

Hi,

Thank you for your insights.

On Sun, 27 Sep 2020 at 15:12, Nicolas Goaziou <mail <at> nicolasgoaziou.fr> wrote:

> > --8<---------------cut here---------------start------------->8---
> > guix build -m manifest.scm --with-input=emacs-minimal=emacs-next \
> >      --with-input=emacs=emacs-next
> > --8<---------------cut here---------------end--------------->8---
>
> Possibly. And then Magit uses emacs-no-x as an input, so we may need to
> also add --with-input=emacs-no-x=emacs-next to the command.

[...]

> Or maybe `package-with-emacs-next' could be more high-level, and handle
> all of these cases. I don't know.

I am not familiar with the Emacs build system.  Do the packages need
different flavors of the Emacs VM to be byte-compiled?
For example, the package emacs-magit drags emacs-no-x because of
emacs-libgit, why is emacs-minimal not enough here?

Well, the emacs-build-system depends (implicitly) on emacs-minimal,
only.  And the initial patch `package-with-emacs-next' was changing
this, only.  However, the package emacs-libgit is cmake-build-system
and the package emacs-no-x is an explicit dependency; which is another
story. :-)

Therefore, the `package-with-emacs-next' could replace the Emacs used
by the build system (emacs-minimal -> emacs-next-minimal) and also
traverse all the graph of dependencies and replace all the Emacs
variants (emacs-{minimal,xwidgets,no-x,no-x-toolkit,wide-int}) in
gnu/packages/emacs.scm by the package emacs-next.  I am not sure it
will work.  Maybe the Emacs variants should also be rebuilt inheriting
from emacs-next instead of emacs.  WDYT?

Does it make sense?


All the best,
simon

Previous Next

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