Required since Godot 4.3, which is also the first Godot version with
wide WASM gdnative support (previous versions were Chrome-only, and very
brittle).
Visual Studio projects are multi-config projects like Ninja-MultiConfig which means you can't set the configuration at configure time as there are multiple, it always chooses the first one by default when not specified in the build command.
Instead of this:
cmake -DCMAKE_BUILD_TYPE=Release -G"Visual Studio 17 2022" .
cmake --build . --verbose
It should be this
cmake -G"Visual Studio 17 2022" .
cmake --build . --verbose --config Release
Update ci.yml
Because the current build system doesnt use generator expressions for multi config builds, both the CMAKE_BUILD_TYPE and the build --config options need to be set
This should make all symbols that are not marked otherwise have hidden
visibility. There still may be exposed symbols if marked with respective
attributes.
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.
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.
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.
Thaddeus Crews
David Snopek
Samuel Nicholas
Fabio Alessandrelli
ytnuf
Andreas Pokorny
George L. Albany
Aaron Franke
Raul Santos
Mikael Hermansson
Chris Cranford
bruvzg
Klaim (Joël Lamotte)
Hugo Locurcio