Document source level integration into GDNative C++ plugins

[twaritwaikar]

Currently, the documentation written in README.md mentions that this repository can be added as a submodule and then built into a static library.

It also mentions that this library can then be linked into the GDNative C++ plugins.

However, I have found that sometimes a source-level integration (instead of just a static library that needs to be chucked into the C++ plugin build process) needs to take place between the plugin and godot-cpp. This is required in cases where the plugin is interacting with a custom build of Godot and needs to regenerate the C++ bindings using the custom api.json workflow.

I was able to get such a setup working by adding the following to the plugin's SCons script:

...
opts.Add(BoolVariable("godot_cpp", "Build godot-cpp by forwarding arguments to it.", "no"))
...

# Updates the environment with the option variables.
opts.Update(env)

Export("env")

if env["godot_cpp"]:
	if ARGUMENTS.get("use_custom_api_file", False) and ARGUMENTS.get("custom_api_file", "") != "":
		ARGUMENTS["custom_api_file"] = "../" + ARGUMENTS["custom_api_file"]

	SConscript("godot-cpp/SConstruct")

SConscript("godot-git-plugin/SCsub")

This allowed the calling SCons script to straight away start godot-cpp builds using a custom api.json and then moving on to building the plugin, without going through the process of changing the directory into godot-cpp, running SCons and then changing directory back up one level and then building the plugin.

It would be nice if such a workflow is mentioned in the README because for the longest time godot/godot-git-plugin has been generating custom bindings for testing and that has been done using native shell scripts until it gets updated to use the code I shared above.

[BastiaanOlij]

I've thought about doing so before as well, chaining building things through vscodes workflow but it showed a great weakness of this approach.

You generally build godot-cpp once and it won't change while you are building your plugin, but scons is not smart enough (currently) to figure out the api.json has changed leaving you with two options:

• only generate the sources once, which means that if you update the api.json and forget to manually reset, you're working against an older version
• always generate the sources by adding generate_bindings=yes to the arguments, but this will result in greatly increasing build times.

That said, those can be footnotes worth adding to the documentation and giving people the option to choose their preferred strategy.

[twaritwaikar]

One clarification that was pointed out to me on Rocket.chat is that this additional option godot_cpp=yes would be completely optional. So if the developer would want to build godot-cpp, they would just add this option in the build command.

Otherwise, they leave it out and only the plugin gets built, by reusing a pre-existing godot-cpp binary.