Open xmamo opened 7 years ago
Same here, same system, Unreal Engine v. 4.14.1, mingw-w64
Same issue as well. It also will not build using Run -> Build seems to be erroring when trying to build the Plugins folder on the CLionSourceCodeAccess files.
Nah, i've removed plugin manually by removing it from cmake file, it is caused by braces at the end of cmake command
Anyone have more specifics on this, i'm at a bit of a loss trying to debug this. (primarily on a mac) I've got latest plugin + Unreal 4.14.1 + bundled cmake and its not giving me grief ... any more details would be much appreciated.
I can get with you on TeamViewer session or something and we can try to fix that if it suits you
I setup CLion and UE4 as specified in the Wiki both using MinGW as well as LLVM's clang. After reading around, I went ahead and replaced all the *.cmake files \ with / which fixed some errors in generating debug symbols and errors in the cmake log.
This is what I am left with when enabling verbose mode on cmake. If you would like, we could do a remote desktop session as PWN1109 suggested as well.
@anastasiak2512 you think you might be able to chime in on this one?
I wish I could help, but I'm not too confortable with C++'s CMake yet.
Just wanted to say that the backslash problem wasn't there in commit cca71db960a371d1847215e898f181164b892503. I saw that you reverted the changes of that commit; I presume this is to avoid replacing escape backslashes on Mac and Linux. As @otks suggested in pull 34, you could solve this problem with #if PLATFORM_WINDOWS
preprocessor directives.
If you need a Windows testing environment, you could set up a virtual machine. You can get Window's ISO from Window's official website right here.
I've got a VM actually setup :) its just a time thing at the moment. I'm trying to find sometime this next week to fix all this however. I have a bunch of other fixes on the mac side to go in.
I've reached out to @anastasiak2512 as well, she's the lovely person from JetBrains that helped get the CMake stuff going on Windows/etc :) So she is the most qualified for fixing it, but I will take a stab at it none the less.
Working with Visual Studio is so frustrating! Can't wait to use CLion instead! Wish I could help more, but I'm not at my work PC right now.
I'll have a look at it next week hopefully.
Any update on this integration? :)
Sorry, but not yet from my side.
Any update on this? Even a workaround to remove DNDEBUG or the braces would be helpful
Hey, I finally found some time for this. Sorry for a delay.
That's not about slashes/backslashes I'm afraid. CMake can correctly convert them where necessary.
Looks like the problem is caused by the "p -g ( ) " generated by CMake (you can find it at the end of the long line in the original report). Maybe some incorrect or crashed path caused that. Since I can't reproduce it, I need all CMake files generated by the plugin (that caused this error) and flags from
Hey, I've recently tried out the plugin and got the same error. I can confirm that the problems are the empty brackets at the end. I've uploaded my generated files to this repo: here
I've also found a kind of hacky way to get one step further. If you set
set(CMAKE_CXX_FLAGS "-g -std=gnu++11\n")
in the cmake file you'll cut out the brackets. Problem is, I'm stuck on the new error that pops up right after:
g++.exe: error: CreateProcess: No such file or directory
@Chartas Could you pls also upload generated flags? Somewhere from
I pushed the whole cmake generated folder. =)
Edit: I think I got something. Definitions.cmake line 295. There is a pair of brackets at the end of GameSavedDir() (kudos to text highlighting) and if i remove them, no more error.
Edit2: Okay, still get errors, just the new one i also get when i use the hacky way.
I believe my generated CMake files are nearly identical to the one from Chartas, but here is my repo in case it helps in any way, flags.cmake only exists in CMakeFiles/TestClionEditorFake.dir/flags.make.
@Koriel Would you mind trying to navigate to the Project/Intermediate/ProjectFiles folder and escaping or removing the brackets in Definitions.cmake? Then reload the cmake file with CLion and see what happens.
The parentheses? If I switch:
-DPIPELINE_STATE_FILE_LOCATION=FPaths::GameSavedDir()
To either one of these:
-DPIPELINE_STATE_FILE_LOCATION=FPaths::GameSavedDir\(\)
-DPIPELINE_STATE_FILE_LOCATION=FPaths::GameSavedDir
I get the following:
with g++.exe: error: CreateProcess: No such file or directory
Yes that's exactly what i meant. Numerous google results state that this error is due to a missing path entry for MinGW but that makes no sense, since other projects and applications seem to work. (I also spent some time installing numerous mingw distributions and restarting my pc. Didn't help.)
Additionally i found that reducing the number of paths included through IncludeDirectories.cmake has an effect on this error. I can't see any pattern but entirely commenting out all includes following line 250 removes the error for me, (Of course that's no proper solution.) But it might be something to look at.
Indeed, that's not correct from the compiler side that () are not escaped in
-DPIPELINE_STATE_FILE_LOCATION=FPaths::GameSavedDir()
It should be either
-DPIPELINE_STATE_FILE_LOCATION=FPaths::GameSavedDir\(\)
or
“-DPIPELINE_STATE_FILE_LOCATION=FPaths::GameSavedDir()"
Since the definitions are parsed and copied to the generated Definitions.cmake as
DefinitionsProcessed.Append(FString::Printf(TEXT("\t-D%s\n"), *Line));
from CLionSourceCodeAccessor.cpp:173
It could make sense to escape (). Still not sure :: is also a valid symbol. And other invalid symbols could also be present in this Line.
Another workaround could be in CLion itself. CLion v2017.1 should handle them correctly on project loading and since it's only a fake target to open project in CLion (so you won't build/run this target), could be a possible solution.
Could you please try private CLion EAP build from here, open your UE4 project in it, and share the error log, generated cmake files and build dir in case the problem is still present?
This file ("remote: error: File Intermediate/Build/Win64/UE4Editor/Development/TestCLion2017/TestCLion2017.h.pch"
) is larger than 800 MB, so I had to remove it, but I have the Build dirs in both the project root's Intermediate directory and the plugin's Intermediate/Build directory.
Error Log: https://gist.github.com/Koriel/326e0d98f38b073716ac5fb877dbeaa6
Repository: here
It appears the issue with () is gone, it just has g++.exe: error: CreateProcess: No such file or directory
. Not sure if this is my configuration, or some underlying thing.
@Chartas Do you have Cygwin installed? There might be a conflict with having both of them in the system PATH and trying to use g++.
@Koriel I had it installed. I now removed it according to this guide and still get the same error we two get after escaping the parentheses. Here my message which is pretty much the same as yours only with a different compiler version and my own paths.
Okay, with the help of my mad python skills i managed to identify the path values that are most likely the reason for the recent error.
Most of the path values in the second to last line look like this:
C:/PROGRA~1/EPICGA~1/4.14/...<SomeMoreFolder>
They're simplified, probably due to the spaces in the path name. (I don't really know why, doesn't matter for now anyway.) Point is, there are a number of paths to whom this does not apply. For example:
C:/Program Files/Epic Games/4.14/Engine/Plugins/MovieScene/MatineeToLevelSequence/Source/LevelSequenceEditor/Private
And as it happens this path does in fact not exist on my machine. The second to last subfolder is named MatineeToLevelSequence
instead of LevelSequenceEditor
.
So I conclude that the path retrival is faulty for windows user. Since they're retrived from the CodeLite project, those are probably already faulty as well. I'm not sure how it might be possible to fix that yet.
So there was already some fixes to handle faulty data in the CodeLite side of things, so what could be done (and its feasible) is that we do directory checks on each line as its added to the config. This actually is a good idea as a whole across all platforms.
Thoughts?
I agree. The problem is, what to do once a faulty path has been found? Also, how do we know that we have all relevant path values included, since CodeLite appears to not be reliable?
It might be possible to use the UBT to generate a cmake file and then parse that one to construct a CLion useable cmake file. But I'm not sure how UBT generates the file and it might suffer from the same base problem.
When I first started on this, they 'talked about it' but it wasnt ready. It was an engine patch, and i wanted to make this accessible to everyone. I'll dig into it tonight a bit to see if it got mainlined. The actual code the generates the CodeLite file however is going to be the same as the other, so it would have the same fundamental flaw.
One idea could be to attempt parsing the generated .vcxproj files. Those are by necessity working and appear to contain all required path values.
So I had looked at parsing the xcode stuff on mac, and the vs stuff on pc but it presented two divergent methods hence sticking with CodeLite, but alas might be a good solution.
If there are bad paths, i could do some sort of searching system that looks through the base UE folder for them sorta thing, if not found doesnt use...
Well sounds like a start. Sooner or later we probably want to find a way to get the path values directly from the engine or something, but for now anyone can include missing values themselves if they require a certain module.
But at least for the mingw users this will have to wait because I hit another sad issue. I used python to filter out any Intermediate, Build and Invalid path values but it still won't compile, throwing the same error as before. Reducing the number of includes however works once a certain point is reached. Apparently there is a command line length limit at 32k symbols... That's the reason the include issue seemed so arbitrary before. The Line just gets cut off and mingw gets a cutoff path value it obviously can't find, leading to the CreateProcess error...
Heh Ricardo had mentioned that as well-- definitely a problem -- when i saw the newer non monolithic build stuff in 4.15 I was wondering if it would cut down on the includes, and make it shorter ... apparently not.
Here's hoping CMake generation gets mainlined soon :)
One last bit for today: The 32k limit is a compiler problem, so obvious solution -> change the compiler:
set(CMAKE_C_COMPILER "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/Bin/cl.exe")
set(CMAKE_CXX_COMPILER "C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/Bin/cl.exe")
Since pretty much everyone has at least visual studio installed while working with ue4 this could be a workaround for most people. I still have problems with CLion finding the includes. But one step at a time.
Edit: In case someone is already sure this cannot work, let me know.
CLion doesn't support cl.exe for now. The work is in progress and it will come into 2017.1 I hope, but until that there will be issues with MSVC usage in CLion.
By the way, thinking more about this right now. CLion uses @ to pass long arguments to the compiler (especially to deal with the long lines correctly). So it should be some internal MinGW problem. Anyway, it's easy to check - Windows allows to increase the max command line length limit. So simply increase it and recheck, if this is internal MinGW problem, this won't help.
It's an internal problem. I haven't found the option to increase the command line length, but this stackoverflow thread and this api documentation for the CreateProcess
function make it quite clear that we're hitting the 32k limit. Also the previously posted log shows g++.exe issung the call to cc1plus.exe which is then throwing the error. So it's not called by CMake and therefore a problem with MinGW.
I'll look if i can find a MinGW option that maybe solves this problem, since other threads on the net suggest that we're obivously not the first with this problem, or submit a bug to the MinGW community.
Edit: Apparently the flag that's supposed to help here is --with-gnu-ld
according to this. Sadly for some reason cmake ignores me specifingy this as CMAKE_CXX_FLAGS
and does not pass it to g++. Any ideas on why this flag doesn't get passed?
Edit2: Okay I think it's not a compiler flag but a build flag for mingw itself. So one would have to build mingw first with the added flag and then test this.
All mingw-builds' builds after that discussion are built with --with-gnu-ld
, but at least g++ 6.2.0 still unwraps arguments to cc1plus.
Edit: seems to be this bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71850
I solved using clang
set(CMAKE_C_COMPILER /usr/bin/clang)
set(CMAKE_CXX_COMPILER /usr/bin/clang++)
(Arch Linux)
switching to clang won't be a solution if it's windows that is the problem (as far as I understood)
Looks like that for Windows the only solution is switching to MSVC, which CLion is going to support this year. You can follow the updates in this here.
CLion 2017.1 is out with initial MSVC support. I tried it but there's an error:
Command line error D8049 : cannot execute 'C:\BuildTools\VC\Tools\MSVC\14.10.24930\bin\HostX86\x86\c1xx.dll': command line is too long to fit in debug record
That's interesting. Thanks for letting us know. Is it the full log available?
Sure, here it is (warning, it's huge). Please let me know if you require any additional info!
@teobaranga At a first glance looks like msvc's issue: https://github.com/fastbuild/fastbuild/issues/105.
We'll investigate further, meanwhile, try limiting the number of incude_directories, if possible
UPDATE: Bug report for CLion: https://youtrack.jetbrains.com/issue/CPP-9026
Guys, the reload of cmake project works just fine after a switch to a new version of clion (using cygwin):
C:\Users\tobol\.CLion2017.1\system\cygwin_cmake\bin\cmake.exe -DCMAKE_BUILD_TYPE=Debug -DCMAKE_LEGACY_CYGWIN_WIN32=0 -G "CodeBlocks - Unix Makefiles" /cygdrive/e/Workspace/C++/dtrepository/project/KinectGames -- The C compiler identification is GNU 5.4.0 -- The CXX compiler identification is GNU 5.4.0 -- Check for working C compiler: c:/cygwin64/bin/gcc.exe -- Check for working C compiler: c:/cygwin64/bin/gcc.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: c:/cygwin64/bin/g++.exe -- Check for working CXX compiler: c:/cygwin64/bin/g++.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done -- Build files have been written to: /cygdrive/e/Workspace/C++/dtrepository/project/KinectGames/cmake-build-debug
but when I actually try to build the project, I'm getting this:
C:\Users\tobol\.CLion2017.1\system\cygwin_cmake\bin\cmake.exe --build E:\Workspace\C++\dtrepository\project\KinectGames\cmake-build-debug --target KinectGamesEditor -- -j 4 /bin/sh: UnrealBuildTool.exe: command not found make[3]: *** [CMakeFiles/KinectGamesEditor.dir/build.make:57: CMakeFiles/KinectGamesEditor] Error 127 make[2]: *** [CMakeFiles/Makefile2:329: CMakeFiles/KinectGamesEditor.dir/all] Error 2 make[1]: *** [CMakeFiles/Makefile2:336: CMakeFiles/KinectGamesEditor.dir/rule] Error 2 make: *** [Makefile:222: KinectGamesEditor] Error 2
any ideas?
EDIT:
Ok, I've solved it by adding export PATH=$PATH:"/cygdrive/C/Program Files/Epic Games/UE_4.14/Engine/Binaries/DotNET/"
into cygwin ... now my builds are successfull
Using
set(CMAKE_CXX_FLAGS "-g -std=gnu++11\n")
and adding
...Engine/Binaries/DotNET/
to my path, I was able to get the project to build successfully. Unfortunately, I can't get it to pickup macros properly, and that seems to break a lot of the code analysis.
Above you can see most of the code looking fine, but
GENERATED_BODY()
is underlined as an error. Additionally, the class, variables, and methods are all underlined as unused, even though CLion will allow me to jump to the definition.
Any suggestions?
Just tried downloading and building the source from Github (rather than through the Epic Launcher) and I was able to avoid needing the cmake flags. Still, I am having the same problem with the macro.
Upon further investigation, it seems that building the source from scratch actually allows the code to work fine, for the most part. The macro still complains, but it doesn't affect the rest of the code, for the most part.
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.