Mac OS X VST support #2393
Mac OS X VST support #2393
Conversation
On Mac OS X dynamic libraries (dylib) and shared objects (so) are two separate concepts. HACK: The definition of the BUILD_LIKE_A_PLUGIN macro is almost completely duplicated from BUILD_PLUGIN.
CMake changed its behaviour somewhere along the way, and specifying commands by SOURCE is no longer the way to do it.
GNU "find" defaults to the current directory, but most other "find" implementations don't. (The POSIX spec treats the path as mandatory.) We could also use "mv" or CMake's RENAME macro.
Although LMMS has been built primarily on Linux for a long time (it's even in the name!), there are other platforms that can benefit from LMMS's Wine-based VST support. Mac OS X is the obvious one (and the one relevant to me right now).
| @@ -63,3 +63,63 @@ MACRO(BUILD_PLUGIN PLUGIN_NAME) | |||
| SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "${ER_H} ${plugin_MOC_out}") | |||
| ENDMACRO(BUILD_PLUGIN) | |||
|
|
|||
| MACRO(BUILD_LIKE_A_PLUGIN PLUGIN_NAME) | |||
| CMAKE_PARSE_ARGUMENTS(PLUGIN "" "" "MOCFILES;EMBEDDED_RESOURCES;UICFILES;JUSTALIBRARY" ${ARGN}) | |||
There was a problem hiding this comment.
What is JUSTALIBRARY? I'm having a hard time finding documentation on this...
Edit: If this is in fact needed, we may want to keep our existing plugin macro and shim this in with an IF statement.
|
@rhunter Thanks for the work on this. I've made a few in-line comments. |
| @@ -39,17 +39,17 @@ IF(LMMS_HOST_X86_64) | |||
| ENDIF(LMMS_HOST_X86_64) | |||
|
|
|||
| ADD_CUSTOM_COMMAND( | |||
| SOURCE "${CMAKE_CURRENT_SOURCE_DIR}/RemoteVstPlugin.cpp" | |||
There was a problem hiding this comment.
This entire section may be worth breaking out into its own block under IF(LMMS_BUILD_APPLE) (or perhaps IF-clang). Also, a description as to why these changes are needed would go a long way to understanding why these are needed.
|
@rhunter I know this is far from complete, but if you can address the requested changes, we can get closer to getting these changes integrated. There's very little disadvantage in implementing this as-is (we can always remove the library at bundling time until we get the feature actually working). |
|
@rhunter any progress on this? I'm cleaning up branches and noticed @tobydox's Again, if we can cleanup the code, there's no risk in merging and keeping the plugin disabled on Apple until the bugs are worked out. |
|
@rhunter I'm closing this from a task perspective, but please feel free to reference it or reopen it when its ready. |
(do not merge)
I've been investigating issue #698 "VST Plugins on OS X (Apple)" and have had some (limited) success.
This is definitely a work in progress -- it's quite incomplete, and several of the changes are solving problems in entirely inappropriate ways -- but I want to share what I've been doing so far.
Eventually, I suspect that this will spawn into a few smaller pull requests, such as:
At this time, the code builds on only on Mac OS X -- one commit in particular, 149b4fa, almost certainly breaks Linux support. (That's clearly not OK for a real solution, but as a temporary change it helped me progress a little).
Compilation and linking succeed (woot) but there are some semaphore issues that hang the plugin. This is helped somewhat by the changes in pull request #2390.