jackaudio
CMake build system for JackWeakAPI
Summary
I recently updated the jack2 port in vcpkg and fixed it to install a pkgconfig file. To my surprise I saw it had its own CMakeLists.txt which only builds JackWeakAPI, not the real JACK library nor the JACK server. I was not aware of the existence of JackWeakAPI before that and I did not find any documentation for how to build it. I am wondering if it would be welcome to move that CMakeLists.txt upstream into this repository.
I think it would be confusing to have a CMakeLists.txt in the repository root if it does not build the main library and executable. Perhaps we could make a new jackweak directory in the root of the repository, move JackWeakAPI.c to that directory, and put the CMakeLists.txt in there. What do you think?
Basic example
I got PortAudio building on GitHub Actions on Ubuntu, macOS, and Windows with both MSVC and MinGW using the jack2 port in vcpkg which builds JackWeakAPI with CMake: https://github.com/PortAudio/portaudio/pull/618
Motivation
Provide a cross platform way to build JackWeakAPI without the rest of JACK.
afaik the JackWeakAPI only works on macOS, that is why it just didnt get used much or at all. maybe it works on Windows with MSVC, but we are now using mingw for the official builds.
in any case, cmake is not officially supported as a way to build jack2, only waf is. if at any point we are moving to a different build system, it will be meson. There is already some WIP branch for this.
afaik the JackWeakAPI only works on macOS
I tried making a build of Mixxx for Windows with PortAudio built with the jack2 port in vcpkg but I did not get it to show JACK as an option for a PortAudio backend (I made sure JACK was running before starting Mixxx). I have not had time to debug this yet, but if JackWeakAPI doesn't even work on Windows, that would explain it.
If the vcpkg port was changed to build the real JACK library and an application linked that, would it work when deployed to another macOS or Windows computer running JACK? I am guessing the answer is no which is why JackWeakAPI exists.
if at any point we are moving to a different build system, it will be meson. There is already some WIP branch for this.
If the Meson build system provided a way to only build JackWeakAPI that would work too. Then the CMakeLists.txt in vcpkg could be removed.
If the vcpkg port was changed to build the real JACK library and an application linked that, would it work when deployed to another macOS or Windows computer running JACK? I am guessing the answer is no which is why JackWeakAPI exists.
I dont know about vcpkg port, I dont think anyone from the JACK project is involved with that. so you are on your own with that.
But to be more clear: you can build your own jack2 libs and link with that, then ship an application without such jack2 (but with a clear notice that jack is required to run, otherwise there will be missing libs of course). While this works fine on macOS, Linux and many other systems, it wont work on Windows. afaik this is because mingw libraries use an index for referencing to functions. So when jack2 is updated or rebuilt, the indexes can change. This is not set in stone though, help is welcome to make the situation better. But we should remain with mingw, at least until a time when MSVC comes to Linux.
if at any point we are moving to a different build system, it will be meson. There is already some WIP branch for this.
If the Meson build system provided a way to only build JackWeakAPI that would work too. Then the CMakeLists.txt in vcpkg could be removed.
If you really want JackWeakAPI as part of the build, the best for now would be to make it build/work as part of waf.
Was JackWeakAPI ever a part of the build system? Was there a different build system before waf?
afaik this is because mingw libraries use an index for referencing to functions. So when jack2 is updated or rebuilt, the indexes can change.
Ah, right, MinGW and MSVC do not produce ABI compatible libraries. So an application linked to a JACK library built with MSVC would not work with the official JACK library built with MinGW. Perhaps if I can get JackWeakAPI working it could work around that...
for linux, dont know. @sletz might know
macos and windows builds used xcode and msvc respectively.
Ah, right, MinGW and MSVC do not produce ABI compatible libraries.
err, the libraries are compatible if you map function pointers correctly. the linkage stuff is just different.
we have msvc built binaries (mixbus is an example) working with official jack2 builds using mingw. so technically they are ABI-compatible, we need a different term to refer to this :P
JackWeakAPI searches for a file called libjack64.dll but there is no such file shipped with JACK on Windows. The files installed to C:\Program Files\JACK2\lib are libjack64.dll.a, libjack64.lib, and libjack64.def.
we have msvc built binaries (mixbus is an example) working with official jack2 builds using mingw.
Interesting. Do you know where to find the build scripts they use for this?
JackWeakAPI searches for a file called libjack64.dll but there is no such file shipped with JACK on Windows. The files installed to C:\Program Files\JACK2\lib are libjack64.dll.a, libjack64.lib, and libjack64.def.
the jack libs are installed in %windir%
we have msvc built binaries (mixbus is an example) working with official jack2 builds using mingw.
Interesting. Do you know where to find the build scripts they use for this?
mixbus builds from ardour source code, so pretty sure there is a msvc file in there. but it doesnt have anything special, it uses weakjack from x42, so it just works.
I assume bitwig also uses msvc. it works as-is with jack on windows. (yes it has jack support on windows) There is a short list of jack+windows supported apps in https://jackaudio.org/faq/jack_on_windows.html
the jack libs are installed in %windir%
That expands to C:\Windows and indeed there is a libjack64.dll in there.
weakjack from x42
Interesting. I was not aware of this. What are the differences between that and JackWeakAPI apart from the license? @x42 could you clarify?
weakjack from x42 is GPL licensed, so not suitable for some projects. JUCE does similar things https://github.com/juce-framework/JUCE/blob/develop/modules/juce_audio_devices/native/juce_linux_JackAudio.cpp#L26 and I have my own version for carla and dpf at https://github.com/DISTRHO/DPF/tree/develop/distrho/src/jackbridge (more liberally licensed, but not 100% self-contained as it needs a few headers from the same repo)
JackWeakAPI might be working okay. It is possible there is a bug in my PortAudio branch. I'll investigate that further.