dotBunny / CLionSourceCodeAccess

A CLion Plugin for Unreal Engine
138 stars 26 forks source link

Unable to open CLion in UE4.20 in Linux #97

Open YashBansod opened 6 years ago

YashBansod commented 6 years ago

I built UE4 from source (Master branch) Then I create a basic c++ project with starter content. I selected my source code editor as CLion.

In File => Refresh Clion Project works fine.

But, when I try File => Open Clion it pops a dialog box saying: Could not open CLion for project /home/uidk4283/Documents/UnrealProjects4.19/MyProject/MyProject.workspace Note: I couldn't fine Clion in Edit=> Project Settings and setting the path of executable for Clion as we used to do for <=UE4.18

To get things working, I manually open CLion and open the UE4 project in it. I set up the compiler as clang in the setting of CLion and reload the CMake project. But, I get error. The last few lines of the error are:

clang: error: no such file or directory: '(' clang: error: no such file or directory: ')' clang: error: no such file or directory: '=' clang: error: no such file or directory: '(' clang: error: no such file or directory: ')' clang: error: no such file or directory: '='

RicardoEPRodrigues commented 6 years ago

Maybe this is related with #91 ?

S-Marais commented 6 years ago

the plugin has only one default path to find CLion /opt/clion/bin/clion.sh If you don't have CLion installed there it won't find it. I wish we could still set the path to CLion ourselves.

Since UE 4.19 CLion plugins is hold directly in the UE repository and its version is 2.0. This repository is holding the 1.07 version (Just a reminder).

S-Marais commented 6 years ago

@YashBansod so to have this working natively you will need to edit /path/to/UE_4.19/Engine/Plugins/Developer/CLionSourceCodeAccess/Source/CLionSourceCodeAccess/PrivateCLionSourceCodeAccessor.cpp and near the bottom of the file for the Linux part change the hard coded path to CLion to you correct CLion path.

For now you will have to change the path each time you update CLion (if you are using the JetBrains Toolbox as I do).

As for the compiler error there is a merge in the Editor that should fix the issue very soon as it's status is Waiting for Merge

btwolfe commented 5 years ago

I'm working with Ubuntu 18.04 and Unreal 4.21.2 and see the same error as the original post. I Tried following the path mentioned by @S-Marais to edit that file but the directory path has a typo and should be /path/to/UE_4.19/Engine/Plugins/Developer/CLionSourceCodeAccess/Source/CLionSourceCodeAccess/Private/CLionSourceCodeAccessor.cpp. Regardless, that cpp code has no hardcoded path so this is no longer the solution. My CLion is installed in /opt/clion-2018.3.4/.

Any other suggestions would be appreciated.

S-Marais commented 5 years ago

As far as I'm concerned the path for CLion is still hardcoded in 4.21. But I've forked the Engine to make quite a few changes to UBT and the CLion plugin and I have it working properly on Linux, Windows and Mac. If you head to this page https://github.com/EpicGames/UnrealEngine/compare/release...S-Marais:release the File Changed tab will give you all the changes I made

RicardoEPRodrigues commented 5 years ago

Hello @btwolfe, following what @S-Marais say, the only path currently searched by Unreal is /opt/clion/bin/clion.sh, if you want to have little trouble create a soft link to have the correct path: ln /opt/clion-2018.3.4 /opt/clion.

Regardless, that cpp code has no hardcoded path so this is no longer the solution.

I just visited the CLionSourceCodeAccessor.cpp in the repo and the path is hardcoded in line 275.

There is already a pull request with corrections pending to be included in the main repo: https://github.com/EpicGames/UnrealEngine/pull/5006 @S-Marais This is your pull request for those changes correct?


On a side note, a pull request for Hot Reloading in Linux is also pending: https://github.com/EpicGames/UnrealEngine/pull/5287

I've been struggling with using UE4 on Linux for some time now, and since 4.20 I think it is starting to become a stable and easy to setup engine. It is only missing some essential pull requests.

btwolfe commented 5 years ago

Ooops, I was looking at the CLionSourceCodeAccessModule.cpp file, which has no hard-coded paths in it. Anyway, I'll just go with the symbolic link ln -s /opt/clion-2018.3.4 /opt/clion for now so I can focus on my code development.

Incidentally @RicardoEPRodrigues , I am struggling with UE4 on Ubuntu 18.04 as well. It's a major PITA. I've tried QTCreator, CodeLite, VSCode, and now CLion to get an IDE that works with Unreal. With the above symlink, I can now get CLion to come up in Unreal from the File->Open CLion option, but now it's complaining that my lnotify setting is too low (7), so had to boost that per https://confluence.jetbrains.com/display/IDEADEV/Inotify+Watches+Limit . To further complicate things, I'm also trying to compile UE4 against ROS2, so it's a nightmare trying to get the IDE to know about the include paths, UE plugins, and external libraries. I realize this if off topic, but I'd love to hear if you have had success with any IDE with UE4 and linux.

S-Marais commented 5 years ago

@RicardoEPRodrigues yes these are mine.

@btwolfe keep in mind the actual CLion plugin in UE does not clear the CMakeLists.txt as it use to prior its merge in UE. The version I've PR puts a lot more effort directly in UBT to compute out a much cleaner and a much more usable file to manage our projects

btwolfe commented 5 years ago

@S-Marais Are you saying the UE4 File->Refresh CLion project command in UE4 is insufficient to update the CMakeLists.txt file? Don't know if this is related but CLion is unable to Intellisense ("file not found" when hovering mouse over problematic includes in code) any Engine includes nor any include that is from my UE4 plugins that are part of my project.

S-Marais commented 5 years ago

@btwolfe Not exactly it will refresh the CMakeLists.txt but it will populate it with ALL the files from UE too. If you edit the file yourself, each time you will refresh your project it will erase any of your changes

btwolfe commented 5 years ago

That might explain why it's compiling 436 cpp files with a build (taking forever). So those changes you mentioned in your release fix this so it only compiles my project's code?

S-Marais commented 5 years ago

yes it should only compile a few files.

RicardoEPRodrigues commented 5 years ago

To avoid compiling the engine all the time I created Rocket Builds.

TL;DR - Rocket builds are a build of the engine without all the code, basically is a build easy for distribution.

@reapazor has an amazing tutorial to build them, although I think I had to tweak it a bit to work in Linux: https://reapazor.com/2017/08/17/building-a-rocket-build-from-the-unreal-engine-source-code/

I basically compile the engine on time to have a working Engine build, then create a Rocket Build and use it for my daily work. It no longer recompiles the whole engine and is easier to maintain. I also make a copy into an USB not only to prevent accidents, but also to install the same version anywhere I want.

NOTE: Do not create a build and put it publicly online! UE4 is NOT open-source, in that when they grant you access to the code, you cannot distribute it!

btwolfe commented 5 years ago

Having gotten past the whole 436 ccp file compile, I'll try inserting your release changes if I can ever get a successful compile. The compile completes with errors and it appears CLion is confused about standard UE class definitions. It thinks the Unreal AActor class does not define a method GetActorLabel().

In file included from /home/tuser/UnrealProjects/TestLinuxCPP/Plugins/ROSIntegration/Intermediate/Build/Linux/B4D820EA/TestLinuxCPP/Development/ROSIntegration/Module.ROSIntegration.cpp:52:
/home/tuser/UnrealProjects/TestLinuxCPP/Plugins/ROSIntegration/Source/ROSIntegration/Private/TFBroadcastComponent.cpp:96:38: error: no member named 'GetActorLabel' in 'AActor'
                CurrentThisFrameName = GetOwner()->GetActorLabel();

No idea why this is happening. Could it be related to the issue mentioned previously where CLion can not resolve Engine include file references?

btwolfe commented 5 years ago

@S-Marais I tried cloning and building your fork, but I get build errors. Not sure what to make of this.


~/UECLionFork$ sudo make
bash "/home/tuser/UECLionFork/Engine/Build/BatchFiles/Linux/Build.sh" CrashReportClient Linux Shipping  
Fixing inconsistent case in filenames.
Setting up Mono
Building CrashReportClient...
Using 'git status' to determine working set for adaptive non-unity build (/home/tuser/UECLionFork).
Creating makefile for CrashReportClient (no existing makefile)
Performing full C++ include scan (no include cache file)
Building UnrealHeaderTool...
Using 'git status' to determine working set for adaptive non-unity build (/home/tuser/UECLionFork).
Creating makefile for UnrealHeaderTool (no existing makefile)
------- Build details --------
Using toolchain located at '/home/tuser/UECLionFork/Engine/Extras/ThirdPartyNotUE/SDKs/HostLinux/Linux_x64/v12_clang-6.0.1-centos7/x86_64-unknown-linux-gnu'.
Using clang (/home/tuser/UECLionFork/Engine/Extras/ThirdPartyNotUE/SDKs/HostLinux/Linux_x64/v12_clang-6.0.1-centos7/x86_64-unknown-linux-gnu/bin/clang++) version '6.0.1' (string), 6 (major), 0 (minor), 1 (patch)
Using bundled libc++ standard C++ library.
Using lld linker
Using llvm-ar : /home/tuser/UECLionFork/Engine/Extras/ThirdPartyNotUE/SDKs/HostLinux/Linux_x64/v12_clang-6.0.1-centos7/x86_64-unknown-linux-gnu/bin/llvm-ar
Using fast way to relink  circularly dependent libraries (no FixDeps).
------------------------------
Performing 29 actions (6 in parallel)
[1/29] Compile PCH.Core.h
[2/29] Compile PCH.CoreUObject.h
[3/29] Compile BuildSettings.cpp
[4/29] Compile SharedPCH.Core.h
[5/29] Compile Module.UnrealHeaderTool.cpp
[6/29] Link (ld) libUnrealHeaderTool-BuildSettings.so
[7/29] Compile Module.Core.6_of_10.cpp
[8/29] Compile Module.Core.7_of_10.cpp
[9/29] Compile Module.Core.8_of_10.cpp
[10/29] Compile Module.Core.9_of_10.cpp
[11/29] Compile Module.Core.10_of_10.cpp
[12/29] Compile Module.Core.5_of_10.cpp
[13/29] Compile Module.Core.1_of_10.cpp
[14/29] Compile Module.Core.2_of_10.cpp
[15/29] Compile Module.Core.3_of_10.cpp
[16/29] Compile Module.Core.4_of_10.cpp
[17/29] Compile Module.Json.cpp
[18/29] Compile Module.Projects.cpp
[19/29] Compile Module.CoreUObject.5_of_6.cpp
[20/29] Compile Module.CoreUObject.6_of_6.cpp
[21/29] Compile Module.CoreUObject.1_of_6.cpp
[22/29] Compile Module.CoreUObject.2_of_6.cpp
[23/29] Compile Module.CoreUObject.3_of_6.cpp
[24/29] Link (ld) libUnrealHeaderTool-Core.so
[25/29] Compile Module.CoreUObject.4_of_6.cpp
[26/29] Link (ld) libUnrealHeaderTool-Json.so
[27/29] Link (ld) libUnrealHeaderTool-Projects.so
[28/29] Link (ld) libUnrealHeaderTool-CoreUObject.so
[29/29] Link (lld) UnrealHeaderTool
Total build time: 112.78 seconds (Local executor: 110.70 seconds)
Parsing headers for CrashReportClient
  Running UnrealHeaderTool CrashReportClient "/home/tuser/UECLionFork/Engine/Intermediate/Build/Linux/B4D820EA/CrashReportClient/Shipping/CrashReportClient.uhtmanifest" -LogCmds="loginit warning, logexit warning, logdatabase error" -Unattended -WarningsAsErrors -NoEnginePlugins
Refusing to run with the root privileges.
Error: UnrealHeaderTool failed for target 'CrashReportClient' (platform: Linux, module info: /home/tuser/UECLionFork/Engine/Intermediate/Build/Linux/B4D820EA/CrashReportClient/Shipping/CrashReportClient.uhtmanifest, exit code: Canceled (1)).
Makefile:197: recipe for target 'CrashReportClient-Linux-Shipping' failed
make: *** [CrashReportClient-Linux-Shipping] Error 1```
S-Marais commented 5 years ago

you should not sudo the make command for UE

btwolfe commented 5 years ago

My mistake was trying to do it in /opt directly, where permissions are complicated. Recompiling now under my user account. I definitely need a faster machine. Thanks for the support.

btwolfe commented 5 years ago

@S-Marais I got your forked version compiled and running. When opening existing projects, it thinks the UE version doesn't match, so creates a copy; however, it complains about marketplace plugins not being compatible so won't bring up the project copy in the editor. You know a way to force compatibility with a plugin?

btwolfe commented 5 years ago

In lieu of having an answer about plugin migration, I've just gone back to the UE 4.21.2 version of my project that had the marketplace plugin and removed the dependency. This allowed me to create a copy of that project successfully. Upon creating a project with the forked Editor, I did a "Refresh CLion Project" and then "Open CLion". I looked at the new CMakeList.txt file and it is no different than the stock UE4 build. With the "configuration" set to "MyProject|Debug" I compile and, sure enough, it's compiling 436 source files of which only 4 are my source. What am I missing here?

S-Marais commented 5 years ago

sorry I was away for a few days. the CMakeLists.txt should look different. with loads of lines commented out.

btwolfe commented 5 years ago

Since I didn't hear back from you I switched to a different task. Getting back to this, I checked CMakeList.txt file and it definitely has the majority of custom_targets commented out. To make things as simple as possible, I started the forked UEditor and created a new blank c++ project. As normally happens on Ubuntu, switching to a new project shuts down the editor in preparation for bringing it up with the new project. Unfortunately it fails to bring up the new project in UE, ending with an error to the terminal:

[2019.03.07-19.57.00:362][537]LogInit: Tearing down SDL.
tuser@bubbles:~$ 
(process:2631): Gtk-WARNING **: 13:57:06.884: Locale not supported by C library.
    Using the fallback 'C' locale.
Gtk-Message: 13:57:07.021: Failed to load module "canberra-gtk-module"

I did a sudo apt install libcanberra-gtk-module and it shows that it's already installed. Creating the new UE C++ project did bring up CLion. I am able to bring up the forked UEditor manually and load the new project, so not sure what that error is about.

When I open up CLion from within the forked editor, I get the dreaded g++: error trying to exec '/usr/lib/gcc/x86_64-linux-gnu/7/cc1plus': execv: Argument list too long error, even though I've got ulimit -s 65536 ,

S-Marais commented 5 years ago

this is an issue with CLion itself not UE4 or the patch, I don't remember what I changed to get rid of all the errors back in the days (yeah it's been a long journey between me and CLion :p)

RicardoEPRodrigues commented 5 years ago

My honest but tiresome suggestion is to clean it all and start over. I had several issues rising because I didn't correctly cleaned my repo.

2 ways to do it:

The Effective way

Delete the UE4 folder and all that is in it. Download it again, change to the correct branch and start from the beggining.

The Hard way

Clean your repo, and start again.

To clean your repo do:

git reset --hard
git clean -dxf

Either option will remove any modifications you've made, so be careful.

gmgarciam commented 5 years ago

Open up the ClionSourceCodeAccessor.cpp and change the ending to this. Ofcourse, you'll want to replace my name and directories with the ones that match your system. After that recompile the engine. i also made a guide to how to setup Clion with UE4. It's best guide available as of right now. https://answers.unrealengine.com/questions/746602/clion-with-ue419.html


#elif  PLATFORM_MAC

    // Check for EAP
    NSURL* CLionPreviewURL = [[NSWorkspace sharedWorkspace] URLForApplicationWithBundleIdentifier:@"com.jetbrains.CLion-EAP"];
    if (CLionPreviewURL != nullptr)
    {
        return FString([CLionPreviewURL path]);
    }

    // Standard CLion Install
    NSURL* CLionURL = [[NSWorkspace sharedWorkspace] URLForApplicationWithBundleIdentifier:@"com.jetbrains.CLion"];
    if (CLionURL != nullptr)
    {
        return FString([CLionURL path]);
    }

    // Failsafe
    if (FPaths::FileExists(TEXT("/Applications/CLion.app/Contents/MacOS/clion")))
    {
        return TEXT("/Applications/CLion.app/Contents/MacOS/clion");
    }

#else

    // Linux Default Install
    if(FPaths::FileExists(TEXT("/opt/clion/bin/clion.sh")))
    {
        return TEXT("/opt/clion/bin/clion.sh");
    }   
            else (FPaths::FileExists(TEXT("/home/estebagel/clion-2018.3/bin/clion.sh")));
            {
                return TEXT("/home/estebagel/clion-2018.3/bin/clion.sh");

            }

#endif

    // Nothing was found, return nothing as well
    return TEXT("");
}

#undef LOCTEXT_NAMESPACE`
#elif  PLATFORM_MAC

    // Check for EAP
    NSURL* CLionPreviewURL = [[NSWorkspace sharedWorkspace] URLForApplicationWithBundleIdentifier:@"com.jetbrains.CLion-EAP"];
    if (CLionPreviewURL != nullptr)
    {
        return FString([CLionPreviewURL path]);
    }

    // Standard CLion Install
    NSURL* CLionURL = [[NSWorkspace sharedWorkspace] URLForApplicationWithBundleIdentifier:@"com.jetbrains.CLion"];
    if (CLionURL != nullptr)
    {
        return FString([CLionURL path]);
    }

    // Failsafe
    if (FPaths::FileExists(TEXT("/Applications/CLion.app/Contents/MacOS/clion")))
    {
        return TEXT("/Applications/CLion.app/Contents/MacOS/clion");
    }

#else

    // Linux Default Install
    if(FPaths::FileExists(TEXT("/opt/clion/bin/clion.sh")))
    {
        return TEXT("/opt/clion/bin/clion.sh");
    }   
            else (FPaths::FileExists(TEXT("/home/estebagel/clion-2018.3/bin/clion.sh")));
            {
                return TEXT("/home/estebagel/clion-2018.3/bin/clion.sh");

            }

#endif

    // Nothing was found, return nothing as well
    return TEXT("");
}

#undef LOCTEXT_NAMESPACE