Announcing beta CLion support in the Projucer

[t0m]

Hi all,

We have just released a new CLion exporter in the Projucer on the develop branch:

https://github.com/WeAreROLI/JUCE/commit/21315abce494f2ec2968c9c0241c5e618e9a9aa9

To use JUCE with CLion you must check out the develop branch from GitHub and recompile the Projucer so that you can access the new exporter.

There are a few things to note about this new feature:

• This is a beta release, so please report any issues you encounter.
• The generated CMakeLists.txt file can be used on MacOS, Windows and Linux. On Windows you will need to have the MinGW compiler installed.
• The CLion exporter can be thought of as a “shell” exporter, where it takes build configurations from other exporters added to the project. The currently supported “source” exporters are:
  • Xcode
  • Linux Makefile
  • Code::Blocks (Windows)
• Not all build configuration options are currently supported. In particular, on MacOS you cannot build fat binaries or AUv3 plug-ins or embed resources, and application icons are unsupported on all platforms.
• When you first open a JUCE project with CLion you will need to change the project root before you can browse your source files. A popup warning in CLion will prompt you to do this.

Please try it out and report back!

[jules]

@timur

[jimc]

Awesome

I’ll will be super pleased when i don’t need to xcode any more

[eyalamir]

This is pretty amazing, thank you!

I’ve been wanting to use JUCE in CLion for quite some time, mainly for all it’s refactoring options.

So far, I only opened a few examples and it seemed to have been going rather well.
However:

1. When I opened the DSPModulePluginDemo on the latest CLion EAP for Mac, I immediately got a bunch of ‘red code’ and compiling errors (worked and compiled OK on XCode):
   

   

2. When I opened “DSPDemo”, while it did compile OK, I got false error reporting and error messages.
   

   

3. Which folder do I need to set when setting the root folder?

4. “Save Project And Open In IDE” doesn’t work (yet?).

5. I got red code in “OpenGLAppExample”:
   

   

6. Adding modules to “Local Copy” seemed to be the only way I’ve found that makes them browsable within the CLion project. Is that the intended way to do it?

Thanks again for making this happen!

[t0m]

1. Fixed

https://github.com/WeAreROLI/JUCE/commit/73573ede912bf4fffbc8100a19ebf7402aab88d8

2. I’m not sure this is something we can fix in JUCE… the code is correct and we’re not doing anything unusual.

3. (+ 6.) I set the root folder to be two directories up from it’s original location, which lets me browse the project source code. Unfortunately I’ve not found a way to make code browsable if it’s not under the current project root. Copying the modules locally will fix this, but if anyone knows more about this than me then please let me know!

4. Yep, this is on the todo list.

5. This is another CLion C++ parsing bug. There’s nothing wrong with the code!

[jamiebullock]

This is fantastic, thank you! I’ve been tempted to make the jump to CLion after horrendous experiences with Xcode 9 and this might just be the thing that tips me over the edge (plus CLion has vim mode!)

[t0m]

Whilst there are a few false positives, CLion also provides some really worthwhile suggestions and warnings - far beyond what I’ve come across in other IDEs.

[Jnv]

I am really interested in CLion on Windows, so I made a test with the Projucer. At 98%, it finds errors:

In file included from G:/MESDOC~1/ARKOST~2/REPOSI~1/JUCE/extras/Projucer/Builds/CLion/../../../../modules/juce_gui_extra/juce_gui_extra.cpp:152:0,
             from G:\Mes documents\Arkos Tracker 2\repository\JUCE\extras\Projucer\JuceLibraryCode\include_juce_gui_extra.cpp:9:
G:/MESDOC~1/ARKOST~2/REPOSI~1/JUCE/extras/Projucer/Builds/CLion/../../../../modules/juce_gui_extra/native/juce_win32_WebBrowserComponent.cpp: In static member function 'static void juce::WebBrowserComponent::clearCookies()':
G:/MESDOC~1/ARKOST~2/REPOSI~1/JUCE/extras/Projucer/Builds/CLion/../../../../modules/juce_gui_extra/native/juce_win32_WebBrowserComponent.cpp:407:99: error: cannot convert 'const char* const' to 'LPCWSTR {aka const wchar_t*}' for argument '1' to 'void* FindFirstUrlCacheEntryW(LPCWSTR, LPINTERNET_CACHE_ENTRY_INFOW, LPDWORD)'
 ::HANDLE urlCacheHandle = ::FindFirstUrlCacheEntry (searchPattern, entry.getData(), &entrySize);
                                                                                               ^
G:/MESDOC~1/ARKOST~2/REPOSI~1/JUCE/extras/Projucer/Builds/CLion/../../../../modules/juce_gui_extra/native/juce_win32_WebBrowserComponent.cpp:412:94: error: cannot convert 'const char* const' to 'LPCWSTR {aka const wchar_t*}' for argument '1' to 'void* FindFirstUrlCacheEntryW(LPCWSTR, LPINTERNET_CACHE_ENTRY_INFOW, LPDWORD)'
     urlCacheHandle = ::FindFirstUrlCacheEntry (searchPattern, entry.getData(), &entrySize);
                                                                                          ^
CMakeFiles\APP.dir\build.make:1437: recipe for target 'CMakeFiles/APP.dir/G_/Mes_documents/Arkos_Tracker_2/repository/JUCE/extras/Projucer/JuceLibraryCode/include_juce_gui_extra.cpp.obj' failed
mingw32-make.exe[3]: *** [CMakeFiles/APP.dir/G_/Mes_documents/Arkos_Tracker_2/repository/JUCE/extras/Projucer/JuceLibraryCode/include_juce_gui_extra.cpp.obj] Error 1

Is there anything that I should do to correct these? Thanks.

Julien.

[Jnv]

I couldn’t have it work for my own project, and found out why: the project name in the generated CMakeLists.txt must NOT have spaces:

line 16:
project (Arkos Tracker 2 C CXX)
changed to:
project (ArkosTracker2 C CXX)
… as well as all the references to the project name in the file. Works much better (and almost)!

[t0m]

Thanks for reporting!

I suspect handling spaces correctly should be relatively straightforward - we’ll look at that on Monday morning.

What compiler are you using? I’ve successfully built the Projucer with whichever 32 bit MinGW compiler is distributed with Code::Blocks and a 64 bit MinGW-w64 compiler from a couple of years ago.

[t0m]

As a short term fix for other projects (which don’t depend on an internal web browser) you can set JUCE_WEB_BROWSER to Disabled in the settings for the juce_gui_extra module.

[Jnv]

I also use the 32-bit compiler inside Code Blocks and it “kinda works”:
In Debug, the compilation and linking work, but the generated EXE (51 megas!) open a console that closes immediately after. No error message, nothing.
In Release, compilation works, but linking fails, with many errors:

[100%] Linking CXX executable Projucer.exe
jucer_PaintRoutine.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementImageD1Ev[__ZThn112_N17PaintElementImageD1Ev]+0x0): multiple definition of `PaintElementImage::~PaintElementImage()'
jucer_ObjectTypes.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementImageD1Ev[__ZThn120_N17PaintElementImageD1Ev]+0x0): first defined here
jucer_PaintRoutine.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementImageD1Ev[__ZThn112_N17PaintElementImageD1Ev]+0x0): multiple definition of `non-virtual thunk to PaintElementImage::~PaintElementImage()'
jucer_ObjectTypes.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementImageD1Ev[__ZThn120_N17PaintElementImageD1Ev]+0x0): first defined here
jucer_PaintRoutine.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementImageD1Ev[__ZThn112_N17PaintElementImageD1Ev]+0x0): multiple definition of `non-virtual thunk to PaintElementImage::~PaintElementImage()'
jucer_ObjectTypes.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementImageD1Ev[__ZThn120_N17PaintElementImageD1Ev]+0x0): first defined here
jucer_PaintRoutine.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementImageD0Ev[__ZThn112_N17PaintElementImageD0Ev]+0x0): multiple definition of `PaintElementImage::~PaintElementImage()'
jucer_ObjectTypes.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementImageD0Ev[__ZThn120_N17PaintElementImageD0Ev]+0x0): first defined here
jucer_PaintRoutine.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementImageD0Ev[__ZThn112_N17PaintElementImageD0Ev]+0x0): multiple definition of `non-virtual thunk to PaintElementImage::~PaintElementImage()'
jucer_ObjectTypes.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementImageD0Ev[__ZThn120_N17PaintElementImageD0Ev]+0x0): first defined here
jucer_PaintRoutine.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementImageD0Ev[__ZThn112_N17PaintElementImageD0Ev]+0x0): multiple definition of `non-virtual thunk to PaintElementImage::~PaintElementImage()'
jucer_ObjectTypes.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementImageD0Ev[__ZThn120_N17PaintElementImageD0Ev]+0x0): first defined here
jucer_PaintRoutine.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementGroupD1Ev[__ZThn112_N17PaintElementGroupD1Ev]+0x0): multiple definition of `PaintElementGroup::~PaintElementGroup()'
jucer_ObjectTypes.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementGroupD1Ev[__ZThn120_N17PaintElementGroupD1Ev]+0x0): first defined here
jucer_PaintRoutine.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementGroupD1Ev[__ZThn112_N17PaintElementGroupD1Ev]+0x0): multiple definition of `non-virtual thunk to PaintElementGroup::~PaintElementGroup()'
jucer_ObjectTypes.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementGroupD1Ev[__ZThn120_N17PaintElementGroupD1Ev]+0x0): first defined here
jucer_PaintRoutine.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementGroupD1Ev[__ZThn112_N17PaintElementGroupD1Ev]+0x0): multiple definition of `non-virtual thunk to PaintElementGroup::~PaintElementGroup()'
jucer_ObjectTypes.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementGroupD1Ev[__ZThn120_N17PaintElementGroupD1Ev]+0x0): first defined here
jucer_PaintRoutine.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementGroupD0Ev[__ZThn112_N17PaintElementGroupD0Ev]+0x0): multiple definition of `PaintElementGroup::~PaintElementGroup()'
jucer_ObjectTypes.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementGroupD0Ev[__ZThn120_N17PaintElementGroupD0Ev]+0x0): first defined here
jucer_PaintRoutine.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementGroupD0Ev[__ZThn112_N17PaintElementGroupD0Ev]+0x0): multiple definition of `non-virtual thunk to PaintElementGroup::~PaintElementGroup()'
jucer_ObjectTypes.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementGroupD0Ev[__ZThn120_N17PaintElementGroupD0Ev]+0x0): first defined here
jucer_PaintRoutine.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementGroupD0Ev[__ZThn112_N17PaintElementGroupD0Ev]+0x0): multiple definition of `non-virtual thunk to PaintElementGroup::~PaintElementGroup()'
jucer_ObjectTypes.cpp.obj (symbol from plugin):(.gnu.linkonce.t._ZN17PaintElementGroupD0Ev[__ZThn120_N17PaintElementGroupD0Ev]+0x0): first defined here

But then it is compiler related and not linked to the CLion exporter…

I would also be interested in knowing where you got your MinGW 64 bits for Windows, because all the ones I downloaded miserably fail to compile anything!

[Jnv]

I am finally able to run my own projects! Fantastic! I have some limitations which I can live with:

• Only 32 bits (64 MinGW doesn’t work fine. Still all ears if anyone has a working version).
• Only Debug mode (Release finds some crazy linking problems about some of my destructors having multiple definitions. But since I build my Release using VS with Jenkins, this is not a problem for me).

I still can’t make the Projucer work (see my post above) though.

So at least I can use Clion under Windows! Thanks!

[t0m]

I think I can explain most of those issues.

We’re missing a WIN32 as an argument to CMake’s add_executable to mark the app as a non-console app. This will stop the console popping up.

There appears to be problem with the WebBrowser component and this might cause the Projucer to exit on startup if you haven’t previously signed in, as signing in requires a browser. If you compile in “GPL mode” by setting JUCER_ENABLE_GPL_MODE to 1 in the Projucer’s AppConfig.h (or sign in using a Projucer built with Visual Studio first) then I suspect you’ll be able to get a bit further.

I can reproduce the errors you see when building Release binaries using a 32 bit compiler, so there’s something amiss with JUCE there.

For projects that don’t use any WebBrowser stuff I can compile 64 bit Debug and Release variants (with a few compiler warnings) using the x86_64-5.3.0-release-posix-seh-rt_v4-rev0 distribution on MinGW.

[t0m]

All of these are now fixed on the develop branch.

There are a few annoying problems with link time optimisation using the compiler bundled with Code::Blocks, most of which can be worked around by restructuring your code to include the body of all your destructors in .cpp files.

[timur]

Greetings from the other side over here at JetBrains!

Really happy to see the CLion support

I just tried to compile the JuceDemoPlugin (VST) out of the box with CLion on macOS and I get the following CMake error:

"/Applications/CLion 2017.3 EAP.app/Contents/bin/cmake/bin/cmake" --build "/Users/timur/JUCE/examples/audio plugin demo/Builds/CLion/cmake-build-debug" --target VST -- -j 4
[ 88%] Built target SHARED_CODE
Scanning dependencies of target VST
[ 94%] Building CXX object CMakeFiles/VST.dir/Users/timur/JUCE/examples/audio_plugin_demo/JuceLibraryCode/include_juce_audio_plugin_client_VST2.cpp.o
[100%] Linking CXX CFBundle shared module JuceDemoPlugin.vst/Contents/MacOS/JuceDemoPlugin
ld: warning: text-based stub file /System/Library/Frameworks//AudioToolbox.framework/AudioToolbox.tbd and library file /System/Library/Frameworks//AudioToolbox.framework/AudioToolbox are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//QuartzCore.framework/QuartzCore.tbd and library file /System/Library/Frameworks//QuartzCore.framework/QuartzCore are out of sync. Falling back to library file for linking.
Copying "JuceDemoPlugin.vst" to "$(HOME)/Library/Audio/Plug-Ins/VST/"
make[3]: cmake: No such file or directory
make[3]: *** [JuceDemoPlugin.vst/Contents/MacOS/JuceDemoPlugin] Error 1
make[3]: *** Deleting file `JuceDemoPlugin.vst/Contents/MacOS/JuceDemoPlugin'
make[2]: *** [CMakeFiles/VST.dir/all] Error 2
make[1]: *** [CMakeFiles/VST.dir/rule] Error 2
make: *** [VST] Error 2

Any clues what’s going wrong?

(the folder~/Library/Audio/Plug-Ins/VST/ obviously does exist on my machine)

[t0m]

Hmm. That’s working fine for me.

What happens if you change $(HOME) to $ENV{HOME} in CMakeLists.txt? At the very least this should print out a more informative path.

[Pwera]

How to enable CLion icon?

[t0m]

As it says in the description:

The exporters which provide the CLion configuration for the corresponding platform are:

- Xcode (MacOSX)
- Linux Makefile
- Code::Blocks (Windows)

Add these exporters to the project to enable CLion builds.

So you need to also add an exporter from that list corresponding to the platform you want to compile on.

@t0m

The CLion exporter can be thought of as a “shell” exporter, where it takes build configurations from other exporters added to the project.

[timur]

Odd, I cannot reproduce this problem anymore. I had to build it once from the command line, so that the .vst is created in the system folder once, and now I can build from within CLion without error. Even if I delete the .vst it will now re-create it (it only failed to do that the first time).

Very strange.

And yeah, now everything works like a charm!