IDE project configuration for developing Godot GDExtensions using JetBrains Rider

[van800]

Automatically resolves C++ standard libraries. I have tested on Mac and Windows.

[van800]

I see, what you mean. Thank you. It is intended for developers creating an extension that uses godot-cpp NMakePreprocessorDefinitions here is copy-paste from the engine. I will drop it. I will make other changes too, completely forgot about scenarios like compiling gdextension for a different platform and arch. And I will add comments

[dsnopek]

I wonder if this might be better as a community-maintained template for users of Rider?

I don't know if anyone on the GDExtension team uses Rider, and would be able to test PRs for it or maintain it going foward. Whereas a small community of enthusiastic users of Rider could take that on

[van800]

It is up to you to decide if you'd like to incorporate the proposed changes.

https://github.com/user-attachments/assets/12bbf6e1-3a9c-45be-8350-98b685a8ceaf

A bit of me struggling with typing code. But the experience of GDExtension and the game in one place might be very good after all. (GodotEditor should be running all the time)

[van800]

Added a fix for Cpp debugging to work.

[dsnopek]

Discussed at the GDExtension team meeting, and we're a little wary of adding so much code for Rider support. We'd prefer either:

1. Adding something to SCons (in godot-cpp) to generate these files (similar to scons vsproj=true in the Godot project) or a shell script or even docs for how to generate these files. Or,
2. Adding a page to the documentation for developers about how to set this up for themselves (similar to these docs for the Godot project). Or,
3. Adding the minimum files here to make this work (even if it has less functionality)

[van800]

@dsnopek I went with option (3). All files needed for Rider are now in the .sln folder, which is configured to be invisible in vscode. Would this solution fit?

Just a side note. It forced me to do some changes in the Rider Godot integration, so for Rider demo project would be fully recognized by Rider 2025.3, not the current one 2025.2.

[dsnopek]

Thanks! However, I don't think this matches what we had in mind for option nr 3.

This appears to still be the same amount of files and content, just hidden in a dot directory. We aren't worried about the users seeing the files, we're worried about us being able to maintain this going forward, since we don't understand what all of this does or how it was generated in the first place.

The idea behind option nr 3 was to reduce the files and content down to just the bare minimum to make it work. If it was small enough, perhaps we'd be able to understand and maintain it

[van800]

I have removed some auxilary files and macos_debug info, added a readme, describing each of the files in the .sln folder. Does it help to justify the change? @dsnopek

I am afraid, there is nothing else to remove or simplify. I can merge targets and props into gdext.vcxproj, but it would not simplify understanding how msbuild files work.

[paddy-exe]

@van800 The README misses a section that explain how those file have been generated or can be generated on its own. Or could you alternatively elaborate how you did so?

[van800]

Reworked sln-vcxproj mapping again and it became a lot simpler, I am surprised myself.

@paddy-exe The .sln file is created when a new solution is created in VS or Rider and updated with editing solution configurations in VS or Rider. The corresponding part of the .vcxproj, which maps $(Configuration) and $(Platform) to other properties, is typically generated by IDE, though it can be customized manually if needed.

In the video I wanted to point out how switching solution configuration affects the resulting scons call. And then I saw leftovers of previous refactoring and removed them. https://youtu.be/zC5Cy1BZp0Y

[CadeEvs]

Was testing this PR out with 2025.3 EAP4 and running into a couple issues,

1. Trying to build the sln results in a compile error. I've verified python is installed, scons is installed, and my Path environmental variable is setup properly. It is only not recognized within Rider

0>------- Started building project: gdext
scons platform=windows arch=x86_64 target=template_debug dev_build=yes
'scons' is not recognized as an internal or external command,
operable program or batch file.
0>Microsoft.MakeFile.Targets(45,5): Error MSB3073 : The command "scons platform=windows arch=x86_64 target=template_debug dev_build=yes" exited with code 9009.
0>------- Finished building project: gdext. Succeeded: False. Errors: 1. Warnings: 0

2. In example_class.h I'm getting an error at line 10 for GDCLASS. If I run the scons build in cmd it builds fine, so this error is purely visual within Rider

Cannot resolve symbol 'uint32_t'

3. Rider doesn't seem to be helping autocomplete/add the header files for Godot classes

https://github.com/user-attachments/assets/b60dd949-b7d0-4f54-8088-9419030f8391

[van800]

@CadeEvs

1. I have checked - there is some issue with Path on Windows. Not sure how to immediatelly fix.
2. uint32_t might be caused by the missing PlatformToolset - I will check.

[Chkoupinator]

hello @van800

I'm a big fan of Rider and I am considering using it as my main IDE to start working on a game I'm making as a hobby. I noticed this was the way GDExtensions are planned to be supported in 2025.3 so I decided to get the files in your fork of this template to try to use it with my IDE but trying to run it seems to try to run the .sln file itself and causes this error:

I'm on ArchLinux running Rider 2025.3 EAP 5

Edit: I managed to fix this by simply changing the exe path to my the location of godot on my system ( /usr/bin/godot ) I assumed this would be the right thing to do given how we run the project in this video

Edit 2: Running the game from the editor does not seem to trigger breakpoints in the example project's cpp code Adding a Game configuration that does not launch Godot in editor mode fixes it However once a breakpoint is hit even trivial types like String show as "opaque" in the debugger. I assume this is because the pdbs aren't being properly loaded... I think I'll give this a try another day I already spent too much time on this 😅

PS: Could be a bit off topic but attaching the game folder does not seem to make Rider recognize it as a Godot project folder, your Readme is unclear about how we're supposed to enable gdscript support for the demo/game (I renamed everything from demo to game and opening the game folder directly in Rider works)

[van800]

Just fixed

1. Cannot resolve symbol 'uint32_t' on Windows with MSVC
2. scons not found on Windows cc: @CadeEvs

[van800]

@Chkoupinator to debug the game, you'd need not only exe path but also arguments and working directory.

[van800]

@Chkoupinator Regarding opaque presentation in debugger, there are workarounds:

• *nix RIDER-123535
• Windows RIDER-131718

Regarding "Attach Folder" RIDER-131693

[Chkoupinator]

@van800 I had already tried that but it seems the version of python bundled with the lldb plugin of Rider (version 3.8) does not contain the Never type which was introduced to typing in 3.11 as per the logs:

error: module importing failed: Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/chkoupinator/Projekts/Godot/GodotFormatters/godot_formatters/__init__.py", line 18, in <module>
    import godot_formatters.godot_providers
  File "/home/chkoupinator/Projekts/Godot/GodotFormatters/godot_formatters/godot_providers.py", line 19, in <module>
    from typing import Any, Callable, Generic, Never, TypeVar, final, Optional
ImportError: cannot import name 'Never' from 'typing' (/home/chkoupinator/.local/share/JetBrains/Toolbox/apps/rider-2/plugins/cidr-debugger/bin/lldb/linux/x64/lib/python38.zip/typing.py)```