Repository navigation
ci: build and test riscv64 wheels - #249
Conversation
Now that cibuildwheel and PyPI support riscv64, we can start building riscv64 wheels. Integrated in the same way as the other emulated architectures (aarch64, ppc64le), running on the x86_64 runner via QEMU emulation, skipping test. Signed-off-by: Julien Stephan <[email protected]>
|
I am upstreaming this as part of our work with RISE (https://riseproject.dev/) to promote riscv64 support in the Python ecosystem. We already build, deploy and test a riscv64 wheel for python-rapidjson: https://pypi.riseproject.dev/project/python-rapidjson/#python-rapidjson FYI, here are the actions on my personal fork:https://github.com/justeph/python-rapidjson/actions/runs/38739308609 |
|
FYI, RISE provides free native RISC-V GitHub Actions runners (https://riseproject.dev/2026/03/24/announcing-the-rise-risc-v-runners-free-native-risc-v-ci-on-github/). Happy to update this PR to build on a native riscv64 runner instead of emulating via QEMU, if that's preferred. |
|
Thanks. Before merging, help me understand your last offer about "native riscv64": is there a free runner on GH? In other words, why would one prefer the emulated solution over the native one? 😇 |
Good question :) Native riscv64 runners are provided for free by RISE as a third-party app that you need to install on your GitHub account/org. Some maintainers prefer the emulated solution to avoid relying on third-party runners. By default, we try to open PRs using QEMU if the project already uses it for other architectures (such as aarch64, ppc64le, etc.), which is your case. Adding QEMU comes with an execution-time overhead, but pipelines already using it have this overhead anyway. We tend not to introduce it into pipelines that don't already use QEMU. |
Now that cibuildwheel and PyPI support riscv64, we can start building riscv64 wheels.
Integrated in the same way as the other emulated architectures (aarch64, ppc64le), running on the x86_64 runner via QEMU emulation, skipping test.