-
-
Notifications
You must be signed in to change notification settings - Fork 575
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating to Godot 4.0 GDNative API for a first-party plugin #449
Comments
We'll need to implement Personally I plan to switch my development efforts to Godot 4.0 at least when it hits alpha (on bindings and my own projects). |
Seems like there is no quick and dirty way to do this as of now. This would be probably be best done after 4.0 releases if the way to do this is time consuming |
We started on We didn't follow through with actually updating |
@BastiaanOlij For the people using master before 4.0 is released, I think it would be fair to keep the 4.0 branch (of godot-cpp) as not the master branch. Probably master can remain to be 3.2 compatible till 4.0 is released? |
@IronicallySerious yeah that was the opinion I believe expressed on #gdnative as well. Also seeing all the work currently being done on master that is still for 3.2 the current 3.2 branch has become a bit stale and outdated. It makes more sense to have a 4.0 branch here and in godot-headers that follows the godot master while our master branches remain based on the latest 3.2 and we don't switch over until godot 4 is officially released. |
Might be a little bit out of topic, but is there a reason why this is not built as a module with the engine? |
@erictuvesson VCS support was designed to be extensible as we wanted people to be able to use any VCS they like, not just Git. In my experience, some people will always be wary about giving Git a monopoly position. |
@Calinou I am more thinking of the C++ Bindings, for example like how mono is built as a module with the engine. |
I believe it is because having a C API is more consistent and reliable than a C++ API being exposed. This is due to how C is more standardised so it is better if the user compiles the C++ module themselves. This way the module's compiler matches the library and they can interface without any problems. |
FYI, I'm currently working on integrating Git as a built-in VCS provider in Goost (which is basically a custom Godot build with more stuff integrated into the core), see goostengine/goost#98 (still the git-plugin v1.0, because I also kind of depend on the
Git takes over other VCS providers according to recent statistics, and the majority of those who use Godot likely use Git over Subversion. |
The GSoC work on the VCS integration improvement project over at https://github.com/godotengine/godot-git-plugin by janglee is almost complete and works with the 3.2 GDNative API.
However now the GDNative API in Godot 4.0 has changed in its core e.g. StringName has been added to the core, and some API endpoints have started using StringName. This means that our older way of just using the custom api.json from a Godot 4.0 build is not enough to begin testing the plugin on Godot 4.0. The build results in undefined symbol errors (most being for StringName apparently) when just using the custom API.
Is there a way to bypass this or do we have some documentation on how to update godot-cpp on our own to keep testing the plugin in 4.0 before Godot 4.0 is released?
The text was updated successfully, but these errors were encountered: