| Message ID | e43d20b120dd66887e587ac9d157dd7d7df4e411.camel@zrythm.org |
|---|---|
| State | Accepted |
| Headers | show |
| Series | None | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | fail | View Laminar job |
On Mon, Apr 06, 2020 at 10:28:35PM +0100, Alexandros Theodotou wrote: > * gnu/packages/music.scm (shiru-lv2): New variable. Thanks! > +(define-public shiru-lv2 > + (let ((commit "08853f99140012234649e67e5647906fda74f6cc") > + (revision "1")) > + (package/inherit dragonfly-reverb If inheriting, we should use the regular inherit procedure, like this: (package (inherit dragonfly-reverb) ...) package/inherit is for special cases related to grafting and replacement packages. [0] Anyways, it looks like the inherited fields are build-system, native-inputs, and arguments. Is the idea that there is some build complication common to the LV2 plugins that we don't want to copy around? Maybe we could make a build system for them. Does it work to inherit the custom install phase from dragonfly-reverb? It seems like the install-file procedures would not apply here. What do you think? Sorry if I've missed something. [0] https://guix.gnu.org/manual/en/html_node/Security-Updates.html
Hi Leo, > package/inherit is for special cases related to grafting and > replacement > packages. [0] Thank you, I initially thought it was just a shorthand. > Is the idea that there is some build > complication common to the LV2 plugins that we don't want to copy > around? Maybe we could make a build system for them. > > Does it work to inherit the custom install phase from dragonfly- > reverb? > It seems like the install-file procedures would not apply here. Plugins that use the DISTRHO plugin framework ( https://github.com/DISTRHO/DPF) use the same build/install procedure, unless the author makes changes to the Makefiles (like in the case of the zam-plugins package). Dragonfly reverb and shiru plugins both use DPF as-is, so the build/install procedures are exactly the same - built plugins will be produced inside "bin" as binaries, lv2 plugins and vst plugins. There are more DPF-based plugins I plan to package that leave the the DPF Makefiles as-is so I thought inheriting from dragonfly-reverb would be a nice way to do it. Thanks, Alex On Tue, 2020-04-07 at 14:25 -0400, Leo Famulari wrote: > On Mon, Apr 06, 2020 at 10:28:35PM +0100, Alexandros Theodotou wrote: > > * gnu/packages/music.scm (shiru-lv2): New variable. > > Thanks! > > > +(define-public shiru-lv2 > > + (let ((commit "08853f99140012234649e67e5647906fda74f6cc") > > + (revision "1")) > > + (package/inherit dragonfly-reverb > > If inheriting, we should use the regular inherit procedure, like > this: > > (package > (inherit dragonfly-reverb) > ...) > > package/inherit is for special cases related to grafting and > replacement > packages. [0] > > Anyways, it looks like the inherited fields are build-system, > native-inputs, and arguments. Is the idea that there is some build > complication common to the LV2 plugins that we don't want to copy > around? Maybe we could make a build system for them. > > Does it work to inherit the custom install phase from dragonfly- > reverb? > It seems like the install-file procedures would not apply here. > > What do you think? Sorry if I've missed something. > > [0] > https://guix.gnu.org/manual/en/html_node/Security-Updates.html
On Tue, Apr 07, 2020 at 08:09:31PM +0100, Alexandros Theodotou wrote: > Plugins that use the DISTRHO plugin framework ( > https://github.com/DISTRHO/DPF) use the same build/install procedure, > unless the author makes changes to the Makefiles (like in the case of > the zam-plugins package). Dragonfly reverb and shiru plugins both use > DPF as-is, so the build/install procedures are exactly the same - built > plugins will be produced inside "bin" as binaries, lv2 plugins and vst > plugins. > > There are more DPF-based plugins I plan to package that leave the the > DPF Makefiles as-is so I thought inheriting from dragonfly-reverb would > be a nice way to do it. Okay, feel free to write the packages in whatever way works for you. > > Does it work to inherit the custom install phase from dragonfly- > > reverb? > > It seems like the install-file procedures would not apply here. However, I tried building it from the patch and the install phase does fail there.
> > > Does it work to inherit the custom install phase from dragonfly- > > > reverb? > > > It seems like the install-file procedures would not apply here. > > However, I tried building it from the patch and the install phase > does > fail there. Did you build it after applying the previous 2 patches? https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40466 and https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40467 This is supposed to be merged after those changes. The first patch (40466) changes the install procedure in dragonfly-reverb, which is inherited here.
On Tue, Apr 07, 2020 at 09:04:40PM +0100, Alexandros Theodotou wrote: > > > > Does it work to inherit the custom install phase from dragonfly- > > > > reverb? > > > > It seems like the install-file procedures would not apply here. > > > > However, I tried building it from the patch and the install phase > > does > > fail there. > > Did you build it after applying the previous 2 patches? > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40466 and > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40467 > > This is supposed to be merged after those changes. The first patch > (40466) changes the install procedure in dragonfly-reverb, which is > inherited here. Ah, no, I didn't realize they were related. It's annoyingly tricky, but patches that depend on each should be in the same bug ticket. This can be accomplished by first sending an intro message to get a bug number, then sending the patch series to e.g. <NNN@debbugs.gnu.org>. I'll merge them now.
> It's annoyingly tricky, but patches that depend on each should be in > the > same bug ticket. This can be accomplished by first sending an intro > message to get a bug number, then sending the patch series to e.g. > <NNN@debbugs.gnu.org>. > > I'll merge them now. Ah okay, thank you for letting me know. I'll send such patches in the same ticket from now on. Thanks, Alex
On Tue, Apr 07, 2020 at 09:04:40PM +0100, Alexandros Theodotou wrote: > This is supposed to be merged after those changes. The first patch > (40466) changes the install procedure in dragonfly-reverb, which is > inherited here. In general, I think that using syntactic inheritance to factorize build phases is not the right way to go here. It can cause a big headache later when the time comes to adjust things, and it removes the advantages of Guix tools such as `guix graph` and `guix refresh`. I think the better options are to create a new lv2-build-system that inherits from gnu-build-system and replaces the install phase, or to just copy and paste the code around. It depends on how many of these packages we plan to add. Let me know if you need help with any of that! The font-build-system is a concise example of making a new build system based on the gnu-build-system.
I'd say the eventual amount of packages that would use such a build system are between 5-10. Should I go ahead and make a dpf-build-system or do you think we should just copy the code around since it's not that many packages? By the way, we used inheritance in the case of other packages such as gx-* and vl1-emulator/regrader/fogpad, although those are from the same upstream so maybe it's reasonable there. On Wed, 2020-04-08 at 11:41 -0400, Leo Famulari wrote: > On Tue, Apr 07, 2020 at 09:04:40PM +0100, Alexandros Theodotou wrote: > > This is supposed to be merged after those changes. The first patch > > (40466) changes the install procedure in dragonfly-reverb, which is > > inherited here. > > In general, I think that using syntactic inheritance to factorize > build > phases is not the right way to go here. It can cause a big headache > later when the time comes to adjust things, and it removes the > advantages of Guix tools such as `guix graph` and `guix refresh`. > > I think the better options are to create a new lv2-build-system that > inherits from gnu-build-system and replaces the install phase, or to > just copy and paste the code around. It depends on how many of these > packages we plan to add. > > Let me know if you need help with any of that! The font-build-system > is > a concise example of making a new build system based on the > gnu-build-system.
From 83ba8ba27d6b6f75eb8cbcbcdf19369903602249 Mon Sep 17 00:00:00 2001 From: Alexandros Theodotou <alex@zrythm.org> Date: Mon, 6 Apr 2020 22:26:45 +0100 Subject: [PATCH 3/3] gnu: Add shiru-lv2. * gnu/packages/music.scm (shiru-lv2): New variable. --- gnu/packages/music.scm | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm index e2a3d84572..78a799a53a 100644 --- a/gnu/packages/music.scm +++ b/gnu/packages/music.scm @@ -5387,3 +5387,35 @@ filtered, pitch shifted and ultimately disintegrated. This is an unofficial port of the Regrader plugin created by Igorski. It is available as an LV2 plugin and a standalone JACK application.") (license license:expat))) + +(define-public shiru-lv2 + (let ((commit "08853f99140012234649e67e5647906fda74f6cc") + (revision "1")) + (package/inherit dragonfly-reverb + (name "shiru-lv2") + (version (git-version "0.0" revision commit)) + (source + (origin + (method git-fetch) + (uri (git-reference + (url "https://github.com/linuxmao-org/shiru-plugins.git") + (commit commit) + ;; Bundles a specific commit of the DISTRHO plugin framework. + (recursive? #t))) + (file-name (git-file-name name version)) + (sha256 + (base32 + "00rf6im3rhg98h60sgl1r2s37za5vr5h14pybwi07h8zbc8mi6fm")))) + (inputs + `(("cairo", cairo) + ("glu", glu) + ("jack", jack-1) + ("lv2", lv2) + ("mesa", mesa) + ("pango", pango))) + (synopsis "Audio plugin collection") + (description "Shiru plugins is a collection of audio plugins created + by Shiru, ported to LV2 by the Linux MAO project using the DISTRHO plugin + framework.") + (home-page "http://shiru.untergrund.net/software.shtml") + (license license:wtfpl2)))) -- 2.26.0