Migrate to Bzlmod

[MrAMS]

Description:

This PR introduces Bzlmod support to the project. It builds mainly upon the groundwork laid by @lromor in this comment.

Changes:

• Rebased @lromor's attempt against the latest main branch.
• Fixed several bugs encountered after the merge.
• Verified compatibility with a minimal working example.

Verification:
I have validated the changes using my minimal working project (specifically, see rules_hdl_overrides.MODULE.bazel).

The following rules have been tested and verified to work, covering Verilator simulation, Yosys synthesize and the OpenROAD full EDA flow:

• verilog_library
• verilator_cc_library
• synthesize_rtl
• place_and_route
• gds_write

Given the long-standing discussions(issue#336, issue#332, issue#210, pull#405) regarding this migration since 2023, I believe now is the right time to move forward with Bzlmod.

[mikesinouye]

Hi @MrAMS , echoing what was said above thank you so much for all of the effort here (and all others who have helped with this!)

For this to be merged, would it be possible to point to the mainline repos for all of the git dependencies? Ideally everything would be BCR'd, but I would say that's not strictly necessary - but instead of forked repos from https://github.com/amorphic-io/ , if it's possible to point to the true upstream (and merge any fixes there first), that would improve the longevity of the project (so we can bump pointers as needed).

[MrAMS]

I completely agree that publishing to the BCR is the best solution for longevity, and I am actively working on the submission process.

However, since the BCR review can take some time, would it be possible to use my fork temporarily? To address concerns about the fork becoming stale, I have configured a CI pipeline that automatically pulls and merges the latest changes from the official upstream every month.

This automation ensures the repo stays in sync with the mainline while I finalize the BCR packaging. Once the module is live on the BCR, I will immediately update this PR to point to the official bazel_dep.

[MrAMS]

Or would it be acceptable if I updated this PR to point directly to the official upstream repository and applied my changes (such as the BUILD files) as a local patch file stored within this repo?

This approach would ensure we are consuming the official source of truth (addressing the longevity/trust issue) without having to wait for the upstream or BCR to merge the Bazel support.

Please let me know if this direction sounds good to you, and I will proceed with the changes.

[MrAMS]

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

[whitequark]

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.

[MrAMS]

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.

[whitequark]

Thanks.

[MrAMS]

@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.

[lromor]

@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.

[maliberty]

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

[MrAMS]

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.

[MrAMS]

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

[UebelAndre]

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

For these:

• [email protected] bazelbuild/bazel-central-registry#6802
• [email protected] bazelbuild/bazel-central-registry#6801
• [email protected] 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?

[MrAMS]

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.

[MrAMS]

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.

[UebelAndre]

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!