generate compat
generate compat
Update ci.yml
Update binding_generator.py
generate compat
generate compat
lint python files
Update compat_generator.py
update docs
Update binding_generator.py
Update module_converter.py
also collect defines
Add module converter file that converts module based projects to godot_compat
Update ci.yml
update docs
Update compat_generator.py
lint python files
generate compat
generate compat
generate compat
generate compat
Update ci.yml
fix path issue when caling from outside
Update binding_generator.py
update to also take missing classes/structs
Update binding_generator.py
Generate godot compat for dual build
generate compat
generate compat
Update ci.yml
Update binding_generator.py
generate compat
generate compat
lint python files
Update compat_generator.py
update docs
Update binding_generator.py
Update module_converter.py
also collect defines
Add module converter file that converts module based projects to godot_compat
Update ci.yml
update docs
Update compat_generator.py
lint python files
generate compat
generate compat
generate compat
generate compat
Update ci.yml
fix path issue when caling from outside
Add support for build profiles.
Allow enabling or disabling specific classes (which will not be built).
Allow forwarding from `ClassDB` to `ClassDBSingleton` to support enumerations
update to also take missing classes/structs
Update binding_generator.py
update
update naming of files
add godot mappings.
update and run output_header_mapping.json
Update README.md
make godot_compat work without a file generated
fix the test
Update binding_generator.py
Update binding_generator.py
Update binding_generator.py
use files from include too
Update README.md
lint
lint
lint
Update CMakeLists.txt
update to use all. fix linting a bit
update wip
fix posix path
Update CMakeLists.txt
Update binding_generator.py
add using namespace godot; everywhere to includes
fix includes
Try fixes.
generate new include files 123
Update binding_generator.py
Update binding_generator.py
Update binding_generator.py
Update binding_generator.py
update
fix GODOT_MODULE_COMPAT
fix manual includes to match.
Update godot.hpp
Update color_names.inc.hpp
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).
(cherry picked from commit 78498da7c3)
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
(cherry picked from commit 07704f8f48)
This is just a single step, re-arranging the code without actually changing its functionality.
new docs/cmake.md
moved the block of comments from the start of the CMakeLists.txt into the cmake.md file and converted content to markdown.
new cmake/godotcpp.cmake
Moved all exposed options into a new function godotcpp_options()
Moved configuration and generation code into godotcpp_generate()
To get all the options into the godotcpp_options() I changed the logic of GODOT_USE_HOT_RELOAD which I believe is a closer match to scons, that if the options is not set, and the build type is not release, then it defaults to ON.
I msvc builds require the default flags to be modified or it will throw errors. I have added the links to articles in the commit, but its about removing the runtime error checks /RTC1 from the CMAKE_CXX_FLAGS_DEBUG variable. This needs to happen before the files are included.
https://stackoverflow.com/questions/74426638/how-to-remove-rtc1-from-specific-target-or-file-in-cmakehttps://discourse.cmake.org/t/how-do-i-remove-compile-options-from-target/5965
Renamed GodotCompilerWarnings.cmake to common_compiler_flags.cmake to match scons
Included files explicitly by path, as we dont need to append to the CMAKE_MODULES_PATH which effects the whole build tree.
This prevents consumers of the library from clobbering the names of the cmake include files and breaking the build.
(cherry picked from commit 2402a044eb)
changed cache type for api file and api dir to FILEPATH and PATH respectively.
Minor whitespace.
docstring parity
(cherry picked from commit 390a9a5590)
This should make all symbols that are not marked otherwise have hidden
visibility. There still may be exposed symbols if marked with respective
attributes.
(cherry picked from commit d18fa929fb)
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 f36acd8e31)
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 4829199081)
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.