Skip to content

tensorstore: add build-tensorstore.yml for riscv64 wheels - #1865

Open
luhenry wants to merge 7 commits into
mainfrom
tensorstore
Open

luhenry wants to merge 7 commits into
mainfrom
tensorstore

Conversation

@luhenry

@luhenry luhenry commented Sep 12, 2026

Copy link
Copy Markdown
Member

Bazel-built C++ library for reading/writing large multi-dimensional arrays, exposed as a Python extension. Upstream publishes no riscv64 wheel.

Mirrors upstream's build.yml, driving the container directly instead of the cibuildwheel CLI so a bootstrapped bazel binary and the per-interpreter loop stay under our control.

Differs from upstream

  • Bazel bootstrapped from the bazel-8.5.1-dist.zip dist archive - bazelisk publishes no riscv64 binary.
  • TENSORSTORE_BAZELISK points at a thin exec shim around that binary instead of bazelisk.py.
  • Wheels built with a docker run loop over interpreters instead of the cibuildwheel CLI, so the Bazel bootstrap step is shared and cached.
  • SETUPTOOLS_SCM_PRETEND_VERSION_FOR_TENSORSTORE pins the version - applying the patches below leaves the checkout dirty, which setuptools_scm otherwise reads as a post-release dev build.
  • --local_ram_resources=HOST_RAM*.5 keeps bazel from oversubscribing memory on the shared riscv64 runner pool.

Matrix: cp311, cp312, cp313, cp314, cp314t - matches upstream's own Linux build matrix (requires-python >= 3.11).

Testing

  • same as upstream, minus the exact python_test_requirements_frozen.txt pins (numpy 2.4.6 / ml-dtypes 0.5.4 have no riscv64 wheel on our registry yet).

License: OK

Patches

  • 0001-Add-riscv64-support-to-the-dav1d-Bazel-BUILD-wrapper.patch - To upstream (google/tensorstore). Vendored dav1d BUILD file select()s only branch on arm64/ppc/x86_64, failing bazel analysis on riscv64. Reproduces riscv64-only.
  • 0002-Add-a-riscv64-default-to-libaom-s-header-select.patch - To upstream (google/tensorstore). Same gap in vendored libaom's header select(), pulled in transitively via the avif image driver. Reproduces riscv64-only.
  • 0003-Unpin-the-hermetic-numpy-fetch-used-for-building-hea.patch - Inappropriate. Bazel's own pip-install repo rule hash-pins a numpy version with no riscv64 wheel anywhere, so it times out building it from source; drops the pin so it resolves to our registry's wheel. Reproduces riscv64-only.
  • 0004-Ship-zlib-s-cpu_features.c-.h-on-every-arch-not-just.patch - To upstream (google/tensorstore). Vendored zlib BUILD file only ships cpu_features.c/.h on arm64/x86_64, but three base zlib sources include it unconditionally; affects any non-arm64/x86_64 target, riscv64 included.

luhenry added a commit that referenced this pull request Sep 12, 2026
…cm version

git apply leaves the tensorstore checkout dirty, which setuptools_scm reads
as a post-release dev build; pin it explicitly with
SETUPTOOLS_SCM_PRETEND_VERSION_FOR_TENSORSTORE instead.
…red riscv64 runner pool

The previous run's self-hosted runner lost communication with the server
partway through the build step (GitHub annotation: CPU/memory starvation),
while three other packages' builds were running concurrently on the same
runner pool. --local_ram_resources=HOST_RAM*.5 throttles bazel's own action
scheduling so it doesn't assume the whole host is available to it.
…n riscv64

Bazel's own pip-install repository rule has no riscv64 wheel for the
hash-pinned numpy==2.4.6 anywhere, so it falls back to a from-source build
that blows past its 600s default timeout. PIP_ONLY_BINARY=numpy plus the
patch keep it on our registry's prebuilt wheel instead.
…m64/x86_64

adler32.c, crc32.c and deflate.c unconditionally #include cpu_features.h,
but the vendored zlib.BUILD.bazel only added it to srcs for arm64/x86_64,
so any other target cpu (riscv64 included) fails with a missing-header
compile error.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant