fix the arch_host naming for armv8 (-> aarch64)

[bavardage]

Changelog: Fix: Fix CMake system processor name on armv8/aarch64.
Docs: Omit

fixes #14361

[CLAassistant]

All committers have signed the CLA.

[memsharded]

Thanks very much for contributing this fix @bavardage

Just one question, is there any other Conan architecture (armv4, armv4i, armv5el, armv5hf, armv6, armv7, armv7hf, armv7s, armv7k, armv8, armv8_32, armv8.3, arm64ec,) that should also be mapped?

[bavardage]

Not too sure - seems to be not amazingly well documented https://stackoverflow.com/questions/70475665/what-are-the-possible-values-of-cmake-system-processor

[jcar87]

I'd consider that the value of CMAKE_SYSTEM_PROCESSOR is not universal and is platform dependant - This PR is definitely in the right direction, as aarch64 is far more likely to be recognized and used than armv8 as a CMake architecture, but it will depend on how the variable is evaluated.

When cross-building CMAKE_SYSTEM_PROCESSOR can be completely arbitrary, the same armv8 has different values depending on the OS:

• Linux: aarch64
• Windows: ARM64 (all upper-case)
• macos: arm64 (all lower-case)
• Other: can include aarch64le

A robust CMake script evaluating CMAKE_SYSTEM_PROCESSOR should also be robust to this. Tesseract does it up to a point, I can see from here: https://github.com/tesseract-ocr/tesseract/blob/main/CMakeLists.txt#L245 that this script wouldn't be able to handle Windows ARM64.

[memsharded]

A robust CMake script evaluating CMAKE_SYSTEM_PROCESSOR should also be robust to this.

My concern is what is CMake internals doing? Isn't CMake itself expecting one value? Why it doesn't error if an unexpected or unmanaged value like armv8 is defined?

Could this change be considered breaking if users are evaluating the current armv8 value in their scripts already?

[jcar87]

A robust CMake script evaluating CMAKE_SYSTEM_PROCESSOR should also be robust to this.

My concern is what is CMake internals doing? Isn't CMake itself expecting one value? Why it doesn't error if an unexpected or unmanaged value like armv8 is defined?

When not cross-building, CMake uses the value from the underlying build tool, in a way that is very platform specific. That is, CMAKE_SYSTEM_PROCESSOR will be set to aarch64 on Linux and Android, arm64 on Mac, and ARM64 on Windows. On Linux I'm not sure if this is provided by uname or by the gcc triple.

CMake itself is unlikely to evaluate the value of this variable, but when it does, it does consider all possible "conventional" values unless there are other constraints like the ones below:

• FindCUDA.cmake when cross-compiling assumes Linux, Android or QNX, but not Windows (or macOS from back in the day) - so it uses aarch64.
• FindMatlab.cmake uses arm64 for a conditional that only runs on macOS.

When cross-building, it's can be entirely arbitrary - but for a well-known cpu architecture you probably want to use a pre-existing convention, rather than a new one.

The robust way of evaluating CMAKE_SYSTEM_PROCESSOR against armv8 would be something along the lines of -

• For armv8: if (CMAKE_SYSTEM_PROCESSOR MATCHES "arm64|ARM64|aarch64.*|AARCH64.*")
• For "intel" (32 or 64): if(CMAKE_SYSTEM_PROCESSOR MATCHES "x86|x86_64|AMD64|amd64|i386|i686")

Could this change be considered breaking if users are evaluating the current armv8 value in their scripts already?

I'd say it's very unlikely that user scripts are evalauting armv8 because unlike armv7, for 64-bit ARM the other 3 options are used. From a quick search in Github, in fact some scripts would interpret armv8 as generic arm (32-bit arm, or armv7) given the way some conditionals are constructed (check first for 64-bit arm, and if not, anything that starts with "arm" assume as armv7). So I'd say that this PR is good because it moves it closer to what is used and assumed in CMake scripts, but in the future we may want to consider that this variable needs to have a value conditional on the OS.

[memsharded]

Hi @bavardage

I have gone with the insights of @jcar87 and implemented a per-OS mapping for the armv8 architecture, I think it can be a bit less risky given the ecosystem state.

Please let me know what you think.

[bavardage]

that makes sense - per OS seems like the way to go!

[jasal82]

@memsharded Could you please backport this to 1.x as well?