Compute CMAKE_C_COMPILER_ARCHITECTURE_ID everywhere

CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID is currently computed in Modules/CMakePlatformId.h.in during compiler identification for MSVC-like compilers and maybe a couple others. This works only for compilers where the choice of compiler tool determines the target architecture and no compiler flags can change it. It is needed very early for MSVC in order to know the proper -machine: linker argument for later try_compile checks and such.

It may be useful to provide information about the target architecture everywhere. For other compilers it could be detected in Modules/CMakeCompilerABI.h, which is built using the full set of flags that will be used for project code. We already detect sizeof(void*) there.

Cc: @chuck.atkins @ChrisTX

mentioned in issue #17701

mentioned in issue #14473

mentioned in merge request !1731 (closed)

mentioned in merge request !2085 (closed)

I just put up a WIP merge request, which appears to implement the suggested approach given here.

I'm not sure what a good source of architecture macros and names is. I used mostly https://sourceforge.net/p/predef/wiki/Architectures/ for the macros, and used the same names as Modules/CMakePlatformId.h.in.

I also haven't checked any platforms except x64 on Windows under mingw64 (MSYS2), and the unit test only checks that something is defined, not whether it's the right name.

I'm open to feedback, and have no specific plans to iterate beyond this point, without access to a lot of random hardware or cross-compilers.

mentioned in merge request !2353 (merged)

mentioned in issue #18553 (closed)

mentioned in issue #19142

mentioned in issue #20587

mentioned in merge request !4980 (closed)

mentioned in issue #15170

mentioned in merge request !6432 (closed)

mentioned in issue #22881

How about stablize it to resolve #22881, and document it in CMAKE_SYSTEM_PROCESSOR

It's not stabilized because it's computed everywhere. That's the point of this issue.

I think we can stablize it by force CMAKE_C_COMPILER_ARCHITECTURE_ID to be an valid value, that's is CMAKE_C_COMPILER_ARCHITECTURE_ID should be oneOf [ 'X86', 'x64', 'TMS320C6x', 'PPC64', and son on ] So the user would not mis - define it.

And also user can proved CMAKE_C_COMPILER_EXTRA_ARCHITECTURES to define other possible architectures to validate the CMAKE_C_COMPILER_ARCHITECTURE_ID for extension.

#  define ARCHITECTURE_ID "x64"

I have question, https://gitlab.kitware.com/cmake/cmake/-/blob/v3.21.4/Modules/CMakePlatformId.h.in#L210 Why this are use lowercase x, how about use "AMD64" or "X64" instead?

That's in GHS-specific code. Maybe a typo. I'm not familiar with GHS.

As we didn't stablize it, how about convert it to X86_64? It's comes from LLVM target triple https://llvm.org/doxygen/classllvm_1_1Triple.html

Also enabled detecting CMAKE_C_COMPILER_ARCHITECTURE_ID with gcc and clang? The most used compilers

That's the point of this issue.

Agree. After some experiments (#24110 (closed)), I found that this variable is

• SPECIFIED when we use the following compilers: (MSVC and Clang/LLVM)

  • %VCToolsInstallDir%\bin\Hostx64\x64\cl.exe
  • %VCToolsInstallDir%\bin\Hostx64\x86\cl.exe
  • %VCToolsInstallDir%\bin\Hostx86\x64\cl.exe
  • %VCToolsInstallDir%\bin\Hostx86\x86\cl.exe
  • C:\Program Files\LLVM\bin\clang.exe
  • C:\Program Files\LLVM\bin\clang-cl.exe
  • C:\Program Files (x86)\LLVM\bin\clang.exe
  • C:\Program Files (x86)\LLVM\bin\clang-cl.exe

• EMPTY when we use the following compilers: (Compilers in MSYS2)

  • C:/msys64/mingw64/bin/gcc.exe
  • C:/msys64/mingw32/bin/gcc.exe
  • C:/msys64/clang64/bin/clang.exe
  • C:/msys64/clang32/bin/clang.exe
  • C:/msys64/usr/bin/gcc.exe

on Windows platform.

mentioned in issue #23222 (closed)

mentioned in issue #23697

mentioned in issue #24065

mentioned in issue #24110 (closed)

marked #24110 (closed) as a duplicate of this issue

marked this issue as related to #24110 (closed)

This issue is highly important to the one I posted in cmake-conan repo:

• https://github.com/conan-io/cmake-conan/issues/457

since the current CMAKE_<LANG>_COMPILER_ARCHITECTURE only computes with MSVC and MSVC-based Clang compilers. (version 3.24)

Is this the preferred, if under-documented, way to detect architecture for the compiled binaries on MSVC? It appears that CMAKE_SYSTEM_PROCESSOR is somewhat useless with MSVC: the ARM64 toolchain reports AMD64.

Or, can we consider that a bug, since I would be using CMAKE_SYSTEM_PROCESSOR on all other platforms?

See #15170 about CMAKE_SYSTEM_PROCESSOR on Windows. Basically the problem is we don't know the target architecture until at least one language is enabled so we can detect what its compiler does, but by then CMAKE_SYSTEM_PROCESSOR is already determined.

CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID is language-specific and so does not have that problem, but it is only reliably defined with MSVC right now. For MSVC, it is the preferred way.

If CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID (guessing you meant with the _ID suffix?) is the preferred way to detect the architecture with MSVC, can that be documented? The documentation right now says it is "[a]n internal variable subject to change", but that it is needed "[f]or some compilers".

And then CMAKE_SYSTEM_PROCESSOR's documentation just says it's usable "[i]n many cases", cites MSVC as a case where it doesn't work, but says nothing about what to use instead.

I work on a project (BoringSSL) that needs architecture-specific code, and all these quirks make CMake very difficult to use for us. I eventually figured out what was going on by trawling the bug tracker, but ideally that'd just be in the documentation. Perhaps, in advance of CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID being made consistently available, the documentation could at least specify its relationship with MSVC? Then CMake users will at least know they need to special-case MSVC and how to do it.

mentioned in issue #25078

mentioned in issue #25640

mentioned in issue #25669

mentioned in merge request !10516 (merged)

mentioned in commit 1c9f8eeb

closed with commit 7f0f382c