Monday, March 29, 2021

Re: [NEW] audio/zynaddsubfx

On 2021/03/29 16:54, Dimitri Karamazov wrote:
> Ping

I need an OK before I can commit it.

> On Mon, Mar 22, 2021 at 04:00:36PM +0000, Dimitri Karamazov wrote:
> > On Mon, Mar 22, 2021 at 11:34:27AM +0000, Stuart Henderson wrote:
> > > On 2021/03/21 16:19, Dimitri Karamazov wrote:
> > > > On Sun, Mar 21, 2021 at 11:46:48AM +0000, Stuart Henderson wrote:
> > > > > On 2021/03/21 11:30, Solene Rapenne wrote:
> > > > > > On Thu, 18 Mar 2021 17:36:55 +0000
> > > > > > Dimitri Karamazov <deserter666@danwin1210.me>:
> > > > > >
> > > > > > > Ping
> > > > > > >
> > > > > >
> > > > > > hello, in zyn-fusion I'd add audio/zynaddsubfx as a RUN_DEP because
> > > > > > it seems mandatory to use zyn-fusion.
> > > > >
> > > > > The problem is that the dependency is sort-of circular. zynaddsubfx
> > > > > requires zyn-fusion or another UI to be useful, and zyn-fusion requires
> > > > > zynaddsubfx to be useful.
> > > > >
> > > > > AUR deals with this by including zynaddsubfx in zyn-fusion (and having
> > > > > them conflict) but that doesn't seem ideal either.
> > > > >
> > > > > Thinking about what happens if other UIs are added though, having
> > > > > zynaddsubfx depend on zyn-fusion doesn't work because the user might want
> > > > > a different UI.
> > > > >
> > > > > Maybe the answer is to have zyn-fusion depend on zynaddsubfx and move
> > > > > the README to zynaddsubfx ("this package provides the backenx synthesizer,
> > > > > you must also install a user interface") - or even just including it in
> > > > > DESCR.
> > > > >
> > > > > The other way is to use meta-packages but that's messier ..
> > > >
> > > > There is a configure option -DGuiModule in zynaddsubfx which can be set to
> > > > zest(zyn-fusion), ntk or fltk. So making zyn-fusion depend on zynaddsubfx
> > > > will not work(restrict our options to zest). Also zyn-fusion has no real
> > > > dependency on zynaddsubfx it is not needed during build or runtime. It
> > > > is a hollow ui and is supposed to be so.
> > > >
> > > > zyn-fusion(zest) is a runtime dependency, while on the other hand fltk
> > > > and ntk are linked with zynaddsubfx. Only one of these frontends can be
> > > > installed at a time.
> > > >
> > > > Since files created vary with the value of GuiModule, I will have to use
> > > > MULTI_PACKAGES, and then set dependencies and CONFIGURE_ARGS for each
> > > > subpackage(like fltk,ntk and zyn-fusion). I see no other possibility to
> > > > allow Gui choices but to make zynaddsubfx depend on zyn-fusion, then add
> > > > other frontends with MULTI_PACKAGES.
> > >
> > > If I understand correctly this setting changes existing built files?
> > > For example bin/zynaddsubfx (or some other file) would be present in
> > > each build but would be different depending on the build option?
> > > If so then that would be FLAVOR not MULTI_PACKAGES.
> > >
> > > MULTI_PACKAGES is used when you have a core set of files that are
> > > identical for all build options, and additional/missing files depending
> > > on the build options. For example where you have a bunch of dlopen()'d
> > > .so modules which are present or not depending on the build option,
> > > but the main binary doesn't change.
> >
> > So I was mistaken. It needs a mix of both, for different options some
> > common files are differently linked (zynaddsubfx will either call zyn-fusion
> > or zynaddsubfx-ext-gui) and an additional bin/zynaddsubfx-ext-gui
> > file is present for fltk and ntk. Not possible?
> >
> > If it is not, there is no real need to fret at it, aside from the rabbit
> > hole of tabs the rest of the Gui's will lead you into there is nothing
> > interesting they offer. Only Zyn-Fusion has been good enough for them to
> > monetize it.
> > >
> > > > The result should not be same. Check the images I've attached.
> > > > `zyn-fusion` - image1.png
> > > >
> > > > This interface has no connection with the backend and hence is utterly
> > > > useless.
> > >
> > > How about the attached set of ports:
> > >
> > > meta/zyn-fusion
> > > audio/zynaddsubfx
> > > x11/mruby-zest
> > >
> > > (If you unpack in /usr/ports/mystuff you'll need to copy or symlink
> > > meta/Makefile.inc from the main ports tree into mystuff/meta/Makefile.inc)
> > >
> > > x11/mruby-zest is your x11/zyn-fusion port renamed, and with the binary
> > > moved into libexec (so it's out of the normal path, which should remove
> > > most confusion). I used just the date in the version number for this.
> > >
> > > meta/zyn-fusion provides a "zyn-fusion" meta-package which only depends
> > > on both zynaddsubfx+mruby-zest. It's kind-of pointless but gives something
> > > so that people can pkg_add zyn-fusion.
> > >
> > > audio/zynaddsubfx is patched slightly to search in libexec for zyn-fusion.
> > > (Also fixed a 0/nullptr mismatch that is a warning in clang 10 and I guess
> > > might possibly break in clang 11).
> > >
> > > I also changed from SUBST_CMD to sed (using /usr/X11R6 / /usr/local in the
> > > patch) so that if you run "make update-patches" after building it doesn't
> > > undo the subst.
> > >
> > > If other guis are added later then we would add FLAVORS in zynaddsubfx and
> > > tighten/adjust the dependency in meta/zyn-fusion.
> > >
> > > This seems a good balance of not changing too much, and reducing user
> > > confusion (seems better to head off problems by making it so people don't
> > > run into them if possible, rather than hope they will read pkg-readme,
> > > some will but I know many won't and will just think it's broken when they
> > > don't get the bank lists etc showing up..) What do you think? I'm OK with
> > > importing like this.
> >
> > I'm perfectly fine with your changes.
> >
> > regards,
> > Dimitri

No comments:

Post a Comment