fail with 'Unable identify compiler architecture for CMAKE_SYSTEM_PROCESSOR'

[aminya]

This issue is mirrored from aminya/project_options#200

@hihig2001 originally wrote:

I use visual studio 2022 17.4.4 with integrated cmake, and pre-installed vcpkg.
My cmake file is mostly similar with example file.
Difference is that I don't use run_vcpkg() functionality.
Instead, I register 'CMAKE_TOOL_CHAIN' using CMakePresets.json, just like visual studio's official manual.

I'm not so sure about that it is appropriate to report here or 'WindowsToolchain' cause it is dependency not 'project_option' itself.
but I thought that it is something worth to report.

1> Command line: "C:\WINDOWS\system32\cmd.exe" /c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Ninja"  -DCMAKE_TOOLCHAIN_FILE:FILEPATH="C:\dev\vcpkg/scripts/buildsystems/vcpkg.cmake" -DCMAKE_C_COMPILER:STRING="cl" -DCMAKE_CXX_COMPILER:STRING="cl" -DCMAKE_BUILD_TYPE:STRING="Debug" -DFEATURE_UNIT_TESTS:STRING="ON" -DCMAKE_INSTALL_PREFIX:PATH="E:/work/Knuckles/Game/out/install/windows-msvc-debug-soft-mode"  -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "E:\work\Knuckles\Game" 2>&1"
1> Working directory: E:/work/Knuckles/Game/out/build/windows-msvc-debug-soft-mode
1> [CMake] CMake Warning (dev) at C:/Program Files/Microsoft Visual Studio/2022/Professional/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.24/Modules/FetchContent.cmake:1264 (message):
1> [CMake]   The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
1> [CMake]   not set.  The policy's OLD behavior will be used.  When using a URL
1> [CMake]   download, the timestamps of extracted files should preferably be that of
1> [CMake]   the time of extraction, otherwise code that depends on the extracted
1> [CMake]   contents might not be rebuilt if the URL changes.  The OLD behavior
1> [CMake]   preserves the timestamps from the archive instead, but this is usually not
1> [CMake]   what you want.  Update your project to the NEW behavior or specify the
1> [CMake]   DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
1> [CMake]   robustness issue.
1> [CMake] Call Stack (most recent call first):
1> [CMake]   CMakeLists.txt:24 (FetchContent_Declare)
1> [CMake] This warning is for project developers.  Use -Wno-dev to suppress it.
1> [CMake] 
1> [CMake] -- Using Windows Windows toolchain
1> [CMake] CMake Error at out/build/windows-msvc-debug-soft-mode/_deps/_msvc_toolchain-src/Windows.MSVC.toolchain.cmake:169 (message):
1> [CMake]   Unable identify compiler architecture for CMAKE_SYSTEM_PROCESSOR
1> [CMake] Call Stack (most recent call first):
1> [CMake]   out/build/windows-msvc-debug-soft-mode/_deps/_project_options-src/src/VCEnvironment.cmake:72 (include)
1> [CMake]   out/build/windows-msvc-debug-soft-mode/_deps/_project_options-src/src/Index.cmake:34 (msvc_toolchain)
1> [CMake]   out/build/windows-msvc-debug-soft-mode/_deps/_project_options-src/CMakeLists.txt:3 (include)
1> [CMake] -- Configuring incomplete, errors occurred!
1> 'C:\WINDOWS\system32\cmd.exe' '/c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Ninja"  -DCMAKE_TOOLCHAIN_FILE:FILEPATH="C:\dev\vcpkg/scripts/buildsystems/vcpkg.cmake" -DCMAKE_C_COMPILER:STRING="cl" -DCMAKE_CXX_COMPILER:STRING="cl" -DCMAKE_BUILD_TYPE:STRING="Debug" -DFEATURE_UNIT_TESTS:STRING="ON" -DCMAKE_INSTALL_PREFIX:PATH="E:/work/Knuckles/Game/out/install/windows-msvc-debug-soft-mode"  -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "E:\work\Knuckles\Game" 2>&1"' execution failed with error: ''C:\WINDOWS\system32\cmd.exe' '/c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Ninja"  -DCMAKE_TOOLCHAIN_FILE:FILEPATH="C:\dev\vcpkg/scripts/buildsystems/vcpkg.cmake" -DCMAKE_C_COMPILER:STRING="cl" -DCMAKE_CXX_COMPILER:STRING="cl" -DCMAKE_BUILD_TYPE:STRING="Debug" -DFEATURE_UNIT_TESTS:STRING="ON" -DCMAKE_INSTALL_PREFIX:PATH="E:/work/Knuckles/Game/out/install/windows-msvc-debug-soft-mode"  -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "E:\work\Knuckles\Game" 2>&1"' returned with exit code: 1'.

[aminya]

I think by using the detect_architecture function of project_options this issue can be fixed.

https://github.com/aminya/project_options/blob/0aae24f7ac01d262055079d6ddca7070506082af/src/Utilities.cmake#L147-L207

[MarkSchofield]

Perhaps just defaulting CMAKE_SYSTEM_PROCESSOR to CMAKE_HOST_SYSTEM_PROCESSOR would suffice?

[MarkSchofield]

Oh... I try and default CMAKE_SYSTEM_PROCESS to CMAKE_HOST_SYSTEM_PROCESSOR, here:

if(NOT CMAKE_SYSTEM_PROCESSOR)
    set(CMAKE_SYSTEM_PROCESSOR ${CMAKE_HOST_SYSTEM_PROCESSOR})
endif()

[hihig2001]

I downloaded last 'WindowsToolchain' which was 'project_option' dependent, back when 'project option' works.
and check some diff with current and I found that what has changed.

it was

if(NOT CMAKE_SYSTEM_PROCESSOR)
    set(CMAKE_SYSTEM_PROCESSOR x64)
endif()

so I manually changed newer version(v0.5.1)'s ${CMAKE_HOST_SYSTEM_PROCESSOR} with x64 to see if it works after.
and it worked!

I don't know well enough on cmake, but it seems that relying on ${CMAKE_HOST_SYSTEM_PROCESSOR} is not enough?

[ClausKlein]

see CMAKE_SYSTEM_PROCESSOR

[hihig2001]

As you see -DCMAKE_TOOLCHAIN_FILE:FILEPATH="C:\dev\vcpkg/scripts/buildsystems/vcpkg.cmake"
toolchain file has setted with vcpkg.
Is it mean that there are order dependency problem?
Since I have no knowledge wit when cmake_toolchain_file do works, I don't have an answer for that.

[ClausKlein]

so I manually changed newer version(v0.5.1)'s ${CMAKE_HOST_SYSTEM_PROCESSOR} with x64 to see if it works after. And it worked!

I don't know well enough on cmake, but it seems that relying on ${CMAKE_HOST_SYSTEM_PROCESSOR} is not enough?

IMHO: You are cross compiling!
" When cross-compiling, a CMAKE_TOOLCHAIN_FILE should set the CMAKE_SYSTEM_PROCESSOR variable to match target architecture that it specifies (via CMAKE_LANG_COMPILER and perhaps CMAKE_LANG_COMPILER_TARGET). "

[hihig2001]

Please let me know if if I misunderstand something.

Since I have set CMAKE_TOOLCHAIN_FILE with vcpkg.cmake, vcpkg.cmake' will set CMAKE_HOST_SYSTEM_PROCESSOR and CMAKE_SYSTEM_PROCESSOR eventually.

It means that WindowsToolchain must be executed after CMAKE_SYSTEM_PROCESSOR has resolved, which means that CMAKE_TOOLCHAIN_FILE must be executed before WindowsToolchain is executed.

But I have no idea when cmake runs CMAKE_TOOLCHAIN_FILE.
I followed canonical example of cross compiling in 'VS2022 cmake project' and 'project_option'.
Should I do force something?

[ClausKlein]

IMHO: If you are working with ninja and MS cc, this is the right toolchain.cmake
It should set all this cmake variables right.
If not, help them to do it: cmake -D CMAKE_HOST_SYSTEM_PROCESSOR=x86 ...

If it works, I do not know, if have never tried to build a win 32 BIT program with it.

[MarkSchofield]

Since WindowsToolchain is a toolchain, it's supposed to set CMAKE_SYSTEM_PROCESSOR. It was originally defaulting to x64, but that's wrong for a couple of reasons:

• Error selecting MSVC toolchain #41 demonstrated that x64 wasn't right. Since it needs to align to CMAKE_HOST_SYSTEM_PROCESSOR, and CMAKE_HOST_SYSTEM_PROCESSOR defaults to the value of the PROCESSOR_ARCHITECTURE environment variable on Windows (as per the CMAKE_HOST_SYSTEM_PROCESSOR documentation), and that's AMD64 for 64-bit OS's.
• The CMAKE_SYSTEM_PROCESSOR documentation says that its value should default to the value of CMAKE_HOST_SYSTEM_PROCESSOR when not-cross-compiling. And that should be the default.

So the fix for #41 (#42) changed the default of CMAKE_SYSTEM_PROCESSOR to be CMAKE_HOST_SYSTEM_PROCESSOR. Which seems to be the right thing to do. And on my machine, that works. If I don't set a CMAKE_SYSTEM_PROCESSOR value in, say, my CMakePresets.json this logic kicks in:

if(NOT CMAKE_SYSTEM_PROCESSOR)
    set(CMAKE_SYSTEM_PROCESSOR ${CMAKE_HOST_SYSTEM_PROCESSOR})
endif()

And CMAKE_SYSTEM_PROCESSOR is defaulted to CMAKE_HOST_SYSTEM_PROCESSOR. And everything works for me.

The error message from OP, contains the text:

Unable identify compiler architecture for CMAKE_SYSTEM_PROCESSOR

That's written by this code which shows that the value of CMAKE_SYSTEM_PROCESSOR is written at the end of the message, so in this case, it's empty! The only way I can see that being the case is if CMAKE_HOST_SYSTEM_PROCESSOR is empty - which I don't see on my machine, but I am using the latest CMake (3.25.2 at the moment).

What version of CMake are you using? Any idea why CMAKE_HOST_SYSTEM_PROCESSOR would be empty? I could check for an empty CMAKE_HOST_SYSTEM_PROCESSOR, and default it to $ENV{PROCESSOR_ARCHITECTURE}, but that seems to be overly defensive until we've understood why CMAKE_HOST_SYSTEM_PROCESSOR is empty in the first place.

[MarkSchofield]

The fact that you're specifying the vcpkg.cmake as your CMAKE_TOOLCHAIN_FILE means that WindowsToolchain isn't your CMAKE_TOOLCHAIN_FILE - you must be include'ing it later...? I haven't tried that; I'll perhaps try and pull together a repro of that when I get a chance.

TBH, even though the VCPkg documentation says to specify vcpkg.cmake as the CMAKE_TOOLCHAIN_FILE, it doesn't seem to fulfil the role of a toolchain file - i.e. determining the location of the necessary compiler/utility paths. Infact, microsoft/vcpkg#8163 offers a similar sentiment.

[MarkSchofield]

OK, I tried using WindowsToolchain and VCPkg, and whilst it was a bit painful - I'll file a separate issue to have that conversation - I can't reproduce the CMAKE_HOST_SYSTEM_PROCESSOR-being-blank problem (that I'm currently assuming this is).

I think that the best way to track this down would be to use --trace to find - presumably - where CMAKE_HOST_SYSTEM_PROCESSOR is being cleared. If I configure the 'example' folder with --trace, then I see CMAKE_HOST_SYSTEM_PROCESSOR being set almost immediately, followed by the toolchain being processed. Here's the start of the file:

WindowsToolchain/example/CMakeLists.txt(4):  cmake_minimum_required(VERSION 3.20 )
WindowsToolchain/example/CMakeLists.txt(6):  project(WindowsToolchainExample )
WindowsToolchain/example/__output/windows-msvc-blank/CMakeFiles/3.25.2/CMakeSystem.cmake(1):  set(CMAKE_HOST_SYSTEM Windows-10.0.22621 )
WindowsToolchain/example/__output/windows-msvc-blank/CMakeFiles/3.25.2/CMakeSystem.cmake(2):  set(CMAKE_HOST_SYSTEM_NAME Windows )
WindowsToolchain/example/__output/windows-msvc-blank/CMakeFiles/3.25.2/CMakeSystem.cmake(3):  set(CMAKE_HOST_SYSTEM_VERSION 10.0.22621 )
WindowsToolchain/example/__output/windows-msvc-blank/CMakeFiles/3.25.2/CMakeSystem.cmake(4):  set(CMAKE_HOST_SYSTEM_PROCESSOR AMD64 )
WindowsToolchain/example/__output/windows-msvc-blank/CMakeFiles/3.25.2/CMakeSystem.cmake(6):  include(WindowsToolchain/Windows.MSVC.toolchain.cmake )
WindowsToolchain/Windows.MSVC.toolchain.cmake(60):  cmake_minimum_required(VERSION 3.20 )

So CMake is setting:

CMAKE_HOST_SYSTEM
CMAKE_HOST_SYSTEM_NAME
CMAKE_HOST_SYSTEM_VERSION
CMAKE_HOST_SYSTEM_PROCESSOR

And then processing the toolchain. I'm assuming that because you're using the VCPkg as your toolchain, then something must be clearing CMAKE_HOST_SYSTEM_PROCESSOR before it gets to WindowsToolchain..? The --trace output should list where that's happening, and we can figure out what can be done about it. Reply back with details..?

[aminya]

Is there a minimal reproduction of this issue? I use vcpkg every day without problems. Is the difference in adding the toolchain in CMakePresets instead of using the provided run_vcpkg function?

[MarkSchofield]

I'm unable to reproduce this. If anyone can reproduce it, and can share steps, or is comfortable sharing their --trace output, then that should hopefully provide some actionable information.

[Nosenzor]

Is there a minimal reproduction of this issue? I use vcpkg every day without problems. Is the difference in adding the toolchain in CMakePresets instead of using the provided run_vcpkg function?

Try to use lukka's run_vcpkg with a simple project. It fails for this reason on windows runners. (Reproduced with 0.30)

[Nosenzor]

if(NOT CMAKE_SYSTEM_PROCESSOR)
    set(CMAKE_SYSTEM_PROCESSOR ${CMAKE_HOST_SYSTEM_PROCESSOR})
endif()

is not working because CMAKE_HOST_SYSTEM_PROCESSOR is not set too

  CMAKE_BUILD_TYPE="Release"
  CMAKE_TOOLCHAIN_FILE:FILEPATH="./vcpkg/scripts/buildsystems/vcpkg.cmake"

-- CMAKE_SYSTEM_PROCESSOR not set, setting it to 
-- Using Windows Windows toolchain
CMake Error at builds/ninja-release-vcpkg/_deps/_msvc_toolchain-src/Windows.MSVC.toolchain.cmake:170 (message):
Error:   Unable identify compiler architecture for CMAKE_SYSTEM_PROCESSOR
Call Stack (most recent call first):
  builds/ninja-release-vcpkg/_deps/_project_options-src/src/VCEnvironment.cmake:65 (include)
  builds/ninja-release-vcpkg/_deps/_project_options-src/src/Index.cmake:38 (msvc_toolchain)
  builds/ninja-release-vcpkg/_deps/_project_options-src/CMakeLists.txt:3 (include)

I'm not sure who is responsible to set those two.

[MarkSchofield]

I tried lukka's run_vcpkg locally, and it works for me. The steps I took:

1. cloned the repo at the tag v11
2. ran git submodule update --init --recursive to get vcpkg cloned
3. Added the following to the ninja-multi-vcpkg configuration preset cacheVariables (where is a path to a WindowsToolchain repo):

    "VCPKG_CHAINLOAD_TOOLCHAIN_FILE": {
        "type": "FILEPATH",
        "value": "<qualified path>/Windows.MSVC.toolchain.cmake"
    }

4. Ran 'cmake --build --preset ninja-vcpkg-debug'
5. Compilation succeeded, but there was an error saying that "Neither dumpbin, llvm-objdump nor objdump could be found. Can not take care of dll dependencies." (which is tracked as WindowsToolchain and VCPkg don't work well together #59).

It fails for this reason on windows runners. (Reproduced with 0.30)

Do you mean under GitHub Actions? I'll give that a try.

[MarkSchofield]

I tried under GitHub Actions and can't repro. Steps:

1. I forked https://github.com/lukka/CppCMakeVcpkgTemplate into https://github.com/MarkSchofield/CppCMakeVcpkgTemplate
2. I added a single commit to submodule MarkSchofield/WindowsToolchain, and specify the toolchain as VCPKG_CHAINLOAD_TOOLCHAIN_FILE
3. I manually kicked-off the Workflow. The run is here. It succeeded. I didn't even get the "Neither dumpbin, llvm-objdump nor objdump could be found. Can not take care of dll dependencies." message since lukka/run-vcpkg appears to set the environment before launching CMake.

[aminya]

An update on the project_options:
aminya/project_options#200 (comment)

[ClausKlein]

There is still a problem with WindowsToolchain v0.70 and PackageOptions v.0.32.0:

You may find my test setup here aminya/cpp_vcpkg_project#31

CMake Error at build/release/_deps/_msvc_toolchain-src/Windows.MSVC.toolchain.cmake:166 (message):
  Unable identify compiler architecture for CMAKE_SYSTEM_PROCESSOR
Call Stack (most recent call first):
  build/release/_deps/_project_options-src/src/VCEnvironment.cmake:65 (include)
  build/release/_deps/_project_options-src/src/Index.cmake:39 (msvc_toolchain)
  build/release/_deps/_project_options-src/CMakeLists.txt:3 (include)

My workaround is to set this in my configure presets used:

{
            "name": "default-config",
            "hidden": true,
            "generator": "Ninja",
            "cacheVariables": {
                "CMAKE_HOST_SYSTEM_PROCESSOR": "$penv{PROCESSOR_ARCHITECTURE}"
            },
            "environment": { "VARIANT": "MSVC" }
}

[ClausKlein]

MSVC-build.log

This is my git repo used:

MINGW64 ~/Workspace/cpp/cpp_vcpkg_project (feature/test-docker-build)
$ git remote -v
origin https://github.com/ClausKlein/cpp_vcpkg_project.git (fetch)
origin https://github.com/ClausKlein/cpp_vcpkg_project.git (push)

MINGW64 ~/Workspace/cpp/cpp_vcpkg_project (feature/test-docker-build)
$ git branch
develop

• feature/test-docker-build
  mschofie/windowstoolchain

[ClausKlein]

If I change this, it works fine:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index c74c603..5fdf8b8 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -31,7 +31,7 @@ if(ENABLE_CROSS_COMPILING)
   enable_cross_compiler()
 endif()
 # install vcpkg dependencies: - should be called before defining project()
-run_vcpkg()
+#XXX run_vcpkg()

 # Set the project name and language
 project(
diff --git a/CMakeWorkflowPresets.json b/CMakeWorkflowPresets.json
index f797b93..fd4b407 100644
--- a/CMakeWorkflowPresets.json
+++ b/CMakeWorkflowPresets.json
@@ -11,7 +11,10 @@
             "hidden": true,
             "generator": "Ninja",
             "cacheVariables": {
-                "CMAKE_HOST_SYSTEM_PROCESSOR": "$penv{PROCESSOR_ARCHITECTURE}"
+                "CMAKE_TOOL_CHAIN": "WindowsToolchain",
+                "CMAKE_C_COMPILER_Y": "cl",
+                "CMAKE_CXX_COMPILER_Y": "cl",
+                "CMAKE_HOST_SYSTEM_PROCESSOR_Y": "$penv{PROCESSOR_ARCHITECTURE}"
             },
             "environment": { "VARIANT": "MSVC" }
         },

[aminya]

project_options fixed this issue in v0.32.1 by not including the MSVC toolchain when CMAKE_TOOLCHAIN_FILE is already specified.

[FeignClaims]

What version of CMake are you using? Any idea why CMAKE_HOST_SYSTEM_PROCESSOR would be empty? I could check for an empty CMAKE_HOST_SYSTEM_PROCESSOR, and default it to $ENV{PROCESSOR_ARCHITECTURE}, but that seems to be overly defensive until we've understood why CMAKE_HOST_SYSTEM_PROCESSOR is empty in the first place.

@MarkSchofield According to this answer, CMAKE_HOST_SYSTEM_PROCESSOR is only set after project(...). Could we consider defaulting CMAKE_HOST_SYSTEM_PROCESSOR to $ENV{PROCESSOR_ARCHITECTURE} to help address this issue? This issue still occurs when I deliberately add the toolchain file using include(Windows.MSVC.toolchain.cmake) before project(...) and run cmake -B build -S . -G Ninja in "Developer Command Prompt for VS 2022".

[aminya]

I am facing this issue again directly in a project. CMAKE_SYSTEM_PROCESSOR is unset. The above workaround should be a good default!

[MarkSchofield]

Well, I tried to repro - include'ing Windows.MSVC.toolchain.cmake before the project call, and CMAKE_HOST_SYSTEM_PROCESSOR is definitely empty. If I try adding the following to the start of Windows.MSVC.toolchain.cmake (which is how CMake defaults CMAKE_HOST_SYSTEM_PROCESSOR);

  if(DEFINED ENV{PROCESSOR_ARCHITEW6432})
    set(CMAKE_HOST_SYSTEM_PROCESSOR "$ENV{PROCESSOR_ARCHITEW6432}")
  else()
    set(CMAKE_HOST_SYSTEM_PROCESSOR "$ENV{PROCESSOR_ARCHITECTURE}")
  endif()

Then things get further, but my try_compile fails - the link_directories that the toolchain set don't appear to persist into the try_compile, so kernel32.lib isn't found.

Toolchain files are supposed to be read in the project() call - documented here. I'm not sure it's worth trying to figure out/support parsing it before the project() call. What's the use case for include'ing the toolchain earlier? For scenarios - like 'vcpkg' - where another toolchain is used, Windows.MSVC.toolchain.cmake could be specified as a CMAKE_PROJECT_TOP_LEVEL_INCLUDES (in version CMake 3.24 and higher)..?

[MarkSchofield]

Ah, nope. CMAKE_PROJECT_TOP_LEVEL_INCLUDES "[is] not for specifying the toolchain details", and hits the same problem - the link_directories don't propagate into try_compile. If you want to use WindowsToolchain toolchains, they need to be parsed in the toolchain scope.

[aminya]

I have decided not to activate the Windows toolchain in the next version of project_options. The corner cases need to be tackled for cross-compilation and inclusion before CMake knows the system. Right now, this is still not there.

aminya/project_options#286

I still provide the function in case someone ensures that their configurations don't hit any of the corner cases.

msvc_toolchain()

[MarkSchofield]

So the bottom line is that including WindowsToolchain before the top-level project call fails, because CMAKE_HOST_SYSTEM_PROCESSOR isn't set. Toolchains are supposed to be read in the call to the top-level project, when CMAKE_HOST_SYSTEM_PROCESSOR has been set. I don't see the point in supporting non-standard consumption, so I'll close this as "By Design".