Repository navigation
Conversation
Genesis-AI's fork of taichi: a scikit-build-core C++ compiler with an LLVM JIT CPU backend. Compared with the parked taichi entry, two of taichi's three walls are gone here: quadrants targets LLVM 22.1.0 (opaque pointers; RuntimeDyldELF has real RISC-V relocation handling since LLVM 20, confirmed directly against llvmorg-22.1.0 source: 42 riscv hits, a real resolveRISCVRelocation()) and finds clang via clang-22/21/20. The remaining wall is quadrants having no riscv64 CPU arch and no riscv64 LLVM to build against: - patches/quadrants/1.3.3/0001 adds a riscv64 CPU arch alongside x64/arm64 everywhere they're handled (CXXFlags, the arch enum, rhi/arch.cpp, and four scattered "is this a CPU arch" checks in the LLVM codegen/transforms). - 0002/0003 patch the CI build scripts: no riscv64 LLVM/sccache release exists to download, so setup_llvm() expects LLVM_DIR to already point at the LLVM we build ourselves, setup_sccache() no-ops (ccache from the manylinux image covers it instead), CUDA/ AMDGPU/Vulkan (no riscv64 backend for any of them) are turned off, and the dev dependency group is trimmed to what the build actually needs (full --group dev pulls pyright, which has no riscv64 wheel or sdist). build-quadrants.yml builds LLVM+clang 22.1.0 from source once (RISCV target only, matching build-libclang.yml's from-source precedent but also linking OrcJIT/ExecutionEngine/RuntimeDyld, which libclang.so doesn't need), then reuses it across the cp310/cp311/cp312/cp313 matrix - mirroring upstream's own manylinux_wheel.yml scripts (1_prerequisites.sh/2_build.sh/3_check.sh) almost verbatim, pointed at our own LLVM instead of their quadrants-sdk-builds releases. GCC (not our built clang) still compiles the bulk of the project, same as upstream; clang only compiles the LLVM JIT's runtime.cpp bitcode, and the main library links the static LLVM libraries GCC-side, which is an ordinary cross-compiler-ABI link on Linux. No gpl_sources job: the build doesn't statically link libstdc++ into the wheel (that flag is MinGW-only in QuadrantsCXXFlags.cmake), and glibc-based manylinux auditwheel doesn't bundle it either.
jobs.<job_id>.container and jobs.<job_id>.name don't have the env
context available (only github/needs/strategy/matrix/inputs/vars), so
${{ env.MANYLINUX_RISCV64_IMAGE }} in container: and ${{ env.LLVM_VERSION }}
in a job name failed workflow validation outright (zero jobs scheduled,
run marked failed). Hardcode the image literal in both container
blocks, matching build-openmm.yml/build-syntaqlite.yml, and drop the
now-unused MANYLINUX_RISCV64_IMAGE workflow env (LLVM_VERSION stays -
run/with contexts do have env available).
luhenry
added a commit
that referenced
this pull request
Oct 15, 2026
luhenry
marked this pull request as draft
October 15, 2026 12:13
All four riscv64 build legs (cp310-cp313) failed identically in
1_prerequisites.sh's `pip install "cmake<4.0.0" ...` with:
-- Could NOT find OpenSSL ...
CMake Error at Utilities/cmcurl/CMakeLists.txt:772 (message):
Could not find OpenSSL. Install an OpenSSL development package ...
ERROR: Failed building wheel for cmake
With PIP_EXTRA_INDEX_URL set, pip resolves the highest version
satisfying a constraint across both the public index and ours, and
an sdist-only candidate still counts as resolvable. PyPI's cmake
publishes no riscv64 wheel for any release (checked its JSON: only
macOS/Windows/manylinux x86_64/aarch64/ppc64le/s390x/armv7l and
musllinux), and the newest release under "<4.0.0" at the time of
this PR, 3.31.10, is newer than the 3.31.6 we mirror -- so pip picked
3.31.10's sdist over our riscv64 wheel and tried to build CMake
itself from source, which fails configuring its bundled cmcurl for
lack of OpenSSL dev headers in the manylinux_riscv64 image.
Pin to "cmake==3.31.6", the exact version docs/packages/cmake.yaml
publishes a manylinux_2_39_riscv64 wheel for (same fix shape as
patches/ouster-sdk/1.0.1/0002-build-use-a-cmake-release-with-a-riscv64-wheel.patch,
the porting skill's gotcha 30: "the version has to line up, not
just the name").
1_prerequisites.sh ran `yum install -y ccache` on riscv64, but ccache is EPEL-only on RHEL derivatives and manylinux_2_39_riscv64 ships no EPEL (gotcha 51), so every interpreter leg failed with "Unable to find a match: ccache". Upstream never installs ccache; drop the line and build uncached, and update the sccache.py comment in 0002 that relied on it.
luhenry
force-pushed
the
port/quadrants
branch
from
November 9, 2026 05:57
304da06 to
51092e0
Compare
_publish-wheel.yml now requires a matrix input (main's "publish: Validate effective wheel targets"), but this PR branch forked before that landed and quadrants has never been merged to main, so build-quadrants.yml never picked up the matching one-line update every already-published package's workflow got. The merge ref combines the new required-input _publish-wheel.yml with this branch's old build-quadrants.yml, so any run has failed startup with "Input matrix is required, but not provided". Pass it the same way the mass-update commit did for every other package's publish job.
Runs 42731185766's cp311 and cp313 build jobs both failed CMake configure identically: "Commit" printed blank and "CMake Error at CMakeLists.txt:35 (string): string sub-command STRIP requires two arguments.", followed later by "Configuring incomplete, errors occurred!" (cp310 and cp312 failed earlier in the same run, to an LLVM artifact download timeout and a GitLab submodule-fetch overload respectively -- unrelated transient infra, rerun rather than patched). 1_prerequisites.sh's riscv64 branch dropped the upstream `git config --global --add safe.directory /__w/quadrants/quadrants` call outright instead of replacing it, reasoning that the hardcoded path doesn't match our checkout layout. But this job runs inside a `container:`, which doesn't see the safe.directory entry actions/checkout already added to the *runner's* own host gitconfig; without an equivalent here, the `git` this script installs refuses every command against the checkout as "dubious ownership" -- including CMakeLists.txt's own `git rev-parse` for the build's commit string, which swallows that failure and leaves the variable unset instead of erroring, surfacing two lines later as the STRIP argument error instead. Add the safe.directory call back on riscv64, pointed at $GITHUB_WORKSPACE (our actual checkout path, under any job's container) instead of upstream's hardcoded one.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
quadrants1.3.3Genesis-AI's scikit-build-core fork of taichi: a C++ compiler with an LLVM JIT CPU backend. Upstream publishes no riscv64 wheel.
Mirrors upstream's
manylinux_wheel.yml.Differs from upstream
--group devtrimmed to the build-only subset - full group pulls pyright, which has no riscv64 wheel/sdistTesting
qd.init(arch=qd.cpu)only - upstream's pytest suite (tests/run_tests.py) is deferred to a follow-upLicense: OK
Patches
0001-Add-a-riscv64-CPU-arch.patch- To upstream. Adds riscv64 to the CPU-arch enum; without it CMake FATAL_ERRORs on an unknown processor.0002-CI-support-riscv64-in-the-LLVM-sccache-manylinux-build-scripts.patch- Inappropriate [no riscv64 LLVM/sccache release exists]. Wires our from-source LLVM in and turns off the nonexistent GPU backends.0003-CI-trim-riscv64-dev-group-install-and-drop-submodule-reinit.patch- Inappropriate [riscv64 has no pyright wheel].pip install --group devotherwise fails outright.First riscv64 attempt; CI running at the time of this PR, see checks for current status.