| Message ID | b4cbb0be620be359281742d5c6ab10aeac8c5782.camel@student.tugraz.at |
|---|---|
| State | Under Review |
| Headers | show |
| Series | [bug#39804] gnu: add emacs-exwm-next package (i.e. exwm for emacs-next) | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | fail | View Laminar job |
Leo Prikler <leo.prikler@student.tugraz.at> writes: > Am Freitag, den 28.02.2020, 09:32 +0100 schrieb Pierre Neidhardt: >> The `#:emacs` field tells the build system which Emacs package to use >> to >> build this package. There may be something that not compatible >> between >> our current build system and emacs-next. >> >> I've CC'ed Maxim and Leo, they might know more than me. > This issue should be addressed by #39375, which is currently waiting to > be pushed to master or staging. If we don't hear back from https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39823 in a day or two, I'd be OK with pushing #39375 to master. > I took the liberty to rewrite this > patch with that one in mind – the build succeeds now, but I'm not sure > how to run it. Perhaps I'm missing a few bits. > > Regards, > Leo > > From 73eb9dac1bd13a8107aaedddecbe9bf7821a4841 Mon Sep 17 00:00:00 2001 > From: Leo Prikler <leo.prikler@student.tugraz.at> > Date: Fri, 28 Feb 2020 10:46:23 +0100 > Subject: [PATCH 1/2] gnu: Add emacs-xelb-next. > > * gnu/packages/emacs-xyz.scm (emacs-xelb-next): New variable. > --- > gnu/packages/emacs-xyz.scm | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm > index 76b9746f69..fa007f158b 100644 > --- a/gnu/packages/emacs-xyz.scm > +++ b/gnu/packages/emacs-xyz.scm > @@ -9661,6 +9661,14 @@ features an object-oriented API and permits a certain degree of concurrency. > It should enable you to implement low-level X11 applications.") > (license license:gpl3+))) > > +(define-public emacs-xelb-next > + (package > + (inherit emacs-xelb) > + (name "emacs-xelb-next") > + (arguments > + `(,@(package-arguments emacs-xelb) > + #:emacs ,emacs-next)))) > + > (define-public emacs-exwm > (package > (name "emacs-exwm") > -- > 2.25.1 > > > From 19056fa969d830d5ee1065988f6a5b4f76fcbae9 Mon Sep 17 00:00:00 2001 > From: dakling <dario.klingenberg@web.de> > Date: Wed, 26 Feb 2020 22:07:44 +0100 > Subject: [PATCH 2/2] gnu: Add emacs-exwm-next. > > * gnu/packages/emacs-xyz.scm (emacs-exwm-next): New variable. > --- > gnu/packages/emacs-xyz.scm | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm > index fa007f158b..9567324da8 100644 > --- a/gnu/packages/emacs-xyz.scm > +++ b/gnu/packages/emacs-xyz.scm > @@ -9739,6 +9739,24 @@ It should enable you to implement low-level X11 applications.") > built on top of XELB.") > (license license:gpl3+))) > > +(define-public emacs-exwm-next > + (package > + (inherit emacs-exwm) > + (name "emacs-exwm-next") > + (propagated-inputs > + `(("emacs-xelb" ,emacs-xelb-next))) > + (inputs > + `(("xhost" ,xhost) > + ("emacs-next" ,emacs-next) > + ("dbus" ,dbus))) > + (arguments > + `(,@(package-arguments emacs-exwm) > + #:emacs ,emacs-next)) > + (home-page "https://github.com/ch11ng/exwm") > + (description "EXWM is a full-featured tiling X window manager for Emacs > +built on top of XELB.") > + (license license:gpl3+))) No need to repeat the home-page, description and license field. Other than that, LGTM. Maxim
Hello Leo, Maxim Cournoyer <maxim.cournoyer@gmail.com> writes: > Leo Prikler <leo.prikler@student.tugraz.at> writes: > >> Am Freitag, den 28.02.2020, 09:32 +0100 schrieb Pierre Neidhardt: >>> The `#:emacs` field tells the build system which Emacs package to use >>> to >>> build this package. There may be something that not compatible >>> between >>> our current build system and emacs-next. >>> >>> I've CC'ed Maxim and Leo, they might know more than me. >> This issue should be addressed by #39375, which is currently waiting to >> be pushed to master or staging. > > If we don't hear back from > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39823 in a day or two, I'd > be OK with pushing #39375 to master. There have been no activity or reply on #39823 yet, so feel free to push the workaround discussed earlier (on the master branch is fine). Maxim
Am Dienstag, den 10.03.2020, 23:54 -0400 schrieb Maxim Cournoyer: > Hello Leo, > > Maxim Cournoyer <maxim.cournoyer@gmail.com> writes: > > > Leo Prikler <leo.prikler@student.tugraz.at> writes: > > > > > Am Freitag, den 28.02.2020, 09:32 +0100 schrieb Pierre Neidhardt: > > > > The `#:emacs` field tells the build system which Emacs package > > > > to use > > > > to > > > > build this package. There may be something that not compatible > > > > between > > > > our current build system and emacs-next. > > > > > > > > I've CC'ed Maxim and Leo, they might know more than me. > > > This issue should be addressed by #39375, which is currently > > > waiting to > > > be pushed to master or staging. > > > > If we don't hear back from > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39823 in a day or > > two, I'd > > be OK with pushing #39375 to master. > > There have been no activity or reply on #39823 yet, so feel free to > push > the workaround discussed earlier (on the master branch is fine). > > Maxim Following the discussion in 39823, we now have two options. 1. loading the library in advance as I do. 2. wrapping our code in `(eval ...)'. The latter has the advantage of not needing an additional function, but both require a build system change. WDYT?
Hi Leo! Leo Prikler <leo.prikler@student.tugraz.at> writes: > Am Dienstag, den 10.03.2020, 23:54 -0400 schrieb Maxim Cournoyer: >> Hello Leo, >> >> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes: >> >> > Leo Prikler <leo.prikler@student.tugraz.at> writes: >> > >> > > Am Freitag, den 28.02.2020, 09:32 +0100 schrieb Pierre Neidhardt: >> > > > The `#:emacs` field tells the build system which Emacs package >> > > > to use >> > > > to >> > > > build this package. There may be something that not compatible >> > > > between >> > > > our current build system and emacs-next. >> > > > >> > > > I've CC'ed Maxim and Leo, they might know more than me. >> > > This issue should be addressed by #39375, which is currently >> > > waiting to >> > > be pushed to master or staging. >> > >> > If we don't hear back from >> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39823 in a day or >> > two, I'd >> > be OK with pushing #39375 to master. >> >> There have been no activity or reply on #39823 yet, so feel free to >> push >> the workaround discussed earlier (on the master branch is fine). >> >> Maxim > Following the discussion in 39823, we now have two options. > 1. loading the library in advance as I do. > 2. wrapping our code in `(eval ...)'. > The latter has the advantage of not needing an additional function, but > both require a build system change. > > WDYT? #1 would be best, as it is a general fix, and we can even add a parameter to allow choosing between dynamic vs lexcal evaluation (see the doc for `eval', it takes such a parameter and defaults to dynamical). Maxim
Hello! Leo Prikler <leo.prikler@student.tugraz.at> writes: > Am Dienstag, den 10.03.2020, 23:54 -0400 schrieb Maxim Cournoyer: >> Hello Leo, >> >> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes: >> >> > Leo Prikler <leo.prikler@student.tugraz.at> writes: >> > >> > > Am Freitag, den 28.02.2020, 09:32 +0100 schrieb Pierre Neidhardt: >> > > > The `#:emacs` field tells the build system which Emacs package >> > > > to use >> > > > to >> > > > build this package. There may be something that not compatible >> > > > between >> > > > our current build system and emacs-next. >> > > > >> > > > I've CC'ed Maxim and Leo, they might know more than me. >> > > This issue should be addressed by #39375, which is currently >> > > waiting to >> > > be pushed to master or staging. >> > >> > If we don't hear back from >> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39823 in a day or >> > two, I'd >> > be OK with pushing #39375 to master. >> >> There have been no activity or reply on #39823 yet, so feel free to >> push >> the workaround discussed earlier (on the master branch is fine). >> >> Maxim > Following the discussion in 39823, we now have two options. > 1. loading the library in advance as I do. > 2. wrapping our code in `(eval ...)'. > The latter has the advantage of not needing an additional function, but > both require a build system change. > > WDYT? I went with option 2, and tested that emacs-exwm-next could be built. The relevant commit is afc6b1c0b635e3268795c0f766be408c5e9858e7 on master. Maxim
Thanks!
From 19056fa969d830d5ee1065988f6a5b4f76fcbae9 Mon Sep 17 00:00:00 2001 From: dakling <dario.klingenberg@web.de> Date: Wed, 26 Feb 2020 22:07:44 +0100 Subject: [PATCH 2/2] gnu: Add emacs-exwm-next. * gnu/packages/emacs-xyz.scm (emacs-exwm-next): New variable. --- gnu/packages/emacs-xyz.scm | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm index fa007f158b..9567324da8 100644 --- a/gnu/packages/emacs-xyz.scm +++ b/gnu/packages/emacs-xyz.scm @@ -9739,6 +9739,24 @@ It should enable you to implement low-level X11 applications.") built on top of XELB.") (license license:gpl3+))) +(define-public emacs-exwm-next + (package + (inherit emacs-exwm) + (name "emacs-exwm-next") + (propagated-inputs + `(("emacs-xelb" ,emacs-xelb-next))) + (inputs + `(("xhost" ,xhost) + ("emacs-next" ,emacs-next) + ("dbus" ,dbus))) + (arguments + `(,@(package-arguments emacs-exwm) + #:emacs ,emacs-next)) + (home-page "https://github.com/ch11ng/exwm") + (description "EXWM is a full-featured tiling X window manager for Emacs +built on top of XELB.") + (license license:gpl3+))) + (define-public emacs-switch-window (package (name "emacs-switch-window") -- 2.25.1