Skip to content

Conversation

@dsnopek
Copy link
Collaborator

@dsnopek dsnopek commented Sep 4, 2024

The (lucky) 13th batch of PR's marked with cherrypick:4.1

Faless and others added 11 commits September 4, 2024 09:58
This is relevant for the Web platform, where builds with and without threads are incompatible. (cherry picked from commit b0296bb)
SUPPORT_LONGJMP have changed since emscripten 3.1.32 to default to "wasm" mode when exceptions are enabled, and "emscripten" mode when disabled. While we generally doesn't use exception in core, linked libraries may need them, and emscripten don't plan to support WASM EH + Emscripten SjLj in the long term. (cherry picked from commit 1bb543b)
This change removes the warnings (unused parameters) coming from code injected by the GDCLASS macro. Contrary to warnings coming from the normal source code which can be suppressed with most compiles by specifying the include directories of this library as external or system, when the code is injected through a macro it is considered in the context of the user, which is the source code of user of the library. That forces the users to modify their code to hide the warnings coming from the mandatory `GDCLASS` here. That's why it's important to remove these warning from that specific macro and ideally any other macro that the user must use. (cherry picked from commit 738859f)
The engine uses the names `int` and `float` to refer to the 64-bit types, so in the bindings generator we have a hardcoded conversion for those types. But this type conversion should not be used for metadata. Even though the underlying type should still be 64-bit for interop, metadata is meant to specify the correct type to expose. So if metadata says `float` it means the type is really meant to be a 32-bit `float` and not `double`. Other hardcoded type conversions (`int` and `Nil`) won't ever be metadata. This change corrects the `float` type, to use the right type in the generated C++ code. Before we were always using `double` due to this type conversion. (cherry picked from commit 4829199)
Was using CPPFLAGS, but should use the explicit scons CCFLAGS which makes it clear they are applied to both the C and C++ compiler. CPPFLAGS was also fine (they are preprocessor flags, also applied to both C and C++), but we should try to stay consistent with what we do in Godot. (cherry picked from commit f36acd8)
As was fixed with godotengine/godot#91208 (cherry picked from commit 7b31f39)
@dsnopek dsnopek merged commit 4d5d707 into godotengine:4.1 Sep 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug This has been identified as a bug enhancement This is an enhancement on the current functionality