godot-rust
Fix cross build from macos to msvc
Cross-compiling gdext from macOS to Windows was blowing up because build scripts were pulling macOS bindings at build time. #[cfg(target_os = ...)] runs for the host, not the target, so macOS pthread types slipped into Windows builds and caused size/overflow errors.
The fix is simple: during the build script, detect the target at runtime and load the right prebuilt bindings file for that target. We read Cargo’s CARGO_CFG_TARGET_* env vars, map them to a platform name (windows → windows, macos/ios → macos, everything else → linux), and then load res/gdextension_interface_{platform}.rs directly from gdextension-api using DEP_GDEXTENSION_API_ROOT. That logic lives in prebuilt_platform::load_gdextension_header_rs_for_target(), and write_gdextension_headers() now uses it so gdextension_interface.rs always matches the target.
Why this route? It keeps platform detection in one place, uses Cargo’s standard DEP_* env vars, doesn’t force API changes in gdextension-api, and adds basically no overhead (it reads one file). The trade-off is we need a small companion change in godot4-prebuilt (godot-rust/godot4-prebuilt#1) to expose the crate root, and there’s a bit of file I/O—nothing unusual for builds.
Alternatives we skipped: adding per-platform loader functions to gdextension-api (too invasive, more to maintain) and creating a special build-time variant of godot-bindings (duplication and dependency bloat).
What you can expect: native builds still work, macOS → Windows/MSVC cross-compiles now pass, and custom API modes (api-custom, api-custom-json) are unaffected. This only touches the default “prebuilt” mode. For any non-Windows and non-macOS/iOS target, we default to “linux.” If a platform file is missing, the error message tells you exactly what went wrong.
