CLion IDE support

[svdragster]

Without making the following adjustments, CLion can't find the headers for godot, resulting in unavailable IDE suggestions and annoying red squiggly lines.

I added the following at the bottom of CMakeLists.txt, now the IDE suggestions work correctly. It's not ideal since you have to add all your files to SOURCE_FILES. I hope there is a better way that I'm not aware of.

I'm not sure if and how this should be included in the template. Maybe using a patch?

set(CMAKE_CXX_STANDARD 17)

include_directories(SYSTEM extern/godot-cpp)
include_directories(SYSTEM extern/godot-cpp/gdextension)
include_directories(SYSTEM extern/godot-cpp/include)
include_directories(SYSTEM extern/godot-cpp/gen/include)
include_directories(SYSTEM GDExtensionTemplate-build/extern/godot-cpp/gen/include)
include_directories(SYSTEM GDExtensionTemplate-build/gen)

set(
        SOURCE_FILES
        src/GDExtensionTemplate.cpp
        src/GDExtensionTemplate.h
        src/Example.cpp
        src/Example.h
)

file(GLOB extern/godot-cpp/include
        *.h
        *.cpp
        )

file(GLOB GDExtensionTemplate-build/extern/godot-cpp/gen/include
        *.h
        *.cpp
        )

[asmaloney]

Hmm... (Note: I've never used CLion.)

What you're proposing is "old-style" CMake which is generally not used anymore and just ignores the targets in the rest of the CMake files. "Modern" CMake uses targets which is what I'm using here (see CMake tutorial for an example). For example, setting the godot-cpp includes as SYSTEM is done in godot-cpp itself using target_include_directories and then that target is added to GDExtensionTemplate using target_link_libraries.

BTW: Your GLOBs seem to be incorrect as they are missing a variable and the keyword RELATIVE - so I don't think they are doing what you expect. GLOB is generally considered bad practice anyways (see note in previous link) since CMake can't know if any of those files change (though there is a new CONFIGURE_DEPENDS option which helps with it a bit).

Offhand I can't think of why CLion would have problems with targets as that is what most CMake files use now.

• Are you opening the top-level CMakeLists.txt file?
• Is the correct target active (should be GDExtensionTemplate)?
• Does it compile?

I think we need to figure out why it's not respecting the targets rather than work around them.

For reference, here's what things look like in Qt Creator for me:

[svdragster]

You are right, I only found a dirty workaround until the red stuff went away, which is not the correct solution.

• Are you opening the top-level CMakeLists.txt file?
  Yes, the CMakeLists.txt in the root directory of the repository.
• Is the correct target active (should be GDExtensionTemplate)?
  I'm not sure how I can select a target. In the bottom right of CLion it says this while I have Example.cpp open:
  
• Does it compile?

I did a fresh clone and ran the following commands (as per documentation for "Not MSVC"), all successful:

git submodule update --init --recursive
cmake -B GDExtensionTemplate-build -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=GDExtensionTemplate-install GDExtensionTemplate
cmake --build GDExtensionTemplate-build --parallel -- -j 4 
cmake --install GDExtensionTemplate-build 

My project file tree after the commands

[asmaloney]

That looks like it's set to the correct target.

The fact that it compiles tells me there's a disconnect between the compiler and the thing that's handling what I think CLion calls code insight. I have had similar disconnects with Qt Creator in the past and I think it had to do with the version of clang that Qt Creator included as a language server vs. the compiler I was actually compiling with.

According to this article from CLion:

Now, if you include the header or source file into any project file, CLion will automatically treat it as a project file as well, which means full code insight will work in there!

Not sure if that's the same thing since I don't know their terminology.

Are there any "code insight"/code completion/language server settings that might affect this?

[svdragster]

I had the problem when setting up GDExtensions by myself (before finding your awesome template) and searched for a solution for an hour. I didn't find anything regarding any code insight/completion settings, I only got it working with my workaround above.

For visual studio code a way is to use the Include paths setting in the C++ Extension, but I didn't find a similar setting for CLion (https://youtu.be/MRU1FEDPlf8?t=359):

[kiririn39]

I had added OP's config in the topmost CmakeList file (the one with blue text) but it didnt help in my case as you ca see from screen, although it did manage to compile

UPD:
Nevermind, removed all of that and after first compilation and regeneration of cmake, red squiggles went away!

[asmaloney]

Nevermind, removed all of that and after first compilation and regeneration of cmake, red squiggles went away!

Maybe it's caching the symbol information and compiling forces it to re-index? I know that Qt Creator sometimes takes a long time to index these larger projects.

@svdragster If it's still a problem, I would suggest asking on the CLion forums. It looks to me like godot-cpp and GDExtensionTemplate are following CMake's recommended target style.

@kiririn39 That warning you're getting is unusual - what OS are you compiling on? -arch doesn't seem to be passed explicitly in godot-cpp.

[kiririn39]

@asmaloney I didnt pass any explicitly, i used an ide's compile button since it was available. I'm on arm mac so that is why

[asmaloney]

I wonder where x86 is coming from then. It should be using x86_64 from here to build a universal lib:

set( CMAKE_OSX_ARCHITECTURES "x86_64;arm64" CACHE STRING "" )

[kiririn39]

maybe because i used g++ instead of standard apple-clang?
While g++ has this kind of output:

a-clang's does not raise this warning:

which you were probably expecting. Maybe it's internal name in gcc for x86 or something

[kiririn39]

I'v looked in to it a bit more. Seems like godot-cpp generates or however it gets these actual nodes api binding files, but they went in cmake-build-debug folder. Which is probably not expected?

i tried moving them in appropriate locations. On this sccreen red file names mean the are not listed in git because i copy-pasted them. This is a place i would expect them to be and i guess Clion does so, because after this i could use Cion's intellisense even without prior mentioned actions. Are they supposed to be here?

My guess would be that Clion messes up with some paths? and insted of pasting generated files in extern/godot-cpp they went to export folder? Excuse me if i'm writing strange sentences, i'm not a cmake enjoyer and making a wild guess here)
@svdragster Can you try this for yourself and see if it also fixes your setup.
@asmaloney Since you are using other IDE could you maybe check were your gen files can be found?

[asmaloney]

Those files are in the right place - all generated files belong in the build directory.

(You can see them in my IDE project structure in my comment above.)

If you look at godot-cpp's CMakeLists.txt, they are clearly added to the library.:

add_library(${PROJECT_NAME} STATIC
		${SOURCES}
		${HEADERS}
		${GENERATED_FILES_LIST}
)

and later on they are added to the include directories:

target_include_directories(${PROJECT_NAME} ${GODOT_CPP_SYSTEM_HEADERS_ATTRIBUTE} PUBLIC
	include
	${CMAKE_CURRENT_BINARY_DIR}/gen/include
	${GODOT_GDEXTENSION_DIR}
)

So I don't know why CLion can't find them for code completion, but can for building.

I think the best bet is to ask on the CLion forums.

[Sythelux]

I'm working on a project, based on this repo here:

https://github.com/Sythelux/godot_tree_generator_plugin/tree/feature/godot-4.1-gdextension

i'm coding with CLion and except for CLion not being able to do the includes on its own. it works rather well. Maybe other CLion users can track down what I might've different from this repo. (I had to set the build dir to "." in the settings, because CLion is usually putting stuff in its own cmake build directory.

[asmaloney]

Thanks @Sythelux.

I had to set the build dir to "." in the settings, because CLion is usually putting stuff in its own cmake build directory.

That's what it is supposed to do. With CMake you generally don't build in your project's directory (i.e. the build process doesn't add or modify any files in your project's directory at all). You would have build directories for debug and release outside your project directory.

project/
  CMakeLists.txt
  LICENSE.txt
  src/
  (other project files)
project-debug/
  gen/
  (other build stuff for debug)
project-release/
  gen/
  (other build stuff for release)

Aside: You also shouldn't check in any generated files that are supposed to be in the build directory - e.g. gen/Version.h, addons/zylann.treegen/zylann.treegen.gdextension. These are generated when you run the build. Generated files may be different between builds (debug & release) like the .gdextension file, or between different runs of the build (in the Version.h case, the git hash will be changing all the time). This is one of the reasons the build directories are outside the project directory.

[Sythelux]

Thank you for helping me with my project structure. I didn't want to open up another thing here in the issue tracker though. Just telling, that CLion can work with that project setup.