Add Carla support for MacOS

[tresf]

• Bump Homebrew formula to use beta version (It'll work with 1.9.9 onward now)
• Bump to beta version by addressing code changes in Use new carla-native-plugin library #4593
• Wrap precompiler check around window->winId(); to prevent it from having focus bug.

Steps:

1. Install Carla to /Applications:
   https://github.com/falkTX/Carla/releases/download/v1.9.9/Carla_2.0-beta7-macos.dmg (this version has the hang-on-relaunch bug, wait for 2.0 RC2 or stable)
   • ... or the beta: http://download.linuxaudio.org/kxstudio/Carla_2.0-RC1test1-macos.dmg
2. Install LMMS to /Applications:
   https://github.com/tresf/lmms/releases/download/v1.2.0-RC7/lmms-1.2.0-rc6.36-mac10.13.dmg (this version has the focus bug, 1.2.0-RC7 onward will be fixed)
   Details:

• Adds a new DYNAMIC linking option for BuildPlugin.cmake for -undefined dynamic_lookup linking against an optional .dylib.
• Adds falktx/Carla as a submodule to LMMS to provide carla-standalone.pc and required headers. These should eventually be moved to a Homebrew recipe.
  • Installs carla-standalone.pc to the build directory with some regex changes. These are hackish and slightly volatile, but the submodule will ensure we're on a dedicated commit hash.
• For the plugins to show up, LMMS assumes Carla is side-by side (e.g. /Applications/LMMS.app and /Applications/Carla.app).
  • Unfortunately, LMMS is currently hard-coded to look in /Applications/Carla.app when launching the python scripts, so the plugin may appear in the plugin listing but fail to launch if installed elsewhere (e.g. ~/Applications/Carla.app, etc.). This is an easy runtime detection that can be fix if needed, located at plugins/carlabase/carla.cpp#L165
  • I haven't tested this. I don't use Carla, so I'm not sure what's needed to test this out.

Closes #2689

[PhysSong]

The problem is that the build system will try to link with the Carla library even if it doesn't exist. pkg-config seems not to check if the library file is available. I think you should use the pkg-config trick only if the .dylib file is available.
Additionally, you may want to install Carla on Travis-CI.

[tresf]

I think you should use the pkg-config trick only if the .dylib file is available.

This is why I've added a new BUILD_PLUGIN LINK option.

I don't think it will make sense to use -bundle_loader for SHARED on macOS. How about keep using SHARED and testing for it instead of the new DYNAMIC?

That was my original thought, to just strip the -bundle_loader flag when building SHARED, but from what I recall it just resulted in more errors.

Note that this library was already using SHARED since #2578. At compile time I don't think we'll know if the target is a .dylib or an .so because the libs are referenced by path and name (not by extension). Correct me if I'm wrong. :) Here's my initial trial and error: #2689 (comment).

Additionally, you may want to install Carla on Travis-CI.

Might have to. I'm pretty sure I got it building locally using -undefined dynamic_lookup without Carla.app installed but I'll have to do some more testing.

[PhysSong]

I think you should use the pkg-config trick only if the .dylib file is available.

I mean something like this: PhysSong@65983c5

That was my original thought, to just strip the -bundle_loader flag when building SHARED, but from what I recall it just resulted in more errors.

See e.g. PhysSong@c57a607. I'm not sure about the CMP0068 part though.

At compile time I don't think we'll know if the target is a .dylib or an .so

IIRC it's determined when linking.

[tresf]

See e.g. PhysSong/lmms@c57a607.

Did you mean to completely remove the SHARED|BUNDLE logic for all systems there? I'm out of my expertise here with the linking stuff. If I'm doing it wrong, feel free to help fix it. I've tried a bunch of combinations and the SHARED + -undefined dynamic_lookup seems to work best for Carla. I'm not sure if it would break other parts of the software though so I'm hesitant to change it.

I'm not sure about the CMP0068 part though.

I have that fixed now. Specified the old cmake behavior.

[tresf]

All concerns addressed, just waiting for Homebrew/homebrew-core#31560 to be merged.

[tresf]

Due to some changes in Carla, the Homebrew recipe requires updating and then we'll have to copy in the patches kindly provided by @falkTX in #4593.

SInce ee6d502, b38dd02 it'll build with 1.9.9 or 2.0.0 now. We'll automatically take the new carla version when it's ready. 👍

[tresf]

@PhysSong once Travis-CI passes, this is ready for merge. The only thing we need decision on is the style of the precompiler checks in #4558 (review).

[tresf]

Updates:

• Wrapped a precompiler check around window->winId(); to disable it on macOS to prevent it from having a major focus bug. Possibly related: "Stay on top" bug when project contains VST effects #4183, QTBUG-63787, QTBUG-30181, QTBUG-69343.
• @falkTX was able to fix a pretty serious bug preventing LMMS from being relaunched after Carla was loaded on MacOS thus closing LMMS + Carla macOS specific issues falkTX/Carla#737, a blocker for the Carla 2.0 release. This was also affecting Ardour and it took a very long time to locate. See #programming channel on Discord, search for "semaphore" if interested in the saga... just to explain the severity of this bug, you'd have to logout from the macOS Desktop and back in again to get LMMS to relaunch from the Dock and there was no backtrace. He debugged this line-by-line by logging out and back in. Thanks again @falkTX. 🎉
• All code comments addressed.

Waiting for Travis-CI, then merging.

[JMii63]

this entire thread is like a novel and I am all here for it. Good job :)