improve architecture detection for cross-compilation

[foxandfeature]

While working on cross-compilation setups, I ran into a few cases where godot_arch_name() fails to detect the intended target architecture because CMAKE_SYSTEM_PROCESSOR is host instead of the target.

This shows up in a couple of fairly common scenarios:

• MSVC cross-compilation: when using Visual Studio generators, CMAKE_SYSTEM_PROCESSOR isn’t set, but CMAKE_VS_PLATFORM_NAME reliably reflects the selected target (Win32, x64, ARM64)
• GCC multilib (-m32): building 32-bit binaries on an x86_64 host keeps CMAKE_SYSTEM_PROCESSOR at x86_64
• ARM Linux toolchains (e.g. gcc-arm-linux-gnueabihf): some toolchains set CMAKE_SYSTEM_PROCESSOR to the generic arm, which previously didn’t match any known aliases and caused detection to fail

I’m not entirely sure whether all of this should live here or whether some of it would be better handled by toolchain files (especially setting CMAKE_SYSTEM_PROCESSOR correctly). Also, Linux ARM32 and x86_32, as well as Windows x86_32, are probably not heavily used targets anymore.

[enetheru]

Yeah the documentation clearly states that CMAKE_SYSTEM_PROCESSOR is for the target architecture and is supposed to be set by the toolchain, but, nobody's perfect hey. So I'm happy to take some special cases if they can be very tightly constrained.

the msvc stuff I'm good with, the rules around that appear to be clear, even if they aren't the best at playing nice with cmake, needing some special flag for themselves.

But the -m32 flag is not exclusive to gcc as an x86 flag, so it cannot be relied upon to select architecture without additional information.

[foxandfeature]

Thanks for the feedback!
Is it acceptable to use a check like
if (CMAKE_C_COMPILER_ID STREQUAL "GNU" OR CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
or should the GNU-specific part be removed entirely?

[enetheru]

Even guarding it with GNU is not enough, you'd have to have some check for x86 too,
Something like if gnu and x86 and -m32 then ...

I'll approve either direction, appropriate guard, or removal of the GNU stuff. you can always remove it and submit a new pr later when/if you find the solution.

[enetheru]

lgtm. just needs to be squashed before it can be merged.
Cheers.

I appreciate the submission.

[foxandfeature]

Great, thanks! I’ll squash it. After thinking it over, I agree the m32 part would get messy quickly and is really something the toolchain should handle.