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 <deserter...@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. > 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.
zyn.tgz
Description: application/tar-gz
