godotengine / godotengine/godot-cpp
Automatically detecting if GODOTCPP_TARGET is misconfigured (missing)
- Dominant language
- C++
- Stars
- 2.7k
- Forks
- 809
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 8
Description
### Godot version
4.5
### godot-cpp version
4.5 (e83fd0904c13356ed1d4c3d09f8bb9132bdc6b77)
### System information
macOS 15.6 (24G84)
### Issue description
I had a pretty silly mistake in my build configuration as I was not setting `-DGODOTCPP_TARGET=template_release` in release CMake builds. That for some reason made only Mac release game exports crash. Everything else somehow still worked (Windows, Linux, and Mac debugging). It took me about 3 days to track down this "simple" build misconfiguration.
So as it is so, so difficult to debug this problem, I have a suggestion that at least one godot-cpp header could be set up to cause the build to immediately fail if mismatched flags are detected. This is what I used to finally after a long day today manage to track down the problem to be build flags, but I'm not sure if these would be in general the right combination of flags to check:
```c++
#ifdef NDEBUG
#ifdef DEBUG_ENABLED
#error "Invalid configuration of Godot build flags (release incorrect)"
#endif
#else
#ifndef DEBUG_ENABLED
#error "Invalid configuration of Godot build flags (no debug)"
#endif
#endif
```
And interestingly enough I have had this problem in my build flags since like Godot 4.3 but it is only now causing a problem on Mac with Godot 4.5.
### Steps to reproduce
- Build a GDExtesion for Godot 4.5 on Mac with CMake using `-DCMAKE_BUID_TYPE=RelWithDebInfo` (or another non-debug build type)
- Export the project for Mac as a non-debug game
- Run the game and get an immediate crash. The crash callstack *sometimes* had useful info (but often it was totally useless):
```
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libthrive_extension_without_avx.dylib 0x10e62b564 0x10e628000 + 13668
1 libthrive_extension_without_avx.dylib 0x10e66f1a8 0x10e628000 + 291240
2 libthrive_extension_without_avx.dylib 0x10e64cbd4 0x10e628000 + 150484
3 libthrive_extension_without_avx.dylib 0x10e632260 0x10e628000 + 41568
4 Thrive 0x1081bade8 GDExtensionManager::initialize_extensions(GDExtension::InitializationLevel) + 84
5 Thrive 0x1056123b8 Main::setup2(bool) + 15008
6 Thrive 0x105606f94 Main::setup(char const*, int, char**, bool) + 95644
```
That at least hints to where the problem was but I could not see any problems with my method registration nor was I proficient enough in Mac debugging tools to be able to catch the problem (funnily enough I had to work on a different project on Linux before I was able to find this mistake as then I was able to use valgrind to pinpoint the memory allocation problems the mismatched flags caused).
### Minimal reproduction project
Any project with at least one call to `ClassDB::bind_method` should be sufficient to trigger the issue.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.