The issue occurred because during the 'close' event, the logic was trying to terminate the native engine on the UI thread instead of doing on the render thread.
The presence of those abis cause them to be included in the set of `p_features` passed to the `gdextension_export_plugin#_export_file(...)` method, which caused them to be lumped in the `features_wo_arch` set.
When trying to find the gdextension library path, we use a predicate with the following logic:
```
[features_wo_arch, arch_tag](String p_feature) { return features_wo_arch.has(p_feature) || (p_feature == arch_tag); }
```
For a `gdextension` config file like the one below, this causes the first android entry (`android.armeabi-v7a = ...`) to always be returned regardless of archs since it always satisfies the predicate.
```
[configuration]
entry_symbol = "example_library_init"
compatibility_minimum = 4.1
[libraries]
linux.x86_64 = "res://libgdexample.so"
android.armeabi-v7a = "res://libgdexample.android.template_release.armeabi-v7a.so"
android.arm32 = "res://libgdexample.android.template_release.armeabi-v7a.so"
android.x86 = "res://x86/libgdexample.android.template_release.x86.so"
android.x86_32 = "res://x86/libgdexample.android.template_release.x86.so"
android.x86_64 = "res://libgdexample.android.template_release.x86_64.so"
android.arm64-v8a = "res://libgdexample.android.template_release.arm64-v8a.so"
android.arm64 = "res://libgdexample.android.template_release.arm64-v8a.so"
```
- Provide api to retrieve the running Godot instance from a GodotHost
- Provide api for the GodotHost to register runtime GodotPlugin instances
- Hide the GodotService class until it's completed
- Include project setting to enable long press for Android devices
- Include project setting to enable pan and scale gestures on Android devices
This allows to include script_instance.h directly in the
generated gdvirtual.gen.inc, and remove excessive includes
from the codebase.
This should also allow Resource to use GDVIRTUAL macros,
which wasn't possible previously due to a circular dependency.
When a hardware keyboard is connected, all key events come through so we can route them directly to the engine.
This is not the case for soft keyboards, for which the current logic was designed as it requires extra processing.
Upon investigating the extremely slow MSVC build times in #80513, I noticed
that while Godot policy is to never use exceptions, we weren't enforcing it
with compiler flags, and thus still included exception handling code and
stack unwinding.
This is wasteful on multiple aspects:
- Binary size: Around 20% binary size reduction with exceptions disabled
for both MSVC and GCC binaries.
- Compile time:
* More than 50% build time reduction with MSVC.
* 10% to 25% build time reduction with GCC + LTO.
- Performance: Possibly, needs to be benchmarked.
Since users may want to re-enable exceptions in their own thirdparty code
or the libraries they compile with Godot, this behavior can be toggled with
the `disable_exceptions` SCons option, which defaults to true.
