[icu] fix mac os x64 build on apple arm

[autoantwort]

Describe the pull request

• What does your PR fix? Fixes [qt-base] build failure (icu is build for arm with x64-osx triplet) #16424

That was the only successful way to generate x64 binaries on an arm mac. I tried many different approaches but that one was the only successful one. See here.

[autoantwort]

I could image that another solution is to cross build from arm to x64 on mac, but than you need icu installed for the host triplet, so that solution is only possible when #15424 gets merged.

[autoantwort]

Can you rerun the pipeline? The mac machine was offline.

[azure-pipelines]

Commenter does not have sufficient privileges for PR 16433 in repo microsoft/vcpkg

[ras0219-msft]

Let me know what path you'd like to take with this PR.

[ras0219-msft]

It seems like -arch x86_64 should be part of the target CFLAGS. We might want to look at using

https://github.com/microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_internal_get_cmake_vars.cmake

to compute the right flags. Otherwise, this PR looks like an acceptable incremental improvement.

[autoantwort]

Let me know what path you'd like to take with this PR.

I think the host triplet way is a better one. It will also make cross compiling from linux -> windows possible and other cross compiling scenarios. The only downside to my understanding is that you build the port twice if you are using for example the triplet x86-windows (x86-windows + x64-windows)

[autoantwort]

Ok currently #16504 prevents a solution with host triplets on macs.

[JackBoosY]

@autoantwort It looks like we have to fix issue #16504 first.

[ras0219-msft]

From #16504 (comment):

As a workaround, you can set VCPKG_HOST_TRIPLET as an environment variable or pass --host-triplet= on the command line to change which triplet to use as the host.

[ras0219-msft]

While we would need to build the port "twice":

1. We need to build the port twice anyway if we need a different host port that depends on icu
2. We can avoid building the "tools" part in the cross-compiled port, which hopefully means the total build time won't be 2x

[autoantwort]

We can avoid building the "tools" part in the cross-compiled port

Some of the tools are needed to cross compile and I don't know if you can only build the tools needed for cross compiling.

I think this can be closed in favour of #16577