Closed messense closed 1 year ago
I'm afraid this broke no-toolchain cross-compilation using Visual Studio, from an x86_64 Windows host to aarch64-pc-windows-msvc. Things are a bit clunky there in general (the existing support goes through platforms and does not set CMAKE_SYSTEM_PROCESSOR
), but it was working in 1.48.0 (and I'm afraid we hadn't been testing with new crate versions, so we didn't discover this sooner).
(Specifically, the auto-search for CMAKE_C_COMPILER
and CMAKE_CXX_COMPILER
doesn't kick in, even though it works fine for a non-cross-compile MSVS generator build.)
Workaround: set CMAKE_SYSTEM_NAME
to an empty string, which counts as defined for this crate, but unset for CMake itself.
Turns out this also broke cross-compiling to Mac Catalyst targets (*-apple-ios-macabi
), because CMake doesn't like having CMAKE_SYSTEM_NAME
set to "iOS" while compiling against a macOS sysroot. That should probably eventually be fixed in CMake itself, but for now setting CMAKE_SYSTEM_NAME
back to "Darwin" does work, at least for simple libraries. I don't know if you want to put that in this crate, though.
EDIT (months later): here's CMake not deciding what to do about Catalyst, which isn't cmake-rs's fault.
This PR changes
cmake-rs
to fill outCMAKE_SYSTEM_NAME
andCMAKE_SYSTEM_PROCESSOR
basedCARGO_CFG_TARGET_OS
andCARGO_CFG_TARGET_ARCH
when cross compiling whileCMAKE_TOOLCHAIN_FILE
andCMAKE_SYSTEM_NAME
isn't set by user.It's tested on CI using
cross
.Closes #75 Closes #80 Closes #151