Hi,
I’m trying to use some JUCE code as part of a secondary project in Qt.
Exporting my JUCE files from Projucer as a static library (.a), I can then successfully include it as a library into my Qt project, but I then run into issues.
I add the JUCE Project as part of INCLUDEPATH, which allows me to do a #include "/Source/MyClass.h"
But the compiler then spits out that <JuceHeader.h> file cannot be found. (And if I link JuceHeader properly, then all the JUCE global modules (audio_basics.h, etc…) cannot be found… and I have not been able to manually solve that one. The linker in the Qt Project just doesn’t cope with JUCE global modules added to INCLUDEPATH for some reason)
Any tips or ideas? It seems the headers are purely made for the Projucer, which I understand, but how am I supposed to include my library files properly? (I’m on Linux - I don’t know if the VS or XCode exports maybe make more sense).
Hi, in my (limited) experience Juce needs pretty much to be Juce-centric i.e. you can add 3rd party libs to juce (with normal linkage/platform/compiler issues that apply to all projects) but if Juce is around, and you want to stay sane, you need a projucer-centric workflow.
There is a blue pill tough (or was it red?) I managed in the past to make a non juce centric project use a juce library,. having only some problems in debugging/setting breakpoints in the library.
In brief :
make your juce static library & maintain it with normal projucer workflow
make library only public headers standard C++ (no juce objects)
use pimpl to make public features use JUCE internally
Of course you’re gonna be somewhat limited and need to find hacks for a lot of situations (my lib was not UI but DSP oriented, so a lot of message thread/component/graphic context issues were not in my way) but it’s anyway a possible road ahead.
Thank you for the info!! It seems like a tough process and I guess I was attempting what you did in your non-juce-centric project without making it all the way.
I think I’m just gonna drop the Qt part of the project and develop it in JUCE (as the JUCE graphics are somewhat equivalent to the QGraphics Framework, which is what I was using).
But am I right about this - Projucer’s Static Library option is actually not implemented? How is it that the library is unusable? Or is it that it would only just work in another JUCE project. Either way I’m quite surprised to see the shortcoming of the platform.
Never tried to use a juce static library added as a 3rd party lib to a juce project, but once you have a projucer driven project the static library concept is covered by the juce module concept. If you drop qt and go with projucer your easiest path to modularize your project is by making juce modules.
I’ve been following along with this thread, which has been crazy helpful. I am trying to build a Xcode Swift macOS app with a static juce library and have been running into linking issues.
After following the great advice by @fefanto and following these articles on working with c++ and swift: Swift++ == Swift => C => C++ => STL and Use a C++ Library from Swift. I can call a class in my static library that has no juce calls at all. I’m using the pimpl approach, only having juce references and objects in cpp files
For linking, I have linked the library (which also added it as a framework automatically), added the path to my static library headers in “Header Search Paths”, and added the path to my library in the static library juce project in “Library Search Paths”. Without juce objects in my pimpl’s, I can use/call my library classes no problem. But once I add a private member in the pimpl class, I get 78 undefined symbol errors.
Has anyone had any success doing this, or has any suggestions on how to resolve this linking problem? I have also tried using the juce module path in “Header Search Paths” and “Library Search Paths”.
I was able to solve it because this post. Essentially all the errors were because I needed to add some of the apple frameworks to the projects (eg: Accelerate, CoreAudio, AudioToolbox, etc).
At the moment yes, but the goal is to build something with the bare minimum of juce objects to make sound in macOS. Then test it on Windows/Linux.
The big goal is to create a standalone program that’s cross-platform. The audio engine will be juce, and I’ll build the middle and front end with Electron.
