Hi folks, I’m trying to figure out whether I should use CLion (free grad school license!), but it seems like all the CLion posts on here are several years old, and maybe CLion projucer integration got abandoned? Just curious to find out what the state of the nation is on this, whether people do it, if so, how they do it, is it worth the setup, etc. At the moment I’m just editing in MacVim and compiling in XCode, so there must be better ways of working than that, haha
It seems that the CMake approach is more and more popular nowadays. I doubt that adding more exporters to the Projucer is onto the top of the JUCE team jobs (correct me if i’m wrong).
Our whole team switched to CLion during the last year and it works great, but we are using it with the native CMake support added to JUCE since version 6, this means no more Projucer but directly creating the projects via plain CMake.
Since CMake is basically designed to do the same as the Projucer – managing cross-platform C++ projects that can be exported to various IDE projects or build systems using the Projucer as a tool to create a CLion specific CMake project just adds an extra layer of complexity that is no longer needed with native CMake support, this is why posts about the CLion exporter are all a bit older.
To get started with a basic plugin or application you don’t need to be a CMake expert, just have a look at the CMake examples to find some starting point that you can tweak to your needs with the information supplied in the CMake API documentation.
Just a +1 for CLion and JUCE (via CMake). We switched all projects to use this setup as soon as it was stable, and we’ve not looked back. We only use Projucer now for small demo projects.
Thanks! haha, yeah Intellij makes good kit. I’m a die hard vim user, with all the muscle memory and macros and so on, and Pycharm was the first IDE I adopted. Especially because the vimulation is actually very good!
For Windows, CLion is slightly more annoying to set up: you need to have Visual Studio installed too to avoid using MinGW as a compiler, and add -G Ninja to the cmake settings, as otherwise builds are too slow.
Other than that I’ve also switched to that for Mac, Windows and Linux, which is really nice because as much as I love Visual Studio, using the same IDE makes my brain adjust better when I have to switch environments.
We also use CLion on Windows and Mac for plugin development and dropped Xcode and VisualStudio.
Just to add a few thoughts: We are also using Ninja on macOS. While we are currently also still using MSVC as installed with VisualStudio for our Windows builds, @vallant made great success using a vanilla llvm based clang toolchain that should not even need a Visual Studio installation anymore to build our plugins. We’ve not yet taken this step, but we will likely do so in near future. This would then mean CMake + CLion + Ninja + Clang on both macOS and Windows, which we expect to be a great thing this will make the differences between the target platform very little.
@PluginPenguin, did you feel a speed boost with Ninja on Mac?
TBH I’m also using it in my CI builds, just because it simplifies having the exact same CMake commands on all platforms, but in my manual benchmarks the default Mac generator (Unix makefiles) was always faster so I preferred it for development.
I never really benchmarked Ninja vs Unix Makefiles speed on macOS, in our largest project which takes more than 10 minutes for a complete build I got the feeling that Ninja was slightly faster, but this is just a feeling tbh. If make is faster then it won’t be a lot. But maybe I’ll do some benchmarking later here as well
Using Ninja also on macOS is more for the sake of using the same environment everywhere as far as possible.
To be fair, you’ll still need the Windows 10 SDK though @eyalamir I think that the speedup will not be really noticeable, i guess that the limiting factor will still be the compiler/linker used… I cannot imagine that xcodebuild or msbuild are that much slower nowadays…
As you said, i also see the main benefit in having a unified build environment.