[vcpkg scripts] toolchain/osx: Fix CMAKE_HOST_SYSTEM_PROCESSOR condition with lower case arm64

[WangWeiLin-MV]

Fix #40474

CMake STREQUAL is case-sensitive, change ARM64 to arm64 https://cmake.org/cmake/help/latest/variable/CMAKE_APPLE_SILICON_PROCESSOR.html

[WangWeiLin-MV]

Additional

There is an issue that it seems that this optimization has not taken effect:

• The host dependency will still build
• In port file, VCPKG_CROSSCOMPILING is still 1 (TRUE). So the port still requires being passed tools path for running.
• In toolchain file, CMAKE_CROSSCOMPILING is set to empty. The package will build tools, and the passed tool path will be ignored.

Currently, the additional host dependencies could be avoided by specifying --host-triplet to same with target triplet. However, this method will fail if the host dependency does not support the target architecture, for example arm64.

Possible impact: When the option --host-triplet is set same with target, CMAKE_CROSSCOMPILING is TRUE while VCPKG_CROSSCOMPILING is FALSE.

---

Quote from previous discussion #40474 (comment)

If the port does not depend on CMAKE_CROSSCOMPILING and depend independent tools port or provide options, then the original issue could be easily solved:

Just add both host and target tools.

${CURRENT_HOST_INSTALLED_DIR} will point to the correct host program.
The additional target-triplet tools are available to users
Just like -DPKG_CONFIG_EXECUTABLE=${PKGCONFIG}.

Some ports do not provide options, and builds many internal tools in-place, it could be better handled by upstream for that difference behavior of cross-compiling.

---

Example from https://web.archive.org/web/20240813003145/https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html

if(CMAKE_CROSSCOMPILING)
   find_package(MyGen)
else()
   add_executable(mygen gen.c)
   export(TARGETS mygen FILE
          "${CMAKE_BINARY_DIR}/MyGenConfig.cmake")
endif()

add_custom_command(
  OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/generated.h"
  COMMAND mygen -o "${CMAKE_CURRENT_BINARY_DIR}/generated.h"
  )

---

Reference

• [vcpkg/toolchain] set CMAKE_SYSTEM_PROCESSOR for arm on windows #16111
• [toolchain windows] set CMAKE_SYSTEM_PROCESSOR #24100
• Don't unset CMAKE_CROSSCOMPILING when cross-compiling to linux #37734
• https://devblogs.microsoft.com/cppblog/vcpkg-host-dependencies/
• https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html

[dg0yt]

I see that the old line didn't make sense, but the new behaviour might not be desired either. Basically, I would suggest to let a cross build be a cross build.

At least for ports, there are no CPU-based short-cuts. When the target triplet is different from the host triplet, it is "host": true, !native, in manifest, and VCPKG_CROSSCOMPILING, in portfile. So when this line is reached for the target triplet, the host tools are already built.

[WangWeiLin-MV]

I see that the old line didn't make sense, but the new behaviour might not be desired either. Basically, I would suggest to let a cross build be a cross build.

In that case, it will make "CMAKE_CROSSCOMPILING" true even if "--host-triplet" is specified.

[dg0yt]

In that case, it will make "CMAKE_CROSSCOMPILING" true even if "--host-triplet" is specified.

This particular toolchain file sets CMAKE_CROSSCOMPILING to OFF for a case which might looks like meant for target_triplet == host_triplet:

vcpkg/scripts/toolchains/osx.cmake

Lines 44 to 46 in 2f210a9

	if(CMAKE_HOST_SYSTEM_NAME STREQUAL "Darwin")
	if(CMAKE_SYSTEM_PROCESSOR STREQUAL CMAKE_HOST_SYSTEM_PROCESSOR)
	set(CMAKE_CROSSCOMPILING OFF CACHE STRING "")

But vcpkg doesn't control CMAKE_HOST_SYSTEM_PROCESSOR... but CMake does, for macOS: https://cmake.org/cmake/help/latest/variable/CMAKE_HOST_SYSTEM_PROCESSOR.html#macos-platforms

I can't tell how far one would get with running x64 build tools on arm64 osx but this would clearly remove the crosscompiling from targeting x64 osx.

And everything else could be subeject to a specific toolchain instead of vcpkg's generic one.

[dg0yt]

Given that it didn't work in the past, I would prefer to not introduce it now.

[WangWeiLin-MV]

After not setting CMAKE_CROSSCOMPILING empty, x86-windows fails with 24 error ports and 76 cascaded ports.

SUMMARY FOR x86-windows
SUCCEEDED: 2138
BUILD_FAILED: 24
POST_BUILD_CHECKS_FAILED: 1
CASCADED_DUE_TO_MISSING_DEPENDENCIES: 76

It is basically be caused that these packages have different behavior depending on the variable CMAKE_CROSSCOMPILING.

Temporarily suspended modifications.

[dg0yt]

This is expected. The x86 windows hack hides the poor cross-build capabilities of several ports. The android triplets where the first real cross builds in CI.

[BillyONeal]

This was intentionally changed in #26240 with the expectation that arm64 macs can run x64 tools, and setting it to off can allow some ports to work that would not otherwise. It isn't clear to me that rolling this change back as this PR does will lead to a better user experience; in particular, it isn't clear that it fixes the original reported issue in #40474 .

Is the real problem that we need to supply a native arm64 cmake?

When cross compiling, setting CMAKE_CROSSCOMPILING to empty leads confusion.

set(CMAKE_CROSSCOMPILING OFF CACHE STRING "")

sets CMAKE_CROSSCOMPILING to OFF, not "empty". The "" is the "doc string"

[BillyONeal]

@AugP @vicroms @JavierMatosD @data-queue @ras0219-msft We aren't sure how this change fixes the problems described in #40474 and agree with the original design intent clearing CMAKE_CROSSCOMPILING at this time. That said, if it's better explained why this fixes the original problem, we would consider changing the existing CMAKE_CROSSCOMPILING design.

[BillyONeal]

Speaking personally, I think if we were to make this change on macOS we should make similar changes for Windows, and that is going to break a lot of users. So we need a big carrot to go with that stick.

[WangWeiLin-MV]

This is expected. The x86 windows hack hides the poor cross-build capabilities of several ports. The android triplets where the first real cross builds in CI.

Speaking personally, I think if we were to make this change on macOS we should make similar changes for Windows, and that is going to break a lot of users. So we need a big carrot to go with that stick.

As @dg0yt said, there are many ports depends on this hack for x86 windows. I'll try to fix these portability issues.

---

We aren't sure how this change fixes the problems described in #40474

I'll change this PR to fix the original issue.

[WangWeiLin-MV]

Failed ports on x86-windows cross compiling

• ampl-asl:x86-windows [ampl-asl] Update to 20240201 and disable generated header when cross-compiling #40958
• aws-sdk-cpp:x86-windows
• blas-test:x86-windows
• clamav:x86-windows
• cmake-user:x86-windows
• cppmicroservices:x86-windows
• dcmtk:x86-windows
• discount:x86-windows
• fastrtps:x86-windows
• forge:x86-windows
• gamedev-framework:x86-windows
• halide:x86-windows
• itk:x86-windows
• kf5plotting:x86-windows
• kf5sonnet:x86-windows
• kf5syntaxhighlighting:x86-windows
• kfr:x86-windows
• lapack-test:x86-windows
• libfreenect2:x86-windows
• ois:x86-windows
• openblas:x86-windows
• opencc:x86-windows
• plplot:x86-windows
• qtactiveqt:x86-windows
• salome-medcoupling:x86-windows
• torch-th:x86-windows
• vulkan-loader:x86-windows

[BillyONeal]

Thanks to @JavierMatosD for testing this on an arm64 macOS device for me. It fixes things to have the intended behavior for him.

[dg0yt]

And it makes vcpkg build host tools for the arm64-osx host triplet but not reliably use them when targeting x64-osx, leaving more port bugs hidden.
(Yes, I still think these lines should be removed!)

[WangWeiLin-MV]

@dg0yt Except the ports that can be disabled cross-compiling check, for the other ports that require tools to be compiled and run in-place , we will try make these depend on their own host ports. Subsequent fixes will be updated in the list above for the time being.

[dg0yt]

I don't believe this will happen.
This PR added a shortcut which wasn't needed in the past, and it shouldn't be needed in the future. Except for hiding poor port quality.