Add an experimental Bazel build - #212
Conversation
ba5d5bc to
754518f
Compare
Add a standalone Bazel build alongside CMake (best-effort; CMake remains the supported build). Builds libcppyy-backend.so and the Python package against the shared cppyy_bazel module and @cppinterop. - MODULE.bazel wires cppyy_bazel + cppinterop; opts in to the centralized clang toolchain - BUILD.bazel: clingwrapper cc_library/solib (exceptions+rtti re-enabled) and the py_library; py_wheel packaging - best-effort, non-gating GitHub Actions workflow + README section Co-developed-with-the-help-of: Claude Code (Claude Opus 4.8)
754518f to
fe81d2a
Compare
| FORK_OWNER="conrade-ctc" # TODO: compiler-research after infra merges | ||
| FORK_BRANCH="bazel-build-upstream" # TODO: default branch after infra merges | ||
| cd "$GITHUB_WORKSPACE/.." | ||
| for repo in cppyy CppInterOp; do | ||
| git clone --depth=1 -b "$FORK_BRANCH" \ |
There was a problem hiding this comment.
Since the CppInterOp PR is in, can we update this to no longer clone the fork?
There was a problem hiding this comment.
right, I'll update all PRs... whatever order they end up merging in, i'll just keep updating appropriately, then a final clean up PR may be needed depending on the order they merged :) I think if we do cppy first, that cleans with this one all the way, but CppInterOp will need another cleanup...
There was a problem hiding this comment.
What is your preferred order of merging? I see we still point to the forks on the CppInterOp patch, so I'm not sure what the easiest way to test this is
There was a problem hiding this comment.
What is your preferred order of merging? I see we still point to the forks on the CppInterOp patch, so I'm not sure what the easiest way to test this is
Actually, best is that i update all the PRs to ref head since its best-effort, and we already know it works. I'll open another for CppInterOp to get it back to head, then you can merge in any order. I'll hit this later today when i'm back at desk.
… merged CppInterOp #1039 merged the Bazel build to compiler-research/main, so the sibling clone no longer needs the conrade-ctc fork for it. Pull CppInterOp from compiler-research/main; the rest of the stack still comes from the fork until those PRs merge. Co-developed-with-the-help-of: Claude Code (Claude Opus 4.8)
Drop the conrade-ctc fork-branch checkout for the sibling repos. The job stays best-effort/non-gating and may fail until all four Bazel PRs land on the default branches, at which point it goes green on its own — no follow-up PR needed to unwind the fork coupling. Co-developed-with-the-help-of: Claude Code (Claude Opus 4.8)
|
@aaronj0 All four Bazel PRs are ready for merge — CPyCppyy #209, cppyy-backend #212, cppyy #229, and CppInterOp #1042. Each now clones its siblings from the compiler-research default branches (no fork coupling), and the jobs are best-effort / non-gating, so they can be merged in any order: the final state is what matters, and the jobs go green on their own once all four land. No follow-up PRs needed to unwind anything. |
|
Hi @aaronj0 — the requested change is done: sibling repos are now cloned from the |
2 participants
Adds an experimental, best-effort Bazel build alongside the supported build. Builds the cppyy-backend C++ library/solib against a local LLVM/Clang tree, consuming the shared
cppyy_bazelmodule from the siblingcppyyrepo (local_path_override(... path = "../cppyy/bazel")).Not gated in CI; the existing build remains supported. Needs a local LLVM tree via
LLVM_DIR(not built by Bazel).Part of a set of 4 coordinated PRs across the cppyy stack — check out
cppyyalongside this repo and review it after cppyy (which provides cppyy_bazel).Testing
Builds the backend solib and links into the full cppyy stack, whose 23 Bazel test targets pass end-to-end.