search

zynaddsubfx / zyn-fusion-issues

Issue Only Repo
31 stars 0 forks source link

Release 3.0.7 #390

Open pgervais opened 1 year ago

pgervais commented 1 year ago

Main ticket to track the status of the 3.0.7 release, and the decisions that were made during the process, for future reference.

pgervais commented 1 year ago

I created release branches for 3.0.7 in both zynaddsubfx and mruby-zest-build, because I expect there will be some minor fixes necessary in the build system, in particular for Mac OS. I don't want to block the work on https://github.com/zynaddsubfx/zynaddsubfx/pull/221, so having a separate branch makes it possible to work in parallel.

https://github.com/zynaddsubfx/zynaddsubfx/tree/release-3.0.7 https://github.com/mruby-zest/mruby-zest-build/tree/release-3.0.7

My plan is to add a tag with the version number once we decide to release, and to cherry-pick on master whichever fixes are relevant.

I will also add such a branch in zyn-fusion-build, after I've made some modifications to make it possible to specify which branch to clone for the zynadd and zest repositories - so that the '3.0.7' commit in zyn-fusion-build actually compiles zynadd release 3.0.7 instead of the git HEAD.

pgervais commented 1 year ago

I'm treating https://github.com/zynaddsubfx/zynaddsubfx/issues/246 as release-blocking, because it breaks the build on Windows.

pgervais commented 1 year ago

A short update about the status of the release so far:

This is the compilation error I get on MacOS Apple Silicon:

Compilation failure for ZynAddSubFX_lv2_ui
[ 85%] Linking CXX shared library lv2/ZynAddSubFX_ui.dylib
Undefined symbols for architecture arm64:
  "DISTRHO::getDesktopScaleFactor(unsigned long)", referenced from:
      DISTRHO::UI::PrivateData::createNextWindow(DISTRHO::UI*, unsigned int, unsigned int) in DistrhoUIMain.cpp.o
ld: symbol(s) not found for architecture arm64

@falkTX Is that missing symbol error expected?

falkTX commented 1 year ago

might be. until we deal with the dpf update on the main zyn repo we cant expect DPF stuff to work proper. previous attempts of non-linux builds were always very hacky.

the PR with the DPF update (and then reusing DPF CI stuff for testing) is a step to ensure win/mac/linux plugin builds work proper.

pgervais commented 1 year ago

A short update. Using one of github's MacOS builder I ran a compilation of zyn on Mac Intel. It failed with the exact same error as on Mac Arm.

This means that zynadd standalone with the fltk interface can be compiled (and runs), but the plugin version doesn't compile. Given the current refactoring, I see two paths forward:

I would be in favor of the second one. @fundamental what's your take on that? It looks like the DPF change is getting closer to completion. Is it worth waiting?

pgervais commented 1 year ago

Other problem: Windows cross-build is broken. See my comment on https://github.com/fundamental/rtosc/commit/96eaa76fb8292e05b0b8ce42e8c5741c5b48efab @fundamental @falkTX

fundamental commented 1 year ago

I'm fine with this release having issues with MacOS since that's been the case for the last several, it wouldn't be a bad thing to have a release finalize the DPF changes (last time I checked there were a few regressions, but some of those may be resolved now). As per the windows cross build, something is breaking liblo pathing. I think there was a recent patch for using pkg-config in that environment which may be the source of the regression 8a12c705f89535cf5c416e539a8f57aac7799bfa