[vcpkg] Add universal builds for macOS

[omartijn]

Describe the pull request

This yields binaries which work on either platform, making it easier for end-users, since they don't have to be aware on which architecture they are running.

• What does your PR fix?

It adds a triplet allowing universal builds on macOS

• Which triplets are supported/not supported? Have you updated the CI baseline?

Added universal-osx and universal-osx-dynamic`, both as community triplets.

• Does your PR follow the maintainer guide?

Yes

• If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

N/A

[autoantwort]

I think this only works for cmake ports. For example openssl is only arm64 with this triplet

[omartijn]

Yes, there are many ports where this won't work. Another example of this was ffmpeg, for which a custom build-script was written to enable this functionality. Maybe we can find a way to make this more generic.

Given the number of ports, it's unfeasible to find and fix all of them without adding this triplet as an official triplet, having it run through the CI and then fixing all the ones that fail.

[autoantwort]

I think all ports that don't use cmake will fail, or they build fine but they only create libs for arm64 which should be an error.

Imho before this get merged https://github.com/microsoft/vcpkg-tool/pull/163 should be merged to ensure that the libs have the right architecture (and extend https://github.com/microsoft/vcpkg-tool/pull/163 to support universal builds).

[ras0219-msft]

I think we need to wait on considering this until we have actual testing in the tool binary to ensure the produced binaries are correct.

[ras0219-msft]

This requires a long term strategy for how we intend to handle MacOS universal binaries. This problem is not simple, because we need to consider cases like assembly code, chip-specific optimizations, and fortran.

[JonLiu1993]

Draft this PR since it seems that no progress is being made.

[BillyONeal]

This requires a long term strategy for how we intend to handle MacOS universal binaries. This problem is not simple, because we need to consider cases like assembly code, chip-specific optimizations, and fortran.

@JavierMatosD @valeriaconde @ras0219-msft @vicroms and I discussed this today and decided to close this because there is necessary feature work necessary, like what Robert described above. (For example, at a minimum post-build checks need to be fixed to enforce that the output actually contains both architectures so that we aren't 'lying') If you want to continue working in this direction adding things like that will bring this closer to reality.