Wheels built with RISC-V support, and other architectures generally
See original GitHub issueI have a dependency (https://github.com/m-labs/artiq) that depends on llvmlite – however, it requires LLVM to be built with RISC-V support. The wheels that numba distribute on pypi.org are not built with this support.
This isn’t a request for numba to start releasing wheels with target support for any architecture users ask for – I’m aware that it might be a lot of maintenance work. I also understand that adding support for more target architectures may also make the already large wheels larger than desirable. My understanding of PEP440 is that it wouldn’t be possible to have version numbers like 0.37.0-risc-v either – so the question of how to manage separate wheels built for different architectures would also be an issue.
I’m curious if numba has any guidance or suggestions on how people have handled such issues in the past. I think perhaps M-Labs might have chosen to create a llvmlite-riscv project on pypi.org and made that their dependency – and indeed, I could do the same.
I may also create a private fork of llvmlite within my organisation, that builds and deploys a wheel to our private PyPI server.
Any suggestions or knowledge on how other teams might have handled this are welcome 🙂 thank you.
Issue Analytics
- State:
- Created 2 years ago
- Comments:20 (11 by maintainers)

Top Related StackOverflow Question
For all use cases I’m aware of adding 7MB to the size of llvmlite would be un-noticeable (e.g. a CUDA toolkit package installed in the env weighs in at several hundred MB) so I’d be really happy to see the addition of all targets, and to have llvmlite as an easy platform for playing with generating assembly code for other targets.
@stuartarchibald has suggested just turning on all the default LLVM targets, which are (for LLVM 11):
AArch64, AMDGPU, ARM, BPF, Hexagon, Mips, MSP430, NVPTX, PowerPC, Sparc, SystemZ, X86, XCore. We can add back in RISCV, and we also have webassembly turned on as an experimental target already (it apparently becomes a regular target in LLVM 13).I’m checking now how much that increases the size of the package, but I suspect it won’t be a big deal.