Document intended scope for GDExtension: What is expected to be accessible to GDExtension developers?

[tarragonfly]

Your Godot version:
4.1

Issue description:

Make GDExtension documentation accessible to 3rd party developers looking to integrate their tools, SDKs, etc into Godot. This means clear information on export platform support (any special considerations for mobile or web?), and clear information on where exactly GDExtension does not go as deep as engine modules. In this case, AnimationPlayer is the relevant discussion point. It's accessible via engine module route, but can it also be extended via GDExtension? A 3rd party software developer that supports a couple dozen integrations for various engines and frameworks doesn't have the time to tinker and experiment. This is where ideally docs would come in and bridge the knowledge gap. Since the docs mention engine modules having deeper engine integration, it gets chosen by default, which is not ideal.

URL to the documentation page (if already existing):

https://docs.godotengine.org/en/stable/tutorials/scripting/gdextension/what_is_gdextension.html

[dsnopek]

Thanks! I agree that GDExtension could use lots more documentation :-)

To address some specific points:

clear information on where exactly GDExtension does not go as deep as engine modules

The goal of GDExtension and godot-cpp is that you should be able to write C++ code that looks just like module code (and with some #ifdefs even be able to compile as a module or GDExtension), however, there are still some missing pieces. Those pieces aren't missing on purpose, they just haven't been done yet, and we may not even realize it (it's hard to notice things that aren't there ;-)).

So, rather than trying to document the missing pieces, I'd personally prefer if folks opened issues when they encounter something that's possible from a module that isn't possible in a GDExtension, so we can start the discussion around how to expose that functionality to GDExtension.

I guess this too should be put in the documentation :-)

In this case, AnimationPlayer is the relevant discussion point. It's accessible via engine module route, but can it also be extended via GDExtension?

Yes!

Since the docs mention engine modules having deeper engine integration, it gets chosen by default, which is not ideal.

Well, since you should be able to write the source code such that it can be compiled either as a module or GDExtension (there's an example of this in Godot itself: the core 'text_server_adv' module can optionally be compiled as a GDExtension), you could start by attempting to make it as GDExtension, but if you hit roadblock, open some issues and switch to compiling as a module until those issues are resolved? This way you're still able to get work done, and GDExtension becomes more capable at the same time.

[tarragonfly]

Thanks! I agree that GDExtension could use lots more documentation :-)

To address some specific points:

clear information on where exactly GDExtension does not go as deep as engine modules

The goal of GDExtension and godot-cpp is that you should be able to write C++ code that looks just like module code (and with some #ifdefs even be able to compile as a module or GDExtension), however, there are still some missing pieces. Those pieces aren't missing on purpose, they just haven't been done yet, and we may not even realize it (it's hard to notice things that aren't there ;-)).

So, rather than trying to document the missing pieces, I'd personally prefer if folks opened issues when they encounter something that's possible from a module that isn't possible in a GDExtension, so we can start the discussion around how to expose that functionality to GDExtension.

I guess this too should be put in the documentation :-)

In this case, AnimationPlayer is the relevant discussion point. It's accessible via engine module route, but can it also be extended via GDExtension?

Yes!

Since the docs mention engine modules having deeper engine integration, it gets chosen by default, which is not ideal.

Well, since you should be able to write the source code such that it can be compiled either as a module or GDExtension (there's an example of this in Godot itself: the core 'text_server_adv' module can optionally be compiled as a GDExtension), you could start by attempting to make it as GDExtension, but if you hit roadblock, open some issues and switch to compiling as a module until those issues are resolved? This way you're still able to get work done, and GDExtension becomes more capable at the same time.

Excellent, that pretty much clarified all the confusion I had about GDExtension's capabilities and scope.

[tarragonfly]

Can anyone clarify what platforms are actually supported by GDExtension? The docs page for GDExtension doesn't mention platforms at all. Is it correct to assume that GDExtension is included in the default export templates of all available Godot platforms?

[AThousandShips]

GDExtension isn't "included" in any sense, it's a core feature and available where it can be compiled, which I think is everywhere though Web might have issues unsure

[dsnopek]

Starting with 4.2, web should be working as well (although, it does require enabling the "Extension Support" export setting). So, yes, as far as I know, all the default export platform should support GDExtension.

[tarragonfly]

GDExtension isn't "included" in any sense, it's a core feature and available where it can be compiled, which I think is everywhere though Web might have issues unsure

It's included in the core, but this one platform is not actually supported right now and/or conditions apply is precisely the information docs should communicate.

When 3rd party software vendors want to integrate something, this is vital information.

[AThousandShips]

The fact that it's available in all builds shouldn't have to be communicated, and all platforms support it, so what information is lacking?

There's even information available on this here which is part of the documentation that you'd read if you're interested in a particular platform