Support building wheels for manylinux and OSX - #22
Conversation
Test Results
|
811d00b to
1b4e02d
Compare
74bb3ff to
ee821f3
Compare
ee821f3 to
3afd4f7
Compare
3afd4f7 to
de3498f
Compare
|
@vgvassilev A note: The cleanest way to do this is to have wheel-builder images on ci-workflows that provision the image and LLVM build for manylinux and OS X. I will open a PR once I have a working draft locally and update the approach here to trigger that common workflow. That can then, in principle, be reused to build wheels for any other Python package based on LLVM under compiler-research |
| archs = ["arm64"] | ||
| # eigen and boost are test-suite build deps; the LLVM toolchain is the | ||
| # llvm-wheel artifact wheels.yml stages at /opt/llvm before this runs. | ||
| before-all = "brew install eigen boost" |
There was a problem hiding this comment.
Do this assume you are using homebrew? Not everyone does use it on MacOS. I use Macports for example.
| environment = { CMAKE_ARGS = "-DLLVM_DIR=/opt/llvm/lib/cmake/llvm -DClang_DIR=/opt/llvm/lib/cmake/clang" } | ||
|
|
||
| [tool.cibuildwheel.macos] | ||
| archs = ["arm64"] |
There was a problem hiding this comment.
I know its being supported less and less, but what about MacOS intel. There is clearly appetite for it by people wanting to use cppjit (see #39 (comment))
| test-command = "python -m pip install -r requirements.txt && python .github/wheel_smoke.py && cd test && make -j$(sysctl -n hw.ncpu) PYTHON=python && python -m pytest -ra" | ||
| # 14.0 is the toolchain's own deployment floor (set at llvm-wheel build | ||
| # time); nothing brew-built ships in the wheel. | ||
| environment = { CMAKE_ARGS = "-DLLVM_DIR=/opt/llvm/lib/cmake/llvm -DClang_DIR=/opt/llvm/lib/cmake/clang", MACOSX_DEPLOYMENT_TARGET = "14.0" } |
There was a problem hiding this comment.
I'm a little confused. Where does this /opt/llvm/ build come from?
| # LLVM/Clang 21 archives, pinned by sha256) at /opt/llvm. | ||
| before-all = "bash {project}/.github/cibw_before_all_linux.sh" | ||
| # CMAKE_ARGS reaches the CppInterOp ExternalProject sub-configure. | ||
| environment = { CMAKE_ARGS = "-DLLVM_DIR=/opt/llvm/lib/cmake/llvm -DClang_DIR=/opt/llvm/lib/cmake/clang" } |
There was a problem hiding this comment.
Same to MacOS quesion about the /opt/llvm/ build
| test-command = "python .github/wheel_smoke.py" | ||
|
|
||
| [tool.cibuildwheel.linux] | ||
| archs = ["x86_64"] |
| # and linking LLVMSupport fails at generate time unless find_package(ZLIB) | ||
| # resolves, which needs zlib.h from the zlib package. | ||
| micromamba create -y -p /opt/llvm -c conda-forge 'llvmdev=21.*' 'clangdev=21.*' lld zlib | ||
| asset="llvm-wheel-21.1.8-ubuntu-24.04-x86_64-12af669f7a4444de.tar.zst" |
There was a problem hiding this comment.
I am still not sure if I understand the special llvm-wheel. How is it different from what we vendor?
There was a problem hiding this comment.
Only different in the fact that it is built on top of the manylinux pypa container to ensure it satisfies the glibc floor and "standard" build environment when building wheels. We then vendor it the same way. We will need to have a separate llvm-wheel because we can only support one LLVM version and build config per-wheel. Some projects just do it from scratch with an alma8 container such as Triton which we could adopt but this approach is more reliable since PyPA controls the image there which is well tested against Python package deployment environments.
There was a problem hiding this comment.
Does that mean that the other vendored llvms do not satisfy the libc versions?
There was a problem hiding this comment.
No because they are source built on ubuntu24 runners. We need to build on a manylinux image to publish the wheels for manylinux. Similarly we will need a new image for manylinux-aarch64
|
@mcbarton A comment: this PR is in development and some of the decisions here are still in discussion. I can request your review at a point things have converged. To answer your current questions: Yes, Intel mac support is planned but is best-effort since macOS 27 drops support for those platforms. Currently the wheels ship with macOS deployment target 14.0 (the llvm-wheel toolchain's own floor). Linux aarch64 is planned as well. The goal is to land the current wheel-building infrastructure before extending to more platforms, instead of having the entire thing arrive in one PR. That gives me a chance to verify the system before incrementally extending for more architectures (and more Python versions). Regarding homebrew for eigen/boost: that's a test-time dependency, not part of how the wheel is built. The suite's probes now cover /opt/homebrew (arm64 brew) and /opt/local (MacPorts) as of the last commit, so whichever package manager provides eigen/boost, the tests find them. On /opt/llvm: We build the llvm-wheel toolchain from compiler-research/ci-workflows on a manylinux image and OS X runner. Those archives are published on the recipe cache release (https://github.com/compiler-research/ci-workflows/releases/tag/cache) and this toolchain is staged at /opt/llvm by the 'before-all' step on linux and by the setup-recipe step in wheels.yml on macOS. I am still trying to figure out how to optimise this process further so bear that in mind. |
e94d1e6 to
afcfde2
Compare
| test-sources = ["test", "requirements.txt", ".github/wheel_smoke.py"] | ||
| test-command = "python .github/wheel_smoke.py" | ||
|
|
||
| [tool.cibuildwheel.linux] |
There was a problem hiding this comment.
@vgvassilev You can see here that the vendored LLVM is reused exactly as build args on the machine that builds the wheel. Those machines are configured in the matrix in wheels.yml:
- { os: ubuntu-24.04, label: manylinux-x86_64, arch: x86_64 }
- { os: macos-26, label: macosx-arm64, arch: arm64 }
So for every new target platform we can add a new row and extend the wheels infra. I hope this addresses your concern of any redundancy here
| - uses: actions/checkout@v7 | ||
|
|
||
| # ref pins the recipe content the cache key is computed from. | ||
| - uses: compiler-research/ci-workflows/actions/setup-recipe@main |
There was a problem hiding this comment.
Here we reuse the recipe we created with manylinux
| - uses: pypa/cibuildwheel@v4.2.0 | ||
|
|
||
| - uses: actions/upload-artifact@v7 | ||
| with: | ||
| name: wheels-${{ matrix.label }} | ||
| path: wheelhouse/*.whl | ||
|
|
||
| sdist: | ||
| name: sdist | ||
| runs-on: ubuntu-24.04 | ||
| steps: | ||
| - uses: actions/checkout@v7 |
There was a problem hiding this comment.
These are standard PyPA cibuildwheel and sdist actions required to generate the Python wheel
vgvassilev
left a comment
There was a problem hiding this comment.
I do not think I am competent enough to review this, but lgtm... @henryiii, do you mind having a look?
afcfde2 to
e327565
Compare
7e0f1aa to
e71d2df
Compare
e71d2df to
684e839
Compare
Rebased on top of #21 since we need that patch for relocatable wheels.