Note: OpenROAD depends on lemon, ncurses, abc, and swig. We need to wait for their upstream PRs to be merged first.

Please do not spam YosysHQ projects with your build system PRs. They are not welcome and it is not appropriate to even send that many PRs without first asking the upstream project if they're interested in the maintenance burden of another build system.

Hi @whitequark ,
I sincerely apologize for the disruption and the volume of PRs. I understand that introducing an additional build system imposes a maintenance burden that the project does not wish to take on.

I should have opened an issue to discuss this beforehand instead of sending multiple PRs directly. I respect your decision and will close these PRs immediately.

Thank you for your work on YosysHQ.

Thanks.

@mikesinouye Given the reaction from the community, maintaining a separate fork seems to be the better choice. I plan to set up a CI pipeline to automatically merge changes from upstream on a monthly basis, as relying on patches would introduce too much maintenance overhead for me.

@MrAMS have a look at this discussion:
The-OpenROAD-Project/OpenROAD#7647

OpenROAD people seemed interested in the work I did. It would be amazing if you could continue there.
Ideally we could create a separate bazel registry that people can overlay with just patches, and then slowly merge those in the upstream bcr. This is the best approach I can think of.

If you feel like collaborating more, please let me know your preferred means of communication or just reach out.

OpenROAD is slowly converting to having bazel be our main and eventually only build system.

Hi @lromor @maliberty
Since I'm still familiarizing myself with the open-source contribution workflow, I've decided to focus on maintaining my own fork for now. However, feel free to check out this branch: MrAMS/OpenROAD#bzlmodify-upstream-merge. I've updated openroad to the latest upstream version, and verified that all tests are passing.

Here is a summary of my recent progress:

• OpenROAD: I have merged the bzlmod-supported OpenROAD with the latest upstream changes and resolved numerous issues. You can check it out here.
• bazel_rules_hdl: I updated this to ensure compatibility with the latest OpenROAD and fixed several related bugs. The branch is here.
• Dependencies: I synchronized almost all dependencies to their latest upstream versions. In particular, I addressed multiple issues regarding the swig integration.
• CI Workflow: I added a new CI workflow to bazel_rules_hdl. Since git_override can be quite slow and hard to reproduce, the CI now automatically generates an archive_override package on every push. You can see an example release here. (optional, original code use git_override)
• Verification: Finally, I updated my minimal working project and verified that all tests are currently

Hey, I noticed a number of PRs to BCR and am kinda confused.

For these:

• icestorm@0.0.0-20251212-59e4c98 bazelbuild/bazel-central-registry#6802
• prjtrellis@0.0.0-20251212-e076bca bazelbuild/bazel-central-registry#6801
• verilator@5.036.bcr.4 bazelbuild/bazel-central-registry#6842

It looks like you're pointing to your private repo as the source of truth for builds? Also usurping ownership? The current state of those PRs makes me concerned so can you explain how they were generated and provide more context on the direction?

Hi @UebelAndre ,
Thank you very much for your review. Please forgive me if I have offended you in any way—I’m still not very familiar with the open-source contribution process for Bazel. Feel free to close any PRs from me that you find inappropriate, and I would be happy to hear any specific improvement suggestions from you.

My forked repository will automatically pull and attempt to merge the latest upstream changes via CI every month. If upstream changes are detected and merged successfully, the CI will automatically submit a BCR update PR. You can check the CI status of these repositories. If you still think this approach is inappropriate, feel free to refuse to merge and close these PRs.

Additionally, I have now decided not to continue trying to migrate rules_hdl to Bzlmod or publish it to BCR. After discussing with the open-source community, I found that rules_hdl is inconsistent with the minimal modularity concept of Bzlmod. I will focus on making further contributions to OpenROAD, bazel-orfs and rules_verilator in the future, so feel free to close this migration PR as well.

Thank you again for your patience and guidance, as I’m still new to open-source contributions.

Hi @UebelAndre , Thank you very much for your review. Please forgive me if I have offended you in any way—I’m still not very familiar with the open-source contribution process for Bazel. Feel free to close any PRs from me that you find inappropriate, and I would be happy to hear any specific improvement suggestions from you.

My forked repository will automatically pull and attempt to merge the latest upstream changes via CI every month. If upstream changes are detected and merged successfully, the CI will automatically submit a BCR update PR. You can check the CI status of these repositories. If you still think this approach is inappropriate, feel free to refuse to merge and close these PRs.

Thanks! I'm not offended, just alarmed for security reasons by a bunch of changes that moved sources to private repos. I think contributing to OpenROAD would be great and to eventually see The-OpenROAD-Project/OpenROAD#8828 implemented. Thank you for all your work!

Just to clarify as i was confused initially. These are the deps referred to above that are patched/modified versions that are not yet available in bcr. Adding the following to my MODULE.bazel worked:

git_override(
    module_name = "p7zip",
    commit = "be778d8e29b3f21bd3b0c661be0d4f4ab49d3ffa",
    remote = "https://github.com/amorphic-io/7zip.git",
)

git_override(
    module_name = "prjtrellis",
    commit = "3332d029295a8e424969126f5c61a5ea111882a8",
    remote = "https://github.com/amorphic-io/prjtrellis.git",
)

git_override(
    module_name = "icestorm",
    commit = "85fd1682b58581b82d1d14f63c089fb033177c21",
    remote = "https://github.com/amorphic-io/icestorm.git",
)

git_override(
    module_name = "nextpnr",
    commit = "2ab1f5e7e6be52e2a59347cace86f5c16348a115",
    remote = "https://github.com/amorphic-io/nextpnr.git",
)

git_override(
    module_name = "cxxopts",
    commit = "0fc4bdab71ea25e3623e2b609b4e5b2bd20bb938",
    remote = "https://github.com/amorphic-io/cxxopts.git",
)

git_override(
    module_name = "yosys",
    commit = "590ad236368e41af3de4ea8252811beeaadb5f97",
    init_submodules = True,
    remote = "https://github.com/amorphic-io/yosys.git",
)

git_override(
    module_name = "swig",
    commit = "52ed25274e9042611bda40c42e48aae8b6748686",
    remote = "https://github.com/amorphic-io/swig.git",
)

git_override(
    module_name = "iverilog",
    commit = "760dfa28d8f863164a2fbbaabebd1202850249c8",
    remote = "https://github.com/amorphic-io/iverilog.git",
)

git_override(
    module_name = "lemon",
    commit = "f8be7b96fbdfa789a4dae0429967b7724e89d5f5",
    remote = "https://github.com/amorphic-io/lemon",
)

git_override(
    module_name = "abc",
    commit = "2fa8f6e551a85da586fbe01792e6cfdaa7ce72cc",
    remote = "https://github.com/amorphic-io/abc",
)

git_override(
    module_name = "ncurses",
    commit = "f918fafc9f7aeb1745d02e7978597abf8e580de2",
    remote = "https://github.com/amorphic-io/ncurses",
)

git_override(
    module_name = "llvm-project",
    commit = "93c4a9c7b9d2fef50ad97c80efa54ccaed7df0c8",
    remote = "https://github.com/amorphic-io/llvm-project",
)

git_override(
    module_name = "tcl",
    commit = "e285aca41d39e84ab1753f125b095d65a0e15640",
    remote = "https://github.com/amorphic-io/tcl.git",
)

git_override(
    module_name = "openroad",
    commit = "c80e4b3f54dd94cdbebfecc3c98a64049b8c7efc",
    init_submodules = True,
    remote = "https://github.com/amorphic-io/OpenROAD",
)

git_override(
    module_name = "bazel-orfs",
    commit = "126765508161956f8f82ae169084da0235230637",
    remote = "https://github.com/The-OpenROAD-Project/bazel-orfs.git",
)

Also @MrAMS I agree with the modularity argument, but i think bazel_rules_hdl should still collect/aggregate it all. For example the verilator block you have done as standalone is nice and bazel_rules_hdl should depend on it instead of having a parallel implementation. The rules hdl idea with bazel was essential with the WORKSPACE as dependencies were a nightmare, but perhaps splitting sections off into separate repos makes sense now?

Before BCR it was very hard to discover repos/projects. Thoughts from maintainers? @UebelAndre @QuantamHD

@stridge-tnp For new projects, it is highly recommended to use MODULE.bazel (Bzlmod) instead of WORKSPACE. I personally suggest checking out bazel-orfs as a reference.

@stridge-tnp For new projects, it is highly recommended to use MODULE.bazel (Bzlmod) instead of WORKSPACE. I personally suggest checking out bazel-orfs as a reference.

Yeah, I have been using my draft pr for bazel 8.

I was just suggesting that with the transition to bazel 8 I think there is still a place for rules HDL but maybe it should be structured differently.

For anyone interested in the Chisel support within rules_hdl, I’ve published a BCR package called rules_chisel as a Bzlmod-native alternative.

For anyone interested in the verilog_library support within rules_hdl, I’ve published a BCR package called rules_verilog as a Bzlmod-native alternative.

Superseded by #430