Built-in GDNative compilation

[raymoo]

It would be cool if there was a way to have GDNative module source code be part of the project itself, and be recompiled on change and have export templates handle compilation.

To support multiple languages it would need to be extensible in a way that users could add support for different toolchains. Or Godot could just support specific language like C or C++. Recompilation of GDNative modules should probably be configured as a user setting rather than a project setting, because a user might not have the tools necessary to compile someone's project.

If #11068 is implemented, maybe its implementation could be shared with support for integrating C modules.

[Zylann]

There is a big problem if you do this in C and C++, because these aren't always that simple to compile. They take a lot of time, need #defines, config varies across platforms, some dependencies could be needed etc... and you would need to either ship a compiler with Godot require a compiler to be present on your desktop or even be able to choose one... well, all that could be delegated to a build system, whatever it is, and just tell Godot to execute a command, IF you do want this to even happen (also note devs could also want debug and release versions).
If I were to provide GDNative libs to people, I would ship the source AND precompiled libs as much as I can, which is less hassle as long as they work (and #11068 is already pretty tricky).

[ghost]

the problem I see with this is GDNative can link with external C++ objects so it means it would need a compiler that has full C++ libraries/support so it would end up something like c ompiler 200 mb + 30 mb godot engine. Also different platforms need different assembly objects to link to. You would essentially turn Godot into C++ compiler AND an engine.

My suggestion was to include a specific compiler that only produces GDNative specific code without having to link to external C++ objects. This means you could trim the compiler down to only what GDNative libraries/assembly objects that it needs to produce gdnative and only the platforms that godot also supports so the final built in C compiler would be I dunno 3 MB in size and would not be able to compile any C code but only specific gdscript/visual script into gdnative objects and only for the platforms that godot supports.

Certain games or software use custom tailored tiny C compilers to produce custom C binary code. For ex i think Quake 3 produces specific module bytecode using LCC which is run on a kind of virtual machine . this is very similar to GDNative. It's purpose is not to compile C++ generic code but to produce really specific C binaries. I think parallels uses LCC as well . Doing it this way means you would only produce a very limited type of output. In the case of GDNative you would only use Godot library and math and whatever else it uses and all other linking objects can be discarded. This method not only produces a small compiler but also a compiler that only needs updating when gdnative changes but this compiler would never be able to compile generic c++ .

[Xrayez]

Originally posted by @vnen in #19079 (comment)

The only thing Godot should add is the functionality to call a build command that you define, so you can compile before playing the project automatically. But it would be up to you to set up a build system and edit your code elsewhere.

External build hooks are possible to implement since #15489 and got this to work as proof-of-concept as a GDScript main-screen editor plugin:

func build():
	var pid = OS.get_process_id()

	var err = FAILED
	var output = []

	if OS.has_feature('Windows'):
		OS.execute('cmd', ['/C', 'cd .. && vcvars64.bat && scons platform=windows'], true, output)

	if not output.empty():
		var output_str = output[0]
		build_panel.get_node('build_log').text += output_str
		if output_str.find("done building targets") != -1:
			err = OK

	if err == FAILED:
		print("ERROR: Failed to build GDNative modules.")
	else:
		print("SUCCESS: done building.")

	return err == OK

There are a number of issues I've experienced with this:

• difficult interaction between external commands issued;
• freezes the editor before running the project every time the game is run;
• if OS.execute is run in thread, there's no way (?) to get the build output/return value to check if the build has succeeded before running the project.
• GDNative/Godot libraries are locked for writing when attempting to link objects:
  • might be a Windows issue...

I'm crazy and also would like to recompile Godot executable itself from within Godot editor, that was actually possible when I used to compile Godot from within Windows Subsystem for Linux (WSL), somehow it managed to bypass Windows' write locks. Godot would still needed to be restarted if changes were made to the editor itself, but as the editor runs a separate executable on running the project, that's not an issue.

[Calinou]

I'm crazy and also would like to recompile Godot executable itself from within Godot editor, that was actually possible when I used to compile Godot from within Windows Subsystem for Linux (WSL), somehow it managed to bypass Windows' write locks.

You could try building a new editor executable with a different name, close and remove the old one, then start the new one. This is similar to what software updaters do on Windows.

[Calinou]

Closing in favor of godotengine/godot-proposals#119 and godotengine/godot-proposals#573, as feature proposals are now tracked in the Godot proposals repository.