Why CLion doesn't support UE4 out-of-the-box?

Answered

I have a CLion license for my weekdays job and I also want to make use of it for my new hobby, development for UE4. Why C++ oriented IDE doesn't support C++ programming-oriented engine and you add C++ support in C# oriented IDE instead? DotBunny's plugin for "source control access" in UE does the job but not ideally. It creates CMakeLists.txt for CLion but after very long process of indexing it still shows errors. In my case, it can't find a definition for ***_API macro that adds dll export specificators to classes and functions and show a bunch of unrelated errors because of that fact. I don't want to buy a license for my new (maybe not too long-living) hobby. I get used to use CLion and my custom keybindings and the way it works and don't want to switch to another IDE

6 comments
Comment actions Permalink
Official comment

Hello,

Thank you for your question.

CLion is indeed our main offer for C++ development, including cross-platform C++, embedded, and other areas. However, the modern development world is multi-language. And it's often not about one specific programming language but about the technological stack used on the project. While CLion is focused on the general native cross-platform stack, Rider is a popular Game Dev IDE in the Unity world (and it also supports Godot). And since many game dev studios are doing both Unity and UE, it's logical to have Rider as our main Game Development offer, so we brought C++ and specific UE support to it. We were also explaining it here in the blog post.

If you can successfully create a CMake project with the Source Control Access plugin contributed into UE, then you can open it in CLion and use it. However, we know that the CMake generated there is far from being optimal in terms of IDE performance. It also relies on fake CMake targets, which makes code resolve tricky for the IDE. In Rider, we added support for .uproject natively, so it's more accurate and works better.

By the way, Rider for UE is for now a free preview. So until the official release, you can use it free, just need to register: https://www.jetbrains.com/lp/rider-unreal/. And the keybindings and other settings can be shared among CLion and Rider. They both are built on the same IntelliJ platform, so the experience will be similar.

Comment actions Permalink

And the keybindings and other settings can be shared among CLion and Rider

Do you mean i need to export settings from CLion and import them into Rider? I did it and nothing changed. Keymaps - weren't been imported, plugins - weren't been imported, look and feel stuff like appearance and color schemes - weren't been imported, and all other stuff I get used to. If I was a rust developer then I had simply just installed a Rust plugin in any of your IDEs, when it comes to the UE, it requires another IDE. That's breaking your words "the modern development world is multi-language" but some IDEs are able to only handle a single language of choice while some others of them can handle a plenty big stack of languages and technologies, why?

 

0
Comment actions Permalink

Why you'd not just extract UE internal stuff into a plugin and allow to use it in CLion. Yes, that would force you to create and maintain a "source code access" plugin for UE but you already did it for Rider you can base a new one on it. Or you could ask DotBunny to provide their rights and source code to you and make it more "optimal" to use, I guess they will not be against it because they use CLion (IMO, why then they did a plugin for it)

0
Comment actions Permalink

IC see several questions, so let me try to answer them:

Do you mean i need to export settings from CLion and import them into Rider? I did it and nothing changed.

How did you do that? We'll try, maybe there is indeed some Rider specific that prevents inporting.

Why you'd not just extract UE internal stuff into a plugin and allow to use it in CLion.

UE functionality consists of several things: .sln support and .uproject support (not easily extractable as plugins), UE language-specific features (implemented on ReSharper C++ language engine, not available in CLion - this might change in the future, but it's a huge task), shaders support (also on top of ReSharper C++ engine, and required for Unity as well, so it will anyway be in Rider, even just for Unity).

BTW, UE also has some C# files (Build.cs) for example, or plugins (written in C#), which makes Rider a good fit.

And overall, we see Rider as an IDE for Game dev. CLion still might get some UE features in the future maybe, but the full support is targeted on Rider.

"source code access" plugin for UE

We have all rights and I was one of the contributors actually. But the problem is that UE project model comes with much secret knowledge. Quite often UE just knows which files go where in the project. The way it generates VS solution partially reflects this knowledge. But creating a nice and optimal CMake seems like a tough challenge. And we don't see much sense in contributing to it as CMake doesn't seem an essential project model supported by Epic Games. Rider can work directly with .uproject and it looks more reasonable.

BTW, DotBunny are using Rider now.

0
Comment actions Permalink

How did you do that? We'll try, maybe there is indeed some Rider specific that prevents inporting.

I did "export settings" with all checkboxes enabled and it had created a .zip file. Then I did "import settings" with that .zip file. It asked me what stuff do I need and all checkboxes had been enabled. Then I found that nothing applied. I did the monkey job and rebind all needed keybinding. There are keybindings that are generic for each IDE like folding things, build project, etc.., no extended/plugin keybindings.

UE language-specific features (implemented on ReSharper C++ language engine, not available in CLion - this might change in the future, but it's a huge task)

I don't know what do you mean by that. Macros like GENERATED_BODY() and these things? I don't think it's a problem for JetBrains programmers at all. Things like in-code editor reflection (I don't know how does it call, I mean inline stuff that shows you how many references on the particular object there're in the editor) are not that important. Very basic support is more than enough I think.

shaders support (also on top of ReSharper C++ engine, and required for Unity as well, so it will anyway be in Rider, even just for Unity).

UE4 has a material editor which is kinda shader graph. I don't know if there is a plain shader development accessed by a regular game developer. If it's so, then it's just new language support that can be taken from the Rider, right?

BTW, UE also has some C# files (Build.cs) for example

Not a big deal. They are just configuration stuff and can be avoided for the first iteration of development (or maybe at all). 

.uproject support (not easily extractable as plugins)

I believe it's hard but don't think it is not possible

I see that CLion needs some major improvements like .sln support (to support MS Visual C++ projects, is there an issue on your youtrack already for that?). You can kill two birds with one stone, add MS Visual C++ support natively and add UE4 support without headache (or with less headache)

 

 

0
Comment actions Permalink

IC UE language-specific support is actually what makes it possible to parse the whole UE reflection mechanism and not just treat it as text (as they are macros). It's the basis of all UE language support and it's a huge work done in ReSharper C++ engine, not easily portable to CLion. The same goes to project model support in IDEs.

Anyway, as I said, we have no plans to bring the full functionality of Rider for UE to CLion, as Rider is our main Game Dev offer. CLion might still get some support for .sln files and some UE syntax later, but that's definitely not our top priority for now.

Support for msbuild in CLion ticket: https://youtrack.jetbrains.com/issue/CPP-17269

On the settings topic: we've just rechecked and you are right, the import doesn't work as Rider uses a completely different set of key bindings and color schemes, it's more oriented on Visual Studio users and is not compatible with the rest of the IntelliJ-platform IDEs. We'll take a look at this problem.

0

Please sign in to leave a comment.