Conversation
oharboe
commented
Apr 8, 2026
oharboe
commented
- orfs -> b6ff3eb63dac (drop patch 0001 merged upstream)
- openroad -> d34d035725c3
- qt-bazel -> 886104974c2f
- rules_shell 0.6.1 -> 0.7.1 (fix version mismatch warning)
- Regenerate patch 0035 for new upstream MODULE.bazel
Bump dependencies: - orfs -> 74271e42b301 (removes upstreamed merge_lib patch) - openroad -> d22045c978d0 - qt-bazel -> 886104974c2f - rules_pkg -> 1.2.0 (matches resolved graph) The new OpenROAD replaced the InitRunFiles.cpp global constructor with tcl_library_init, but its Runfiles::Create() picks up stale RUNFILES_* env vars left by the Python wrapper that ORFS runs between OpenROAD calls. Patch OpenROAD to clear inherited RUNFILES_DIR/RUNFILES_MANIFEST_FILE before resolving its own runfiles, and gut the now-dead InitRunFiles.cpp shim. Also regenerate the ORFS MODULE.bazel patch for the new upstream (rules_python 1.8.5, shifted line numbers). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Apply the same dependency bumps to gallery, chisel, and sby submodules: orfs, openroad, qt-bazel commits, remove upstreamed patch, add openroad-remove-initrunfiles.patch. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
|
@hzeller 🤞 |
|
@hzeller for now caching is mythical for my use-cases... lots of churn to update. Previously I would get a binary directly from ORFS. But previously I would have to wait for the patches to land upstream before I could even think about upgrading. Now I can upgrade and patch upstream and actually test the patches before I consider upstreaming them. Which is great. But caching remains elusive... |
|
If things don't work well with the cache, maybe build a tiny project in the CI and see how it behaves. I once set up a cache in OpenROAD (while we were still on github actions), that also used time as factor, so you get the latest cache not something that matches alphabetically first with the hash (though not sure that it is still needed; that was needed around 2020 when I first started setting up bazel caches). One problem can be if the cache size is more than 10GiB, it will exceed what github has to offer. |
|
Disappointment is mismanaged expectations, could you check how big the cache needs to be and if there is anything we can do about it? I'd like to stay within the github budget. |
|
@hzeller I want to see if we can whittle the testing setup down so that it fits into github budget. Perhaps we can do something on the openroad side? |
|
@hzeller The main build of this PR that I just merged. It should have caching. This PR ran in 45 minutes, this should run in much less than that... |
|
that ci is still building. Look at the end when it packs up its caches if it runs into trouble |
| @@ -0,0 +1,140 @@ | |||
| diff --git a/bazel/BUILD b/bazel/BUILD | |||
There was a problem hiding this comment.
@hzeller @maliberty Have you run into this?
Could I be running into this with the static web files?
There was a problem hiding this comment.
See link above:
[Warning] Failed to create bazel runfiles: ERROR: external/rules_cc+/cc/runfiles/runfiles.cc(103): cannot find runfiles (argv0="/home/oyvind/OpenROAD-flow-scripts/tools/OpenROAD/tmp/test/orfs/gcd/_main/openroad")
application-specific initialization failed:
There was a problem hiding this comment.
Have to run... so many things in flight, but I'm optimistic that all of these issues will trickle as fixes into OpenROAD and ORFS :-) Takes a bit of time though, step by step...
There was a problem hiding this comment.
Is this a recent openroad from after April 2nd ?
There was a problem hiding this comment.
also: I have no idea what this patch is attempting to accomplish
|
https://github.com/The-OpenROAD-Project/bazel-orfs/actions/runs/24179101305/job/70567318431#step:31:2 <- looks like it wants a path of sorts to save something ? |
2 participants
