Migrate the export scripts from gdscript to C++ via gdextension

[m4gr3d]

This removes the need to enable the plugin before it's usable in the export preset settings.

[BastiaanOlij]

I wish we fixed the enabling of plugin logic, it feels like a dirty workaround :)

That said, I think this logic works much better as a GDExtension anyway. My only "concern" is that it's less accessible, it'll be harder to find contributors who want to work on this. Though that's more an issue for plugins like XR tools than this.

[BastiaanOlij]

This should be handled through the matrix, adding the different variations. Not all platforms support these archs, so this will break on MacOS

[m4gr3d]

All those combinations are only for the android platform (see if: matrix.platform == 'android' below).
This ensures we generate the shared libraries for all supported android architectures prior to running the gradle build.

[BastiaanOlij]

Ah missed that, sorry :) that makes perfect sense!

[BastiaanOlij]

Approving this seeing it makes sense to move forward with this, but I'm still on the fence if we should have an extension per platform.

It makes far more sense to me to have a single extension so that logic is properly shared and not registered multiple times with the IDE especially as vendors adopt each others extensions. We don't need separate plugins to have separate export classes.

[m4gr3d]

Approving this seeing it makes sense to move forward with this, but I'm still on the fence if we should have an extension per platform.

It makes far more sense to me to have a single extension so that logic is properly shared and not registered multiple times with the IDE especially as vendors adopt each others extensions. We don't need separate plugins to have separate export classes.

Unfortunately, so long as each vendor has its own openxr loader, it's not possible to have a single gdextension for all vendors since the loader shared libraries will conflict with each other.

[BastiaanOlij]

Unfortunately, so long as each vendor has its own openxr loader, it's not possible to have a single gdextension for all vendors since the loader shared libraries will conflict with each other.

The GDExtension just contains the editor and extension classes, it doesn't limit having separate folders with the loaders and picking the right loader to install right? Or is there something that prevents us from having multiple editor plugin classes in a single extension library?

I don't see anything in the current source that would prevent us from combining all into a single extension, we still have the separate loader folders for the AARs off course. Or am I missing something?

[m4gr3d]

Unfortunately, so long as each vendor has its own openxr loader, it's not possible to have a single gdextension for all vendors since the loader shared libraries will conflict with each other.

The GDExtension just contains the editor and extension classes, it doesn't limit having separate folders with the loaders and picking the right loader to install right? Or is there something that prevents us from having multiple editor plugin classes in a single extension library?

I don't see anything in the current source that would prevent us from combining all into a single extension, we still have the separate loader folders for the AARs off course. Or am I missing something?

The extension classes have vendor specific header dependencies (example) which prevents them from being easily combined.

The editor plugin classes could be in a single extension library since they don't have dependencies on the loaders, this would require them to be compiled separately from the extension classes however which would defeat the point of having a single extension library.