Building JUCE projects using CMake made easy

(edited on 2019.10.17) Reprojucer.cmake used to print the following error message when it failed to build and install BinaryDataBuilder:

-- Building and installing BinaryDataBuilder
CMake Error at <root>/FRUT/cmake/Reprojucer.cmake:2992 (message):
  Failed to build and install BinaryDataBuilder.  Please report this problem
  by writing a new comment on the following GitHub issue:
  https://github.com/McMartin/FRUT/issues/513

If you are getting this error message when configuring one of your projects, please first update FRUT to commit 07f2f1c081a59dcdaafbc69461bedad63979d4f0 or more recent. Then try again to configure your project and read the new error message if it still fails to build and install BinaryDataBuilder.

This PR adds the COMPILE_IN_TARGET keyword to the jucer_project_module() command, which enables compiling JUCE module source files in specific targets.

Fixes https://github.com/McMartin/FRUT/issues/9. Supersedes https://github.com/McMartin/FRUT/pull/349.

@MartyLake, @scotchi: please review, thanks!

After following the build instructions in the getting started, I am able to generate the CMakeLists.txt file, however when building this file, I get the following error: CMake Error: File /Users/vedant/Desktop/Programming/MUSI6106-Project/plugin_framework/GuitarAmpPlugin/data/JuceLibraryCode-Wrapper.cpp.in does not exist. CMake Error at /Users/vedant/Desktop/Programming/MUSI6106-Project/plugin_framework/FRUT/cmake/Reprojucer.cmake:557 (configure_file): configure_file Problem configuring file Call Stack (most recent call first): CMakeLists.txt:72 (jucer_project_module)

I am using JUCE v.6.1.5 in CLion and the latest version of FRUT

Hi @McMartin . I'm excited to get going with this but have a hit a minor issue on the first attempt. The header paths from my Projucer files import correctly. They look like this:

  HEADER_SEARCH_PATHS
    "Builds/LinuxMakefile/\"/usr/local/include/csound\""
    "Builds/LinuxMakefile/\"/usr/include/csound\""
    "Builds/LinuxMakefile/\"~/SDKs/VST_SDK/VST3_SDK\""

I can manually edit them and move on from there, but thought it might be worth noting in case I am doing something wrong?

When using FRUT to generate an XCode project through my generated CMakeLists.txt, Xcode throws up the following error:

error: The i386 architecture is deprecated. You should update your ARCHS build setting to remove the i386 architecture.

When I generate an XCode project from my Projucer directly, the architecture is fine.

The OSX Architecture field in my Projucer is set to Default. When I change it to 64-bit Intel, the generated XCode project works, so it looks like the default isn't being detected correctly by FRUT.

Hi, having problems with clion... but also with others...

clion-2018.3.4/bin/cmake/linux/bin/cmake -DCMAKE_BUILD_TYPE=Debug -G "CodeBlocks - Unix Makefiles" /home/aldo/prova1/Projucer
CMake Error at /home/aldo/FRUT/cmake/Reprojucer.cmake:1540 (message):
  You must call jucer_export_target("Code::Blocks (Linux)") before calling
  jucer_project_end().
Call Stack (most recent call first):
  CMakeLists.txt:742 (jucer_project_end)

Where did the string "Code::Blocks (Linux)" came from?

here is the official string for the generators: https://cmake.org/cmake/help/latest/generator/CodeBlocks.html#codeblocks

I saw that the code in Reprojucer.cmake improperly uses that string to check for the generator but it should be "CodeBlocks - Unix Makefiles"...

I've even succeded cross compiling to mingw64 using mxe cmake toolchain with some hacks to the Reprojucer.cmake script. Much painful!

Hi! Long story short, I have an assignment in which we were asked to export a project from Projuicer to Visual Studio. I would like to use Clion instead, but that requires that I convert the .jucer file to .cmake

I'm using Windows10, so I installed WSL Ubuntu, got the whole thing running (after 3 hours of trial and error) I installed all the dependencies I could, but when running $ cmake --build . --target install the console says "Building CXX object Jucer2Make......" and then after 5 lines it breaks saying "91 | #error "JUCE requires C++17 or later"

I have the latest version of g++ and clang installed on the ubuntu vm. I installed g++-multilib too.

Do I need to add something additional to the build/target command ? I am learning C++ and I'm quite new to linux, so I apologize if this is a complete noob question. I've exhausted my options.

In the meantime I can continue working on Visual Studio but it's inconvenient once I'm already used to my Clion IDE :(

Thanks in advance to anyone who could give me a hint

I recently updated to JUCE 7, and began getting this error when I try to build with CLion using CMake

Undefined symbols for architecture x86_64:
  "_OBJC_CLASS_$_MTLTextureDescriptor", referenced from:
      objc-class-ref in libBasic.a(include_juce_gui_basics.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

From a little digging, I think something is up with how FRUT is generating the CMake file. I am still able to build/run my code with Xcode using Projucer.

"Getting Started" should specify Juce modules root when directing user to run Reprojucer

Otherwise an error is raised similar to: error: The module juce_audio_basics requires a global path. You should pass the JUCE modules global path using --juce-modules.

https://github.com/McMartin/FRUT/blob/282f7204f3bada25ea411e209180a4fa2384de20/cmake/Reprojucer.cmake#L1358

It seems almost certainly wrong to use -march=native on release builds since it stands to reason that portable binaries are desired. Before realizing that FRUT was adding this flag, I spent several hours tracking down why VSTs built on my Linux desktop with this were crashing on startup when I installed the packages on my laptop. Specifically, the default x86-64 should probably not be overridden.

Hi @McMartin,

I post this issue to report you a bug/limitation with the last version of FRUT (the one on master : 0db9b2a) and JUCE 5.2.0. The problem comes from the Icon (small) and Icon (large) fields in the Projucer. Indeed, to add an Icon to our standalone application, we added an image (png format) in Projucer and set it in the Icon (small) and Icon (large) fields, and when we built the application, no change seems to have occurred. Then we tried to build our application directly using Projucer, and the changes were effective.

FYI, this icon is present in several places. Here is the ones we noticed :

• When the standalone application is open, the icon represent the application in the Docker on OSX and in the Windows' taskbar.
• When the file is build, his icon is the one set in the Projucer on both Operating System.
• In Xcode, the targets icon is the one set by the Projucer too

If you need more informations, or tests on this issue, don't hesitate to ask. Thanks for your time and your work :smiley:

Hi @McMartin,

Apologies for the noob question. I'm fairly new to C++, CMake, JUCE and FRUT. Gotta start somewhere right ;). Firstly thanks for this amazing tool, it great to be able to build a whole project from the commandline rather than reliance on a GUI etc.

I'm experimenting with both JUCE and FRUT at the moment, with the intention of creating a hardened release build. When running an build using the Xcode target even with STRIP_LOCAL_SYMBOLS I find strings related to the build including references to the cpp source files present in the binary. Futhermore, I also find mangled function names in clear sight that would aid a disassembler to circumvent any sort of registration process or aid other malicious intenent.

The example export target that I'm using:

jucer_export_target_configuration( "Xcode (MacOSX)" NAME "Release" DEBUG_MODE OFF BINARY_NAME "test_plugin" STRIP_LOCAL_SYMBOLS ON OPTIMISATION "-O3 (fastest with safe optimisations)" )

I used the utility program called strings (which may have been installed with Xcode) to discover this. Do you know what I might be missing? Do I require linker flags or additional compiler switches.

I'm using: Apple clang version 13.1.6 (clang-1316.0.21.2.5) Target: x86_64-apple-darwin21.6.0 Thread model: posix

Many thanks in advance ;)

If you would like Reprojucer.cmake to support the setting USE_MKL_LIBRARY_ONE_API ("Use MKL Library (oneAPI)" in Projucer), please leave a comment on this issue.

If you would like Reprojucer.cmake to support the setting USE_IPP_LIBRARY_ONE_API ("Use IPP Library (oneAPI)" in Projucer), please leave a comment on this issue.

If you would like Reprojucer.cmake to support the setting USE_LEGACY_BUILD_SYSTEM ("Use Legacy Build System" in Projucer), please leave a comment on this issue.

If you would like Reprojucer.cmake to support the setting USE_PRECOMPILED_HEADER ("Use Precompiled Header" in Projucer), please leave a comment on this issue.

Juce 7 now supports the LV2 plugin format.

It's enabled via Projucer the same way the other formats are enabled, by adding a value to the JUCERPROJECT/pluginFormats property: buildLV2 (as compared to buildVST3 for VST3 for example)