[3nids]

Stacked on #300, which is stacked on #299. This PR's base is #300's branch, cross-python3-target-dep.

The macOS workflow now builds x64-osx-dynamic on an arm64 runner with --host-triplet=arm64-osx-dynamic, instead of natively on macos-15-intel. The x64 target tools run under Rosetta. Both macOS jobs run on macos-26, so they use the same Xcode and the cross job reuses the arm64 host packages that the native arm64 job puts in the binary cache.

Required checks: the job names change, so the ruleset on main needs updating when this is merged:

• build (macos) (macos-15, arm64-osx-dynamic) → build (macos) (macos-26, arm64-osx-dynamic)
• build (macos) (macos-15-intel, x64-osx-dynamic) → build (macos) (macos-26, x64-osx-dynamic, arm64-osx-dynamic)

Workflow

• Matrix: native arm64-osx-dynamic, and x64-osx-dynamic with host-triplet: arm64-osx-dynamic.
• An "Install Rosetta" step, only for the cross row.
• "Build release only" also applies to the host triplet.
• --host-triplet=${{ matrix.host-triplet || matrix.triplet }}.
• The log upload only takes the top-level port logs. Recursing into the source trees hit py-meson's symlink cycle (ELOOP).
• The adbc ports are built again.
• vcpkg baseline bumped to 22f58896. It has the gmp fix for cross builds ([gmp] Keep the -arch flag when assembling on macOS microsoft/vcpkg#54894) and the arrow-adbc fix for fmt 12 ([arrow-adbc] Fix the postgresql feature with fmt 12 microsoft/vcpkg#54910).

Ports

In a native build the host and target are the same, so these change nothing there.

• py-meson: passes the triplet's compiler flags to meson, and lets meson run x64 test programs on arm64 macOS.
• vcpkg-python-scripts:
  • The import test runs with the target interpreter.
  • When the target interpreter builds a wheel, the target site-packages come before the host ones.
• Target dependencies: ports whose build imports a tool with compiled modules (Cython, numpy, cffi, ...) in the target interpreter now also depend on it as a target dependency. The host's arm64 build can't be loaded by the x64 interpreter. A few ports also had missing host build dependencies or runtime requirements.
• py-fonttools: always builds the Cython extensions. Before, it built them only if another port happened to install Cython first.
• arrow: pyarrow is built with the vcpkg toolchain on macOS. Otherwise a cross build compiles it for the host architecture, with the host's SIMD flags.
• py-contourpy: builds with meson-python and pybind11. The port had never built.
• py-matplotlib: passes the Objective-C compiler to meson, and depends on contourpy and packaging.

Testing

• The CI list passes in the cross job on macos-26 (runs on cross-ci before this cleanup).
• Locally, the same list plus the Python packages from QGIS's manifest (about 330 packages) was cross-built on arm64 macOS 26. Every binary in the x64 tree is x86_64, and a runtime check passes under Rosetta: numpy through geopandas, rasterio, matplotlib, pyarrow, duckdb, ADBC and others.

[m-kuhn]

is this pattern something we plan to continue to use and if yes in what situation?

[3nids]

this is just for testing this here, I will drop that when we merge

[m-kuhn]

should we replace the existing intel workflow with this one?

[m-kuhn]

Should we run this already on macos-26?

[3nids]

will do

[m-kuhn]

todo