Updating to Godot 4.0 GDNative API for a first-party plugin

[twaritwaikar]

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?

[Zylann]

We'll need to implement StringName to the core types, basically. As well as Vector2i and Vector3i, all things Godot 4 is introducing. And it might not stop there, given the proposals in https://github.com/godotengine/godot/issues/35467. Sounds quite soon for a plugin to update while Godot 4 is not even in alpha, I don't know when it's best to start working on that in the C++ bindings, or which form it will take until the next GDNative API will be sorted out (build option? or new branch? Stuff is still worked on in 3.2 so I fear it would double work maintaining two at the same time so early).

Personally I plan to switch my development efforts to Godot 4.0 at least when it hits alpha (on bindings and my own projects).

[twaritwaikar]

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

[BastiaanOlij]

We started on godot_headers already and need to do the same thing here, we'll need to update the 3.2 branch to be up to date for 3.2 and then bring the master branch in line with Godot 4. That means the master branch will only work with Godot 4, there is no way to add backwards compatibility here and there should be checks when the library starts for this. My take on this for godot_headers is that we update all the struct versions to 4.0

We didn't follow through with actually updating godot_headers master to 4.0 yet, we'll soon need to do that (also required to start adding VR support into Godot 4). Once we throw this switch it's going to confuse a hell of a lot of people who will keep using master and wonder why things break.

[twaritwaikar]

@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?

[BastiaanOlij]

@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.

[erictuvesson]

Might be a little bit out of topic, but is there a reason why this is not built as a module with the engine?

[Calinou]

@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.

[erictuvesson]

@Calinou I am more thinking of the C++ Bindings, for example like how mono is built as a module with the engine.

[LennyPhoenix]

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. (But I might also be completely wrong here :P)

[Xrayez]

Might be a little bit out of topic, but is there a reason why this is not built as a module with the engine?

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 EditorVCSInterface API and editor), so you might see the v1.0 version of the Git plugin somewhere after Godot 3.4 release, unless core developers decide to backport git-plugin v2.0 functionality to Godot 3.x eventually.

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.

Git takes over other VCS providers according to recent statistics, and the majority of those who use Godot likely use Git over Subversion.