Skip to content

[WIP] Wheels: ARM64 builders for Linux & Windows#1909

Open
ax3l wants to merge 4 commits into
openPMD:wheelsfrom
ax3l:wheels-arm64-linux-win
Open

[WIP] Wheels: ARM64 builders for Linux & Windows#1909
ax3l wants to merge 4 commits into
openPMD:wheelsfrom
ax3l:wheels-arm64-linux-win

Conversation

@ax3l

@ax3l ax3l commented Jul 3, 2026

Copy link
Copy Markdown
Member

Travis-CI is dead; it was the only builder for Linux aarch64 (and ppc64le) wheels. GitHub now offers free native ARM runners for public repos, so move Linux ARM wheel production into build.yml and add Windows ARM64 (new platform).

build.yml:

  • Linux aarch64 on ubuntu-24.04-arm: full parity with x86_64 (cp310-cp314, many+musl, ADIOS2 ON), reuses library_builders.sh unchanged (native aarch64 needs no SIMD/cross tweaks; blosc2 auto-selects NEON, HDF5 builds natively).
  • Windows ARM64 on windows-11-arm: cp311-cp314 (CPython win_arm64 exists only from 3.11+, no PyPy). First cut ships HDF5 + JSON only (ADIOS2 OFF), like the win32/i686 legs, to avoid an unproven ADIOS2-on-ARM64 build.
  • Smoke test: derive the ADIOS2 expectation from matrix.env.ADIOS2 instead of process bitness, so a 64-bit ARM wheel without ADIOS2 passes; also makes the i686/win32 legs explicit.
  • Retarget the retired Travis aarch64/ppc64le matrix comments.

library_builders.bat:

  • Gate the ADIOS2 dependency chain (SQLite3, ZFP, C-Blosc2, ADIOS2) behind openPMD_CMAKE_openPMD_USE_ADIOS2==ON (visible in the before-build step); keep zlib + HDF5 unconditional. Windows ARM64 builds only zlib + HDF5; AMD64 unchanged (win32 stops building the ADIOS2 stack it already discarded).

.travis.yml:

  • Sync to the current post4 patch and cibuildwheel 4.1.0 (kept as reference; Travis no longer runs).

Travis-CI is dead; it was the only builder for Linux aarch64 (and ppc64le)
wheels. GitHub now offers free native ARM runners for public repos, so move
Linux ARM wheel production into build.yml and add Windows ARM64 (new platform).

build.yml:
- Linux aarch64 on ubuntu-24.04-arm: full parity with x86_64 (cp310-cp314,
  many+musl, ADIOS2 ON), reuses library_builders.sh unchanged (native aarch64
  needs no SIMD/cross tweaks; blosc2 auto-selects NEON, HDF5 builds natively).
- Windows ARM64 on windows-11-arm: cp311-cp314 (CPython win_arm64 exists only
  from 3.11+, no PyPy). First cut ships HDF5 + JSON only (ADIOS2 OFF), like the
  win32/i686 legs, to avoid an unproven ADIOS2-on-ARM64 build.
- Smoke test: derive the ADIOS2 expectation from matrix.env.ADIOS2 instead of
  process bitness, so a 64-bit ARM wheel without ADIOS2 passes; also makes the
  i686/win32 legs explicit.
- Retarget the retired Travis aarch64/ppc64le matrix comments.

library_builders.bat:
- Gate the ADIOS2 dependency chain (SQLite3, ZFP, C-Blosc2, ADIOS2) behind
  openPMD_CMAKE_openPMD_USE_ADIOS2==ON (visible in the before-build step); keep
  zlib + HDF5 unconditional. Windows ARM64 builds only zlib + HDF5; AMD64
  unchanged (win32 stops building the ADIOS2 stack it already discarded).

.travis.yml:
- Sync to the current post4 patch and cibuildwheel 4.1.0 (kept as reference;
  Travis no longer runs).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Comment thread .github/workflows/build.yml Outdated
Comment thread .github/workflows/build.yml Outdated
Comment thread library_builders.bat Outdated
ax3l and others added 3 commits July 2, 2026 21:20
Historic character comments are confusing and unnecessary.

Co-authored-by: Axel Huebl <axel.huebl@plasma.ninja>
The first windows-11-arm run failed: openPMD's setup.py picks the Visual
Studio generator platform from interpreter bitness only
(`if sys.maxsize > 2**32: -A x64`), so on win-arm64 (64-bit interpreter,
ARM arch) it passed `-A x64`. That mis-targeted the build and find_package
(Python) then failed ("Could NOT find Python ... Interpreter"). The explicit
-A also overrode any CMAKE_GENERATOR_PLATFORM env (which is why win32 works:
its 32-bit interpreter skips the branch and lets the env drive -A).

- setup-py-windows-arm64-platform.patch: honor CMAKE_GENERATOR_PLATFORM from
  the environment for -A, falling back to the existing x64/interpreter logic.
- build.yml: add the patch to COMMON_PATCHES and set
  CMAKE_GENERATOR_PLATFORM=ARM64 on the windows-11-arm leg.

Dependency builds (zlib + HDF5) and the ADIOS2-chain gating already worked on
ARM64; this only fixes the openPMD wheel's own configure step.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
With the -A ARM64 fix the windows-11-arm wheels build and pass tests (HDF5 +
JSON round-trip, 0 external deps), but the job failed at upload: the artifact
name wheels-${os}-${build||arch} interpolated this leg's build glob
("cp311-* cp312-* ..."), and '*'/spaces are invalid in an artifact name.

Add an optional matrix.artifact override (default: build || arch) and set it to
"ARM64" for the windows-11-arm leg -> wheels-windows-11-arm-ARM64.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant