Clion Exporter broken on Mac

Seems like on the latest develop branch the CLion exporter is broken on Mac, even when using the default GUI app or default plugin template.

The CMake file itself has errors during parsing.

The problem seems to be related to this line

XCODE_ATTRIBUTE_MTL_HEADER_SEARCH_PATHS (
					"../../JuceLibraryCode",
					"/Users/eyalamir/Code/JUCE/modules",
				)

Changing the few appearances of this line manually to:

XCODE_ATTRIBUTE_MTL_HEADER_SEARCH_PATHS "../../JuceLibraryCode, /Users/eyalamir/Code/JUCE/modules"

Seems to fix it and build correctly.

I’m actually running into same issue with CMake file. I’m on BigSur with xCode 12 installed. Not sure if this has any connection, but probably worth mentioning.

Try updating your cmake version using brew - I’ve found that only Cmake 3.18 (the very latest) can correctly generate an Xcode 12 project.

Not sure how this should help. CLion doesn’t support Cmake 3.18 according to warnings I’m getting. Issue comes from Projucer generating incorrect CMakeLists…

Oh sorry, I thought you meant you have a hand-written CMake file and not a Projucer-generated one.

CLion does support CMake 3.18, you just need to install it via homebrew/manually.

Bump, as this is still broken.

i’m also having this issue on some projects. running xcode 10.1 (10B61), on high sierra

Bump, I am also unable to use the projucer exporter. I’m running xCode 11.3 on OSX Mojave, and the most recent projucer build.

I just started using JUCE and have the same issue. I need to manually edit the CMakeLists.txt everytime and it breaks again once exporting from projucer

If you are just starting using JUCE, and want to use CLion, I would recommend using JUCE’s CMake functionality directly. It’s much more powerful.

We will be moving away from the CLion exporter. If you are currently using it for your projects then please don’t worry about it disappearing under your feet - we will keep the current functionality for a while.

We’ll also have a look at the issue in this thread.

Thanks! I’ve switched most of my projects to use native CMake, but there are some existing projects/other people’s projects that use the Projucer, and it would be great to be able to use CLion with those.

P.S. I think many people have asked for a projucer->Native Cmake exporter which would make this transition much easier.

1 Like

This has now been fixed on the develop branch:

1 Like

Thank you. This is helpful.

I was looking at simply using CMake directly but can’t entirely figure out how to use it. Do I just need a template cmakelists txt file and plop it in my project?

When that’s done, can I debug audiopluginhost from clion the same way I can debug from xcode?

Thank you!

Have you checked out the CMakeLists in examples/CMake? We’ve tried to document those clearly to explain the set-up procedure. There’s also brief getting-started info in JUCE’s main readme, and a detailed API reference in docs/CMake API.md. If there’s anything that could be clearer in any of these docs, please let us know and hopefully we can improve them for everyone.

In addition to what @reuk has said, the answer to second question it yes - you can debug in CLion just like in XCode, attach the debugger to a DAW/AudioPluginHost, etc.

1 Like

Thanks for the quick responses!

I’ll definitely look over those docs and let you know if anything else can be noted to help with those instructions. I’m going to attempt a clean project and I’ll take notes on anything I find.

Thanks again for the great support!!

You weren’t joking at how easy the CMake api is to use. This is drastically easier for using CLion. Thank you! I was so used to intellij shortcuts that using xcode was painful.

One thing I’m curious about is if just have one CMakeLists.txt in the root allows for a CI approach like this: https://github.com/maxwellmattryan/juce-ci-starter

He seems to have two CMakeLists.txt (one in root and one udner the project folder). Is the ability to connect this to a CI pipeline dependent on a specific folder structure?

Thanks again!

The folder structure can be quite flexible, although having a top-level folder with inner project folders sounds quite sensible and will keep things tidy as the repo grows.

It looks like the approach in the linked repo is to just run cmake on the top-level folder, and to allow the top-level folder to include the other CMakeLists. If you want to use a single CMakeLists this will work too - just put everything in the top-level CMakeLists instead of splitting it into separate files and calling add_subdirectory.

1 Like