@JanosJuce - I see. I’ll have to compile them as ObjC++ targets then. Thanks, that actually helps a lot.
@jamiebullock - This may be a longer answer than you’re looking for. I started working in Juce in XCode a few years back. I’ve never been a big fan of XCode (save it’s debugger) and I never really got the hang of how Projucer and XCode worked together. I felt like I was always struggling to keep Projucer in sync with XCode. I had a tendency to want to make new files in XCode and then I occasionally had to go back and tell Projucer about them. Either because that’s the way it is or because I wasn’t following some proper workflow, I never got really comfortable.
The reason I switched has more to do with trying to scale to larger projects. If I’m going to build lots of plugins, I might as well share code between them. I believe in XCode, doing this “the right way” means having several interdependent projects and switching between them. That brings with it a ton of baggage. I don’t want my project folders filled with XCode junk. So I was working out of one file and using multiple targets. This works OK until you have to make edits to “some massively shared function in a header” and rebuild everything just to test it. Never really figured out how to do proper unit testing with XCode, either. The short answer is that XCode is too damn complicated for me. If other people like it, that’s awesome, though.
Enter bazel. I use it at work, so it’s already familiar. Unlike writing makefiles, bazel BUILD files are highly readable. Its error messages are mostly friendly. If I want to test “some massively shared function in a header”, it’s easy and the iteration cycle is very fast. Every .cpp/.h pair I write is its own target and I can write it a unit test. It’s not a perfect world, though. Though writing bazel build rules for my own code is beautiful, the major con of using bazel is that writing build rules for third party code can be a nightmare. Juce was a nightmare. Bazel wants to build a dependency tree where ProjectA and ProjectB both depend on Juce and that’s the end of the story. However, the Juce library needs project-specific information to build (the #defines in AppConfig.h) so I had to do some juggling to get around that.
I succeeded in getting everything working on Linux and I’m very happy with it. I really enjoy developing on Linux. However, Linux audio is kind of a sad situation compared to Mac. If I can’t build my plugins on Mac, I’ll never actually use them for making music. So I have to write some build rules that work on Mac. This shouldn’t be too bad now that I have some more understanding of the basic structure. Bazel support for C++/ObjC integration has improved quite a lot in the recent past. I haven’t tried Juce on Windows at all, but probably will someday. (If I have to. I guess.)
If anyone is thinking of going this route, feel free to ping me. If I manage not to scare you off, I’ll at least help you get your BUILD files working.