Add support of external godot modules using dll/so

[caffeine-mgn]

Describe the project you are working on

Some 3d game. And try to write some compiler of kotlin like language

Describe the problem or limitation you are having in your project

I want to write some other language for godot. Like godot-kotlin. But I don't want recompile godot.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Load external godot extention modules from dll/so.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Pass control to external dll. This dll can add support of another language (kotlin, rust and other). This dll/so should implement some interface for implement language support

If this enhancement will not be used often, can it be worked around with a few lines of script?

I don't think so. In case when you want to add language you shoud change godot source and build it.

Is there a reason why this should be core and not an add-on in the asset library?

Progam Language support - is a part of godot. We should change godot core.

[Calinou]

This is already supported with GDNative (and GDExtension in 4.0). See also the original GDNative introduction post.

You can also build a dynamically linked C++ module, but this should only be done for development purposes, not for public distribution.

By the way, there are already Godot Kotlin JVM (recommended) and Native bindings being developed.

[caffeine-mgn]

@Calinou Can I add support of javascript (for example) using GDNative? I mean full support: compile to windows, linux, mac

[Calinou]

Can I add support of javascript (for example) using GDNative? I mean full support: compile to windows, linux, mac

Yes, using the ECMAScript module. However, it is not a GDNative binding, so you need to recompile both the editor and export templates with the module included.

Still, I recommend sticking to GDScript or C# whenever possible. The added convenience of using a familiar language may not be worth it due to all the bugs and performance issues you may encounter as a result of relying on a third-party binding. See also the FAQ on this subject.

[caffeine-mgn]

I'm saying that this is not a task for GDScript. Anyone who adds support for their language is forced to build and distribute Godot with their changes. The essence of the feature is for these people to build their libraries and distribute them, not the Godot build.

[caffeine-mgn]

@Calinou ^^^

[Calinou]

Anyone who adds support for their language is forced to build and distribute Godot with their changes.

This is only the case for statically compiled C++ modules, not GDNative add-ons. If the ECMAScript module was built as a GDNative add-on, you wouldn't have to use custom editor and export template binaries. However, this is not the case for the ECMAScript module as the author of the module likely ran into GDNative limitations. GDExtension solves most of those limitations, but it's backwards-incompatible and will have to wait for 4.0.