Open xmamo opened 7 years ago
Dalai-
commented
7 years ago @shpen where exactly are you adding set(CMAKE_CXX_FLAGS "-g -std=gnu++11\n") and ...Engine/Binaries/DotNET/? Are you using cygwin or mingw? I'm getting the g++.exe: error: (: No such file or directory error and would like to try your fix.
Regarding the macro errors, do you have the Unreal Engine 4 SDK Support plugin installed in CLion?
ghost
commented
7 years ago That would be interesting for me too, i´ve tried setting up the stuff but stucking at this specific point. If i add the set(...) inside the cmakelist i get another issue, but i´ve no clue where to add the /DotNet/ path except in Windows environment and the global bash config of cygwin. None of this worked as expected.
Right now i download the source of the engine and compile it, hopefully you find the time to answer @shpen :-)
shpen
commented
7 years ago @Dalai- I am putting the cmake flags at the top of the CMakeLists.txt. If I rebuild from scratch (github source, rather than just including the source when downloading from the Epic Launcher), then I don't need to set this flag. I am using cygwin, if that matters.
As far as the path for UnrealBuildTool, I unfortunately have not been able to figure out how to configure the path, so I am manually adding the full path in the CMakeLists.txt for the build targets that I use. It's annoying because it gets overwritten, but I haven't figured out a cleaner solution unless @Toby91 can comment.
Unfortunately, despite getting this to work for the most part, I am having serious performance usability issues:
CMakeLists.txt, which requires me to then reapply the full path to the UnrealBuildTool executables.And some other issues I cannot think of off the top of my head. For now I am switching back to VS2015, manually applying all my keybindings and installing Resharper with the hopes of recapturing the Intellij/CLion editor experience, but keeping the usability and stability of VS2015. Really all I need are my shortcuts, color scheme, and some basic code navigation/generation to keep me happy. CLion has all that, but unfortunately I think I will wait for this project to mature a little further before attempting to come back. Sorry if it's not the good news you're hoping for.
anastasiak2512
commented
7 years ago @shpen I'm sorry the experience with CLion was not smooth. Could I kindly ask you for one thing? When there is a freeze in CLion, thread dumps are generated automatically. They are located in the same directory as logs (Help | Show Logs). Could you share them with us, please? We'd like to investigate the freeze. Which CLion version was that btw?
anastasiak2512
commented
7 years ago @shpen thanks!
ghost
commented
7 years ago Good evening,
Something new here? I´m playing a bit with MSVC Beta support and so on but still sitting here with my unsatisfying Visual Studio.
Cheers, Maik
TomCoursow
commented
7 years ago Same here also tried 2017.1 with MSVC Support but also get command line to long :/
anastasiak2512
commented
7 years ago I'm afraid it's a compiler issue and we can't help with it in CLion. The only way could be changing the generated output from the plugin, but I have no proper idea on how to do it.
TomCoursow
commented
7 years ago Sounds like we are doomed? :(
reapazor
commented
7 years ago "There's always hope" :) got it all up in a VM now ....
-- Matthew Davey
On Apr 23, 2017, at 08:50, Tom - Henry Coursow notifications@github.com<mailto:notifications@github.com> wrote:
Sounds like we are doomed? :(
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/dotBunny/CLionSourceCodeAccess/issues/35#issuecomment-296441219, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAGD3IJ7cW8OBpNkgRsE6jlkz_n9v2Fjks5ry0ksgaJpZM4LHwVC.
reapazor
commented
7 years ago So I've gotten past most of the stuff above, im just working out a " g++.exe: error: CreateProcess: No such file or directory" issue :)
reapazor
commented
7 years ago (not giving up on windows :D )
reapazor
commented
7 years ago 
^ Current Setup
reapazor
commented
7 years ago Produces C:\Users\reapazor\AppData\Local\Temp\compiler-file -mtune=generic -march=i686 -std=gnu++11 -fpch-preprocess -g -fworking-directory -dD g++.exe: error: CreateProcess: No such file or directory
Koriel
commented
7 years ago I'm impressed. :D I can redo it later with your configuration and see if I get the same thing. Maybe this is banal, but somewhere it said that could happen if you need to restart after installing for the PATH to take effect (since you installed it in a VM recently?).
reapazor
commented
7 years ago So, yes to the restart :) ... but it presents a more difficult problem after that. I keep hitting the command line character limit on windows.
The compile line it fails on is 160k+ characters long (windows limit is something like <9k).
I'm trying to find a work around :)
Koriel
commented
7 years ago I can't try this yet (maybe tonight), but found a guy who says the 9k limit is a cmd.exe limitation, he tries to solve it by replacing the windows shell with another shell: https://mcuoneclipse.com/2015/03/29/solving-the-8192-character-command-line-limit-on-windows/
reapazor
commented
7 years ago That is a nice find :) I might even play with it soon.
shadd-anderson
commented
7 years ago Any news on this issue lately? I've started developing for Unreal in CLion since JetBrains is LEAGUES better than VS. Hoping it gets worked out soon :)
shadd-anderson
commented
7 years ago So, as mentioned in #53 , uninstalling Unreal and rebuilding from source eliminates this error. h/t to @mhatina.
altairmizuchi
commented
7 years ago Hello, guys. Considering command line length problem for windows. I see that you registered problem for JetBrains but it seems like they knew about it in 2016 and thinks it should be solved by you and not them!
https://blog.jetbrains.com/clion/2016/10/clion-and-ue4/
"As for the CLionSourceCodeAccess plugin, we’ve tested it on macOS. On Windows there is an issue for MinGW and Cygwin toolchains. CLion’s part will be addressed in CLion 2017.1 EAP, but there is still some internal command line length limitation coming from the toolchain. Probably, MSVC support, which we plan for 2017.1, will resolve this as well."
Or have I misunderstood something? https://support.microsoft.com/en-us/help/830473/command-prompt-cmd.-exe-command-line-string-limitation
The solution with parameter file proposed by Microsoft sounds like a good idea.
P.S. I am trying to use MVSC which is supported by CLion now
reapazor
commented
7 years ago @anastasiak2512 that does look like an interesting thing ... but is that more on the clang chain side?
anastasiak2512
commented
7 years ago @reapazor @altairmizuchi The problem is that we do use the response file inside CLion to call the compiler. The problem happens somewhere inside the compiler call and we have no idea for now how to handle the situation( We'll continue the investigation (under CPP-9974)
anastasiak2512
commented
7 years ago @here, could you please try adding the following lines to the CMake settings in CLion:
-DCMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS=1
-DCMAKE_CXX_USE_RESPONSE_FILE_FOR_INCLUDES=1If it helps, I'll contribute to the plugin to generate a proper set command
altairmizuchi
commented
7 years ago @anastasiak2512 I'll check it tomorrow if nobody does it earlier
altairmizuchi
commented
7 years ago 
@anastasiak2512 unfortunately, it has not helped(
anastasiak2512
commented
7 years ago @altairmizuchi That's interesting, doesn't seem the proper parameters are used (you still get a command line error). I'll try to make a set command in CMake scripts with FORCE flag and commit to the plugin. Hopefully, this week. Then we can recheck.
anastasiak2512
commented
7 years ago @altairmizuchi Meanwhile, could you please try Tools | CMake | Reset Cache and Reload?
altairmizuchi
commented
7 years ago @anastasiak2512 clion_output.txt
Cenovis
commented
7 years ago Any news on this issue ? As a big fan of Jetbrains tools I can't wait to find a solution on this issue :)
anastasiak2512
commented
7 years ago @Cenovis Looking at it right now. Sorry for a delay
anastasiak2512
commented
7 years ago First of all, I've sent a pull request to force RESPONSE file usage from CMake: https://github.com/dotBunny/CLionSourceCodeAccess/pull/74/
anastasiak2512
commented
7 years ago @altairmizuchi I see in your log "-DCMAKE_BUILD_TYPE=Debug" and the error is "command line is too long to fit in debug record", so let's try and set Release build type. For that in your CMake settings change configuration to Release. If still fails, attach a fresh CMake output collected after 'Reset Cache and Reload Project'
anastasiak2512
commented
7 years ago @reapazor I would wait for a while and ask users to do some checks before closing this ;)
reapazor
commented
7 years ago Fair :) i merged it in, and it was working ... but true :D Didn't realize merging would close the issue.
anastasiak2512
commented
7 years ago @reapazor My main concern is that @altairmizuchi shows me the log with RESPONSE flags set but the problem still present. However, it might be caused by the Debug configuration. Thus I'd kindly all people here who were reporting the issue do a check and share results.
Iamthecenterofthemultiverse
commented
7 years ago @anastasiak2512 Works for me with release configuration.
Cenovis
commented
7 years ago @anastasiak2512 CLion now detects correctly the UE4 API ! But I'm not able to build my project directly from clion:
C:\msys64\mingw64\bin\cmake.exe --build "C:\Users\Cenovis\Documents\Unreal Projects\ue4-hacknslash\HackAndSlashGame\cmake-build-debug" --target HNSEditor-Development -- -j 2 -- Configuring done -- Generating done -- Build files have been written to: C:/Users/Cenovis/Documents/Unreal Projects/ue4-hacknslash/HackAndSlashGame/cmake-build-debug Compiling game modules for hot reload @progress push 5% @progress 'Generating code...' 0% @progress 'Generating code...' 67% @progress 'Generating code...' 100% @progress pop Target is up to date Total build time: 6.28 seconds (NoActionsToExecute executor: 0.00 seconds) mingw32-make.exe[3]: [CMakeFiles\HNSEditor-Development.dir\build.make:56: CMakeFiles/HNSEditor-Development] Error 2 mingw32-make.exe[2]: [CMakeFiles\Makefile2:104: CMakeFiles/HNSEditor-Development.dir/all] Error 2 mingw32-make.exe[1]: [CMakeFiles\Makefile2:111: CMakeFiles/HNSEditor-Development.dir/rule] Error 2 mingw32-make.exe: [Makefile:130: HNSEditor-Development] Error 2
altairmizuchi
commented
7 years ago Wow! CMD line error disappeared!!! Although I had some missing header error for "target-all" but I have no time to recheck it right now. Thx!
anastasiak2512
commented
7 years ago So I think now the issue could be closed, however, the plugin instruction should be updated. On Windows it is required to use Release configuration (at least for MSVC) - we can't set it from the plugin, it should be configured manually in CLion. We'll think about it more to see if we can make it work with Debug configuration in the future.
anastasiak2512
commented
7 years ago @Cenovis let's clean the installation:
Cenovis
commented
7 years ago @anastasiak2512 Thanks, it worked like a charm 👍 :)
TomCoursow
commented
7 years ago @reapazor @anastasiak2512 Yes with the latest changes and the new Important Wiki Notes for Windows I finally got it working on my Windows Machine after trying it for over a year now 😃 Thank you very much!
Now CLion seems to hang up every 10 seconds for a while but I would also say that this issue task is fixed now as the freeze should not be related to this here right?
anastasiak2512
commented
5 years ago MSVC issue is fixed in Preview 2019!
terrantsh
commented
5 years ago @anastasiak2512 Thank you so much!I have worked out this problem.
When I start up CLion, I get the following error:
I'm on Windows 10 (64 bit). I'm using the latest version of CLionSourceCodeAccess (commit cca71db960a371d1847215e898f181164b892503), the latest version of CLion (build #CL-163.7743.47), and the latest version of Unreal Engine (v. 4.14.0) as I'm writing this.\ I'm using the MinGW toolchain with the bundled CMake and the bundled GDB of CLion. This is a list of all currently installed packages of MinGW (all updated to the latest avaiable version):
mingw-32-binutils(bin);mingw-32-gcc(bin, dev, doc, info, lang, lic, man);mingw-32-gcc-g++(bin, dev, doc, man);mingw-32-gdb(bin, doc, info, lang, lic);mingw-32-libatomic(dll);mingw-32-libgcc(dll);mingw-32-libgmp(dll);mingw-32-libgomp(dll);mingw-32-libiconv(dll);mingw-32-libintl(dll);mingw-32-libmpc(dll);mingw-32-libmpfr(dll);mingw-32-libpthreadgc(dev, dll);mingw-32-libquadmath(dll);mingw-32-libssp(dll);mingw-32-libstdc++(dll);mingw-32-libgz(dll);mingw-32-make(bin, doc, lang, lic);mingw-32-libgcc(dll);mingw-32-mingw-get(bin, gui, lic);mingw-32-mingwrt(dev, dll);mingw-32-w32api(dev).I already tried not to use the bundled CMake and/or the bundled GDB.