Don't set CMAKE_SYSTEM_NAME when using the Visual Studio generator #193
Conversation
src/lib.rs
Outdated
| && !(msvc | ||
| && self | ||
| .generator | ||
| .as_deref() | ||
| .map_or(true, |g| g.to_string_lossy().starts_with("Visual Studio"))) |
There was a problem hiding this comment.
This is definitely weirdly complicated for an inline condition, and depends on the default generator choice for MSVC being Visual Studio (implemented below, unchanged). Suggestions welcome on how to reorganize this.
|
(Test failures are also happening on upstream.) |
tgross35
added
the
S-waiting-on-review
Setting CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR is often enough for CMake to handle cross-compilation even without a toolchain file, but it gets in the way of generators that handle cross-compilation on their own (in Visual Studio's case, using the -T "toolset" option).
jrose-signal
force-pushed
the
visual-studio-cross-compilation
branch
from
88ba56f to
897845f
Compare
ChrisDenton
left a comment
ChrisDenton
left a comment
There was a problem hiding this comment.
On the face of it this does look reasonable to me. We shouldn't have competing sources of truth for cross-compiling.
However, I'm not yet familiar enough with how this crate is used in practice to be confident this won't be breaking for someone out there. Could someone be relying on CMAKE_SYSTEM_NAME or CMAKE_SYSTEM_PROCESSOR being set even for Visual Studio builds?
|
They weren't set before 1.0.50, but now they've been set for a while, so I can't say for sure. However, if I knew how to get things to work with them set (and without using a toolchain file), then I would do that, and I didn't find such a way when I looked in 2023. (I only looked briefly when rebasing this PR, confirming that it's still an issue in the latest cmake-rs and with the latest CMake installed.) |
3 participants
Setting
CMAKE_SYSTEM_NAMEandCMAKE_SYSTEM_PROCESSORis often enough for CMake to handle cross-compilation even without a toolchain file, but it gets in the way of generators that handle cross-compilation on their own (in Visual Studio's case, using the -T "toolset" option).Narrow fix for the issue I brought up in #158 (comment). Possible fix for #171 as well, if it does turn out to be the same thing.