Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 3.0.7 #390

Open
pgervais opened this issue May 12, 2023 · 7 comments
Open

Release 3.0.7 #390

pgervais opened this issue May 12, 2023 · 7 comments
Assignees

Comments

@pgervais
Copy link
Collaborator

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 pgervais self-assigned this May 12, 2023
@pgervais
Copy link
Collaborator Author

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 zynaddsubfx/zynaddsubfx#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
Copy link
Collaborator Author

I'm treating zynaddsubfx/zynaddsubfx#246 as release-blocking, because it breaks the build on Windows.

@pgervais pgervais pinned this issue May 26, 2023
@pgervais
Copy link
Collaborator Author

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

  • Linux: Compiles fine with fltk/ntk/zest UIs. The standalone binaries run, I saw some weirdness with VST2 and LV2 plugins in Ardour but it's likely my ignorance that is the cause here. I'll look harder.
  • Windows: doesn't compile (see previous message)
  • MacOS Intel: not tested yet
  • MacOS Apple silicon:
    • the standalone binary compiles with the fltk UI, with this patch: Remove unsupported flag on MacOS zynaddsubfx#247. I am treated the NTK and zest UIs as not supported for the time being.
    • The Zynaddsubfx plugin does not compile maybe because of a lack of support in DISTRHO for Apple silicon (see below)
    • All other plugins compile. I haven't tried running them yet.
    • Zynaddsubfx and rtosc tests compile and run, but three of them fail: test-port-checker, UnisonTest, MessageTest. I haven't investigated yet.

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
Copy link

falkTX commented May 26, 2023

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
Copy link
Collaborator Author

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:

  • we give up on the macos plugins for version 3.0.7 and publish the release with this caveat.
  • we give up on pushing the 3.0.7 release before the DPF refactoring.

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
Copy link
Collaborator Author

Other problem: Windows cross-build is broken. See my comment on fundamental/rtosc@96eaa76 @fundamental @falkTX

@fundamental
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants