Don't set CMAKE_SYSTEM_NAME when using the Visual Studio generator#193
Don't set CMAKE_SYSTEM_NAME when using the Visual Studio generator#193jrose-signal wants to merge 1 commit intorust-lang:mainfrom
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.) |
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).
88ba56f to
897845f
Compare
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.) |
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.