bazel: stop carrying build files bazel-orfs can generate - #4501
Open
oharboe wants to merge 1 commit into
Open
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request removes all Bazel-related configuration and build files from the repository, including MODULE.bazel, root and subdirectory BUILD files, and design-specific Bazel targets. I have no feedback to provide as there are no review comments.
ORFS is an immutable store of reference designs, scripts, PDKs and
metadata. It is not a build system, and its CI does not run one: no
workflow in .github/workflows/ invokes bazel. Every file deleted here
exists solely for bazel-orfs, an out-of-tree consumer, which can now
generate or carry all of it.
Deleted:
56 flow/designs/<platform>/<design>/BUILD
Every one is exactly two lines of content:
load("//flow/designs:design.bzl", "design")
design(config = "config.mk")
bazel-orfs generates these for any design directory that has a
config.mk and no BUILD.
2 flow/BUILD, flow/util/BUILD
The orfs_pdk targets, the makefile/makefile_yosys filegroups and
the exports_files globs over platforms/. bazel-orfs generates
these too; orfs_pdk has to be declared inside this repository
because a glob() only sees its own, and generating the BUILD is
what lets the glob run here while the rule lives with the rules.
3 MODULE.bazel, BUILD.bazel, bazel/BUILD
MODULE.bazel's remaining job was orfs_designs() and a pip
requirements lock for the bazel-only python targets. bazel-orfs
declares orfs_designs() itself now. BUILD.bazel wraps
bazel/install.sh; bazel/README.md and install.sh are kept, since
they document the docker-image path and are not bazel packages.
Kept deliberately: the other ~116 design BUILD files, which declare
files() groups or genuinely per-design rules, and flow/designs/design.bzl
which they load. A files() group name is not derivable from a
directory's contents -- src/cva6 declares files("verilog") while holding
no .v or .sv, and prim/rtl holds both .sv and .svh but declares
files("include") -- because the name is decided by what other configs
reference. Those follow only if and when bazel-orfs carries them
explicitly.
Zero effect on this repository's own CI, which never invoked bazel.
Verification, from a bazel-orfs workspace pinned at this commit:
bazelisk query '@orfs//flow/designs/...:*'
lists 4135 targets, byte-identical to the same query before this commit
-- 0 added, 0 lost. Measured, not predicted.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
oharboe
force-pushed
the
drop-bazel-surface
branch
from
September 2, 2026 18:06
97a9cb1 to
c4d858d
Compare
Member
🔍 QoR checkMetrics reflect the PR merge build — i.e. what will land on the target branch. Advisory — results are log-only and do not affect build status. The authoritative QoR gate remains the local rules-file check. Commit 62 design(s) checked — 0 with regression(s), 0 without a comparable baseline.
|
This comment was marked as outdated.
This comment was marked as outdated.
oharboe
changed the title
oharboe
marked this pull request as ready for review
September 5, 2026 06:47
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
2 participants
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.
TL;DR bazel-orfs has the machinery to build any ORFS from within the bazel-orfs repository now, so remove hundreds of files of cruft in ORFS. Less noise and churn by having that machinery in bazel-orfs.
ORFS is a pinned storage of scripts, PDKs and example designs as far as bazel-orfs is concerned.
https://github.com/The-OpenROAD-Project/bazel-orfs#quick-start
This also has the effect that you can build any ORFS design from within OpenROAD or bazel-orfs:
I haven't bumped OpenROAD in a while to new bazel-orfs, there hasn't been a need or call for it as bazel-orfs in OpenROAD is only used for regression testing and presumably it is doing its job fine with the version that it has. Even post bumping bazel-orfs in OpenROAD, nothing will change in ORFS w.r.t. regression testing in CI, building any design like above is just a new feature that I don't think anyone would use over bazelisk run //:install + make from ORFS, in practice.