CMAKE_SYSTEM_PROCESSOR is broken on Windows

Not a full solution, but if CMAKE_GENERATOR_PLATFORM is set, can that at least be used to provide the correct value for CMAKE_SYSTEM_PROCESSOR on Windows?

Repeating a comment I made in Mantis for easy reference:

A challenge here is that CMAKE_SYSTEM_PROCESSOR is supposed to be set as part of the CMakeSystem.cmake, configured from CMakeSystem.cmake.in but that configuration occurs very early, even before we have tried to enable any languages or detect any compilers. For Makefile and Ninja generators this is straightforward. When not cross-compiling the host processor can be detected immediately. When cross-compiling it is the responsibility of the CMAKE_TOOLCHAIN_FILE to set CMAKE_SYSTEM_PROCESSOR for the target.

The problem for VS generators is that the target architecture is not determined in time to configure CMakeSystem.cmake because they "cross" compile without explicitly saying so.

@craig.scott yes, I think we should be able to compute the CMAKE_SYSTEM_PROCESSOR when CMAKE_GENERATOR is "Visual Studio ...". We can check for CMAKE_GENERATOR_PLATFORM and also fall back to trying to parse the Win64 from the end of the CMAKE_GENERATOR name. The logic should be added in CMakeDetermineSystem.cmake where we default to the host info.

added triage:mr-welcome label

Must not forget that for Visual Studio, there's more than just x86 and Win64, there's also ARM or some variant thereof, if I understand correctly.

mentioned in issue #16727 (closed)

Sorry, the "mentioned in issue" just above was an error on my part, it is not related to this one (seems gitlab remembers references even after you edit the comment).

Currently looking for guidance on ways to work around this difficulty, it's pretty rough to do in a general way. Any chance this will become an upstream priority?

After compiler probing, CMake does set CMAKE_CXX_COMPILER_ARCHITECTURE_ID (documented, but specifically mentioned as internal and subject to change) , and the undocumented MSVC_<lang>_ARCHITECTURE_ID and MSVC_CXX_ARCHITECTURE_FAMILY. And these do handle the ADM/ARM64/SHx architectures as well as just x86/x64. But this isn't detected in time to get into CMAKE_SYSTEM_PROCESSOR like they really should.

We can check for CMAKE_GENERATOR_PLATFORM and also fall back to trying to parse the Win64 from the end of the CMAKE_GENERATOR name

I can see how to implement that, but not how it solves anything when using a Ninja/JOM/NMake generator... Right now CMakeDetermine{C,CXX}Compiler picks MSVC, the decision really comes down to which set of compilers is in %PATH% (i.e. what vcvarsall invocation was used). So CMAKE_SYSTEM_PROCESSOR just really isn't known until picks a compiler to call and then works out which arch that's producing. Or I suppose you could go the other way, and have compiler-id detection error out if it turns out the cl chosen doesn't match CMAKE_SYSTEM_PROCESSOR (thus forcing users to set it via -A CMAKE_GENERATOR_PLATFORM even for generators where that doesn't actually do anything, just to keep things consistent.

And if doing that, maybe also change cmake-gui to offer a "with MSVC" radio button with the same arch dropdowns it shows for the msbuild generators, and use vswhere/vcvarsall around its invocation of CMake to actually get the requested arch.

mentioned in issue #20073 (closed)

I donno if it's any help, but I made a "WorkaroundBug.cmake" file and the following seems to work okay:

if ("${CMAKE_CXX_COMPILER}" MATCHES ".*/Microsoft Visual Studio/.*/Tools/MSVC/.*/bin/.*/x86/cl\\.exe")
  set(CMAKE_SYSTEM_PROCESSOR "X86")
endif()

An more robust workaround would be to use the existing compiler detection instead of hardcoding paths (e.g. I think your workaround would be broken with Visual Studio build tools)

if(MSVC)
    set(CMAKE_SYSTEM_PROCESSOR ${MSVC_CXX_ARCHITECTURE_ID})
endif()

It's just that this happens to late to get into CMakeSystem.cmake

It's should be fixed at https://github.com/Kitware/CMake/blob/0064981f6fb5ab96cb09bfdc456f6250ee4cb311/Modules/CMakeDetermineSystem.cmake#L146

That line is only for builds targeting WinCE. Also, in general MSVC_C_ARCHITECTURE_ID has not been computed at the time that line runs. I'm not sure it's correct, and may work only when the toolchain file sets MSVC_C_ARCHITECTURE_ID, which isn't typical usage.

Hi, I've create a pull-request, may you have a look.

mentioned in commit lygstate/cmake@878f9fc4

mentioned in commit lygstate/cmake@d3f36b67

mentioned in merge request !5734 (closed)

#15170 (comment 226468) outlines a fundamental problem: we don't know the target platform of the toolchain at the time CMAKE_SYSTEM_PROCESSOR is supposed to be determined. We don't even know what compiler is to be used yet.

Possible paths forward include:

Resolve #17702 (closed), make CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID a first-class public variable, and tell projects to use that instead of CMAKE_SYSTEM_PROCESSOR.
Add more heuristics to choosing CMAKE_SYSTEM_PROCESSOR. For VS generators we probably know what they are targeting pretty early. For command-line generators we expect the environment to be prepared for cl already, so we may be able to look for a hint in the environment.
Document this limitation of CMAKE_SYSTEM_PROCESSOR more explicitly. (EDIT: !5744 (merged) does this)

I have a question, how does CMAKE_SYSTEM_PROCESSOR detected? Does that comes from the compiler?

Here is the env for vs 2019

**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.8.3
** Copyright (c) 2020 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x86'

C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools>set
ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\lygstate\AppData\Roaming
CommandPromptType=Native
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMPUTERNAME=DESKTOP-94PU0GB
ComSpec=C:\WINDOWS\system32\cmd.exe
DevEnvDir=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\
DriverData=C:\Windows\System32\Drivers\DriverData
ExtensionSdkDir=C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs
FPS_BROWSER_APP_PROFILE_STRING=Internet Explorer
FPS_BROWSER_USER_PROFILE_STRING=Default
Framework40Version=v4.0
FrameworkDir=C:\WINDOWS\Microsoft.NET\Framework\
FrameworkDIR32=C:\WINDOWS\Microsoft.NET\Framework\
FrameworkVersion=v4.0.30319
FrameworkVersion32=v4.0.30319
HOMEDRIVE=C:
HOMEPATH=\Users\lygstate
IFCPATH=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29333\ifc\x86
INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29333\ATLMFC\include;C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29333\include;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt;C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared;C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\winrt;C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\cppwinrt
LIB=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29333\ATLMFC\lib\x86;C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29333\lib\x86;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\lib\um\x86;C:\Program Files (x86)\Windows Kits\10\lib\10.0.19041.0\ucrt\x86;C:\Program Files (x86)\Windows Kits\10\lib\10.0.19041.0\um\x86
LIBPATH=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29333\ATLMFC\lib\x86;C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29333\lib\x86;C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29333\lib\x86\store\references;C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.19041.0;C:\Program Files (x86)\Windows Kits\10\References\10.0.19041.0;C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319
LOCALAPPDATA=C:\Users\lygstate\AppData\Local
LOGONSERVER=\\DESKTOP-94PU0GB
MOSQUITTO_DIR=C:\Program Files\mosquitto
NETFXSDKDir=C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\
NUMBER_OF_PROCESSORS=8
OneDrive=C:\Users\lygstate\OneDrive
OneDriveConsumer=C:\Users\lygstate\OneDrive
OS=Windows_NT
Path=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29333\bin\HostX86\x86;C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\VC\VCPackages;C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer;C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\bin\Roslyn;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\;C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x86;C:\Program Files (x86)\Windows Kits\10\bin\x86;C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\\MSBuild\Current\Bin;C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319;C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\;C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\Tools\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files (x86)\Bitvise SSH Client;C:\Program Files\Git\cmd;C:\Program Files\nodejs\;C:\Program Files\CMake\bin;C:\Program Files\TortoiseGit\bin;C:\Program Files\Microsoft VS Code\bin;C:\Program Files\WireGuard\;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files\dotnet\;C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility;C:\Users\lygstate\AppData\Local\Programs\Python\Python38\Scripts\;C:\Users\lygstate\AppData\Local\Programs\Python\Python38\;C:\Users\lygstate\AppData\Local\Microsoft\WindowsApps;C:\Users\lygstate\AppData\Roaming\npm;C:\Users\lygstate\.dotnet\tools;;C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\Llvm\bin;C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin;C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
Platform=x86
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 142 Stepping 11, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=8e0b
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
PROMPT=$P$G
PSModulePath=C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
PUBLIC=C:\Users\Public
SESSIONNAME=Console
SystemDrive=C:
SystemRoot=C:\WINDOWS
TEMP=C:\Users\lygstate\AppData\Local\Temp
TMP=C:\Users\lygstate\AppData\Local\Temp
UCRTVersion=10.0.19041.0
UniversalCRTSdkDir=C:\Program Files (x86)\Windows Kits\10\
USERDOMAIN=DESKTOP-94PU0GB
USERDOMAIN_ROAMINGPROFILE=DESKTOP-94PU0GB
USERNAME=lygstate
USERPROFILE=C:\Users\lygstate
VCIDEInstallDir=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\VC\
VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\
VCToolsInstallDir=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.28.29333\
VCToolsRedistDir=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Redist\MSVC\14.28.29325\
VCToolsVersion=14.28.29333
VisualStudioVersion=16.0
VS100COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\
VS140COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\
VS160COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\Tools\
VS90COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\
VSCMD_ARG_app_plat=Desktop
VSCMD_ARG_HOST_ARCH=x86
VSCMD_ARG_TGT_ARCH=x86
VSCMD_VER=16.8.3
VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\
VSSDK150INSTALL=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VSSDK
VSSDKINSTALL=C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VSSDK
windir=C:\WINDOWS
WindowsLibPath=C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.19041.0;C:\Program Files (x86)\Windows Kits\10\References\10.0.19041.0
WindowsSdkBinPath=C:\Program Files (x86)\Windows Kits\10\bin\
WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10\
WindowsSDKLibVersion=10.0.19041.0\
WindowsSdkVerBinPath=C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\
WindowsSDKVersion=10.0.19041.0\
WindowsSDK_ExecutablePath_x64=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64\
WindowsSDK_ExecutablePath_x86=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\
__DOTNET_ADD_32BIT=1
__DOTNET_PREFERRED_BITNESS=32
__VSCMD_PREINIT_PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files (x86)\Bitvise SSH Client;C:\Program Files\Git\cmd;C:\Program Files\nodejs\;C:\Program Files\CMake\bin;C:\Program Files\TortoiseGit\bin;C:\Program Files\Microsoft VS Code\bin;C:\Program Files\WireGuard\;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files\dotnet\;C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility;C:\Users\lygstate\AppData\Local\Programs\Python\Python38\Scripts\;C:\Users\lygstate\AppData\Local\Programs\Python\Python38\;C:\Users\lygstate\AppData\Local\Microsoft\WindowsApps;C:\Users\lygstate\AppData\Roaming\npm;C:\Users\lygstate\.dotnet\tools;

Yeap, I've seen that, but it's also werid, why need bind to C/CXX/ASM/RUST and so on, Why we doesn't have things like CMAKE_COMPILER_ARCHITECTURE_ID That's weird, do we have the posiblity that CMAKE_C_COMPILER_ARCHITECTURE_ID CMAKE_CXX_COMPILER_ARCHITECTURE_ID CMAKE_ASM_COMPILER_ARCHITECTURE_ID CMAKE_RUST_COMPILER_ARCHITECTURE_ID have different value? So I think is is not a good alternative to CMAKE_SYSTEM_PROCESSOR

We do have CMAKE_SIZEOF_VOID_P, which is defined by taking our internal CMAKE_<LANG>_SIZEOF_DATA_PTR value computed from each toolchain, and just assuming they are all the same. It's defined once one language is enabled.

I think a CMAKE_COMPILER_ARCHITECTURE_ID or similar variable could be provided as soon as any CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID is available, but that would make sense only once the latter is defined for all compilers.

!5744 (merged) updates the documentation to be clear about the current meaning of CMAKE_SYSTEM_PROCESSOR.

so we may be able to look for a hint in the environment

vcvarsall sets VSCMD_ARG_HOST_ARCH and VSCMD_ARG_TGT_ARCH, though it's not clear that these are meant to be public.

@brad.king Where is the first place that cmake detecting MSVC compilers? may CMAKE_SYSTEM_PROCESSOR should setup there

CMAKE_SYSTEM_PROCESSOR is defined independently from any compiler. In a project that does

cmake_minimum_required(VERSION 3.19)
project(Example NONE)

there is no compiler at all, but CMAKE_SYSTEM_PROCESSOR is still supposed to be defined.

For projects that want to make decisions based on the compiler's target architecture (EDIT: on MSVC), CMAKE_SYSTEM_PROCESSOR is inappropriate.

Maybe we need document that, so what's the proper value to replace CMAKE_SYSTEM_PROCESSOR, and what's the intension of CMAKE_SYSTEM_PROCESSOR? CMake expose for CMAKE_SYSTEM_PROCESSOR for reason, right? If doesn't have any meaning, why expose that.

Documentation and alternative options were both covered in #15170 (comment 891234).

CMAKE_SYSTEM_PROCESSOR is well-defined on pretty much all platforms besides Windows, and is valid when defined by a toolchain file for cross-compiling.

Yeap, this issue is intent fixing CMAKE_SYSTEM_PROCESSOR on Windows. Make it usable, otherwise CMake user always need consider Windows sperately when targeting windows.

mentioned in merge request !5744 (merged)

changed the description

removed triage:mr-welcome label

mentioned in commit 5a6379f1

mentioned in merge request !6454 (closed)

mentioned in issue #22881

CMAKE_SYSTEM_PROCESSOR is broken on Windows

Child items ...

Activity