cmake: allow cross-CPU builds via LIBRESSL_CPU

[vszakats]

If LIBRESSL_CPU is not set, honor existing CMAKE_OSX_ARCHITECTURE for Apple targets. Then fall back to CMAKE_C_COMPILER_TARGET (typically a triplet) if set. Otherwise fall back to the value that was used before this patch: CMAKE_SYSTEM_PROCESSOR.

This allows customizing the target CPU, e.g. on Linux.

I'm not certain of the exact CMake rules for this, but on some platforms (e.g. Linux) it is not possible to override the default CMAKE_SYSTEM_PROCESSOR value by passing it to cmake via -DCMAKE_SYSTEM_PROCESSOR=... or -DCMAKE_TOOLCHAIN_FILE=... Meaning, before this patch it was not possible to build for a CPU other than the host one on Linux for example.

Also:

• simplify syntax in STREQUAL and MATCH expressions in the lines touched.
• display target CPU and ABI in the configuration phase.

[vszakats]

Tests:

• before: https://github.com/curl/curl-for-win/actions/runs/6771757681
• after: https://github.com/curl/curl-for-win/actions/runs/6775583329

[busterb]

Thanks. Does that mean the cross compile tests in this project, scripts/test, aren't doing what we thought they were with Cmake?

[vszakats]

I haven't tried that script, but after a quick look it seems to use CMAKE_OSX_ARCHITECTURES for macOS, which was fixed recently and works OK. And CMAKE_TOOLCHAIN_FILE with Windows. With Windows, CMAKE_SYSTEM_PROCESSOR override does work. The toolchain files setting it most likely also work. As for Android, I have no idea.

FWIW when the CPU was mismatched in a cross-build with ASM enabled, it manifested in clear build failures in my Linux tests.

[vszakats]

After inspecting the CMake source code ¹, it seems that if CMAKE_SYSTEM_NAME is set, CMake would allow overriding CMAKE_SYSTEM_PROCESSOR. I still have to test this and investigate what this means for all the build combinations.

Footnotes

1. https://github.com/Kitware/CMake/blob/4c52349b9e08e56bc594d10b6462f59b05d7c8c8/Modules/CMakeDetermineSystem.cmake#L184 ↩

[vszakats]

It was useful to take a second look, because the solution is to set CMAKE_SYSTEM_NAME first. Then CMake allows to override CMAKE_SYSTEM_PROCESSOR to a custom value:
https://github.com/curl/curl-for-win/actions/runs/6783897318

I run into a separate issue where arm64 made the build use arm (v4) ASM, but that's for another PR (#936). This could be fixed locally by setting aarch64 instead of arm64.

[busterb]

Thanks for digging into the logic here. This is potentially more convenient than what CMake provides out of the box. Just wanted to make sure this was solving the right problem.

[vszakats]

No worries, I was also happy to get to the root cause. I'm still not quite sure what is the CMake best-practice here though. No objection to merge this anyway, I agree it could improve the build UX.

[vszakats]

Looking into this more, a triplet doesn't work universally, because some conditions use MATCHES, and some others STREQUAL (seen with Windows) when looking for a CPU value. If you're interested in merging, let me know and I'll continue working on this (it also needs a rebase).

I think maybe the best would be to move the CPU-selection logic to the C preprocessor. This would allow to drop all this (also in autotools), while automatically adding support for building universal (multi-CPU) Apple targets.