Makefile for Mac OS X instead of XCode / integrating JUCE code with existing project

#1

Hi everyone,

I’m trying to use JUCE as a module for an existing project written in C++. I basically want to use JUCE mainly for getting audio input / reading audio files and feeding it to the existing project. Using Projucer, however, makes it so that it sets up a new XCode project for the snippet of code I’m trying to write. This makes it a little challenging when trying to integrate these parts together without having to move the existing project to XCode.

I tried using the Linux Makefile Projucer generates to see if that would be easier, but the makefile has JUCE_CPPFLAGS that specify linux, which I believe causes it to not work on OS X (For example, it might say sys/prctrl.h isn’t available, since it’s only on linux).

Is there a way to compile JUCE code without xcode, or an easy way to use code written with JUCE in other applications? Thanks.

0 Likes

#2

This thread might be interesting to you: How does the Audiounit/VST file actually get created on OSX?
The main takeaway is that you can see all compiler invocations directly in Xcode.

Another place where you can look is FRUT (I’m the author). It enables building JUCE projects using CMake, which then supports many build systems (including Unix Makefiles and Ninja on macOS). You can build one of the JUCE examples using FRUT and look at the Makefile generated by CMake (though it might not be super readable), or you can study the code of Reprojucer.cmake (the central part of FRUT) to understand what are the main settings.

Finally, feel free to ask me any questions about building JUCE, I’ve got a lot of experience now.

1 Like

#3

Hi McMartin! Thanks for the reply.

I tried using FRUT on one of the JUCE demo files (ProcessingAudioInput). I followed the instructions on the readme, and ran it with -G “XCode”, but I’m getting the following error:

CMake Error at /Users/youngchk/FRUT/prefix/FRUT/cmake/Reprojucer.cmake:368 (message):

…/ProcessingAudioInputTutorial/juce_audio_basics/
is not a valid JUCE module
Call Stack (most recent call first):
CMakeLists.txt:43 (jucer_project_module)

It seems that it’s not able to properly recognize the module files, and I’m not sure why. Thanks for the help.

0 Likes

#4

I guess the .jucer you converted has its modules configured with “Use global path”. When you ran Jucer2Reprojucer on that .jucer file you should have seen an output similar to:

error: The module juce_audio_basics requires a global path. You should pass the JUCE modules global path using --juce-modules.
warning: Couldn't a find module header for juce_audio_basics module at "C:\Users\Alain\Downloads\ZIPs\ProcessingAudioInputTutorial\juce_audio_basics\juce_audio_basics.h".

(11 times, once per module).

The error message tells you than you should pass --juce-modules when calling Jucer2Reprojucer, like this:

$ ~/dev/FRUT/prefix/FRUT/bin/Jucer2Reprojucer ProcessingAudioInputTutorial.jucer ~/dev/FRUT/prefix/FRUT/cmake/Reprojucer.cmake --juce-modules ~/dev/JUCE/modules/
C:\Users\Alain\Downloads\ZIPs\ProcessingAudioInputTutorial\CMakeLists.txt has been successfully generated.

And then you should be good to go!

0 Likes

#5

Hey, McMartin. I’m the one who opened the AU/VST on OSX thread you linked to. I’ve since accomplished my similar goal of building JUCE plugins (but with bazel instead of cmake), but I figure if you went down the nasty road of figuring all of the same stuff out, I’d love to pick your brain a bit. I don’t know cmake at all, so forgive me if these questions are obvious after poking through your repo.

  1. How do you keep up with changes in JUCE/OSX? Or does your project only support recent versions of OSX that build JUCE somewhere near HEAD?

  2. For making audio plugins, how do you generate the resource files that are inside of the .au package? Do you also just mock the commands in the xcode project?

  3. Do you support windows? How different is that? I currently only have OSX and linux working and I found OSX to be sufficiently harder to figure out than Linux. Not having developed for Windows before, I’m likely to not even try.

Good to know there’s someone else that’s been down this road, I didn’t exactly enjoy the ride (though I like the destination provided it doesn’t take too much maintenance).

0 Likes

#6

I definitely recommend reading a bit about CMake before diving into FRUT. FRUT does allow you to build JUCE projects without having to type any CMake code, but you at least need to understand the high level concepts (meta build system vs. build system, configure phase vs. generate phase vs. build phase, etc.).

Now let’s answer your questions:

  1. FRUT supports all JUCE versions from 4.2.0 to the latest develop branch. There are some features from newer versions of Projucer that FRUT doesn’t support, so you could argue that some older versions of JUCE are “better supported” than newer ones. If you want to get the same behavior as Projucer version X.Y.Z, you can simply specify it (see https://github.com/McMartin/FRUT/blob/master/generated/JUCE-5.2.1/examples/HelloWorld/CMakeLists.txt#L23 for instance), otherwise FRUT will reproduce the behavior of the latest Projucer. This allows using an older version of the JUCE code (for instance 5.2.1), while using more recent features from Projucer (for instance, specifying Extra Custom Frameworks on macOS, which was added in Projucer 5.4.0).

  2. FRUT makes the build system (make, Ninja, etc.) call the Rez compiler “manually”. See https://github.com/McMartin/FRUT/blob/master/cmake/Reprojucer.cmake#L4528.

  3. FRUT supports Linux, macOS and Windows. For users of FRUT, it roughly works the same on all 3 platforms. For me, it means dealing with a lot of if/elseif in the code of FRUT. I’m mainly working on Windows, so feel free to ask any question.

I hope this helps. If you have more questions about FRUT, I invite you to create issues on the GitHub repository (https://github.com/McMartin/FRUT/issues) or to send me direct messages.

0 Likes