bazel: enable tclreadline in Bazel

[alokkumardalei-wq]

Note: Since there is no scope of installing tclreadline in macOS , therefore all the development and testing was done in linux Docker container with tclreadline available there.

What does this PR resolves?

Fixes #7115 .
Trying to fix missing tclreadline support for BUILD.bazel.

What actually the issue is?
The Bazel build was missing tclreadline support,
so running bazelisk run //:openroad
showed a bare % prompt instead of openroad>.

What changes are made to fix this ?

bazel/tclreadline.bzl
— repository rule to detect the system-installed tclreadline library at build time via pkg-config, falling back to common system paths (new file created ).

MODULE.bazel
— registers the new repository.

BUILD.bazel
— adds ENABLE_READLINE + TCLRL_LIBRARY defines and links @tclreadline on supported platforms.

Validation/Testing:

Validation and testing only can done tclreadline is installed , here in our case the Linux Docker Image.
In macOs it uses the stub empty target (no tclreadline available).

$ bazelisk build //:openroad

Expected output (in macOS):

INFO: Invocation ID: 949d17c2-1bdd-4cfe-9c86-8215ae772c00
INFO: Analyzed target //:openroad (32 packages loaded, 321 targets configured).
INFO: Found 1 target...
Target //:openroad up-to-date:
  bazel-bin/openroad
INFO: Elapsed time: 1.009s, Critical Path: 0.35s
INFO: 1 process: 11 action cache hit, 1 internal.
INFO: Build completed successfully, 1 total action

Expected output (before fix in linux official OpenRoad Docker image environment):

%

Expected output (After fix in linux official OpenRoad Docker image environment):

openroad>

[gemini-code-assist]

Code Review

This pull request enables tclreadline support in the Bazel build, which provides a better interactive prompt. The changes introduce a new repository rule to detect the system-installed tclreadline library, with fallbacks for systems where it's not available. The implementation is sound, but I have one suggestion to improve the robustness and clarity of the library detection script by avoiding duplicate search paths.

[gemini-code-assist]

The list of include directories is constructed by simple concatenation, which can lead to duplicate paths if include_dirs (from pkg-config) already contains /usr/include. While the break on line 38 prevents incorrect behavior in this case, this approach is inefficient and can be confusing.

To improve this, you should create a unique list of paths before iterating. A common way to do this in Starlark (which lacks a set type) is to use a dictionary as a temporary ordered set:

unique_include_dirs = {}
for d in include_dirs + ["/usr/include", "/usr/local/include"]:
    unique_include_dirs[d] = True

for d in unique_include_dirs.keys():
    # ... search logic ...

This same issue of potential duplicates applies to the library search paths on lines 43 and 64, and the library names on line 49.

[maliberty]

This appears to be looking for a locally installed tclreadline. The goal of the bazel build is to be hermetic and not rely on local installation.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[alokkumardalei-wq]

Hello @maliberty,

Thanks for the feedback! The build is now fully hermetic — tclreadline is fetched from source via http_archive and no longer relies on any system-installed libraries. Please see commit 47f963a for the changes.
Happy to address any further feedback!

[alokkumardalei-wq]

And also you can have a look on these Open PRs when you have time:

1. Refactor TA files and format and document TA support files. #9677
2. docs: Add DependencyInstaller.sh functionalities(-local and -prefix) to Build.md #9649
3. Fix endcap corners cells overlapping results from cutting rows #9640

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[alokkumardalei-wq]

Hello @maliberty,
You can see continuous-integration/jenkins/pr-head and continuous-integration/jenkins/pr-merge jenkins CI are failing.
I might be wrong about this but when I clicked on the failing Jenkins checks to investigate. The console log shows the build couldn't be scheduled because all worker nodes were offline at the time. Could you please look into this and re-trigger the jenkins build again if possible.

Thank you

[maliberty]

pr-merge ran and bazel failed with

[2026-03-11T04:30:37.929Z] bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/+_repo_rules+tclreadline/tclreadline_patched.c:24:12: fatal error: 'readline/readline.h' file not found
[2026-03-11T04:30:37.929Z]    24 | #  include <readline/readline.h>

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[alokkumardalei-wq]

Hello @maliberty,

Thanks for catching that and sorry about before(my bad)! You were right — the Jenkins Linux build failed because the container lacked the system readline in Main.cc.
headers needed to compile tclreadline.I have fixed this to make the build 100% hermetic. In commit 4ecb37d, I added readline and tcl_lang as official Bazel Central Registry dependencies in MODULE.bazel.
Bazel now fully manages and compiles the readline source itself locally, completely removing the reliance on any host system dependencies. I hope it should pass now.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[alokkumardalei-wq]

Hello @maliberty again sorry for inconvenience I think I forgot to remove this line linkopts = [\"-lreadline\"] in tclreadline.BUILDwhich was causing the linker to search for a system-installed readline library in addition to the hermetic one Bazel provided. FIxed that, and hopefully it should pass now.
Thank you.

[alokkumardalei-wq]

Hello @maliberty the pr merge jenkins integrations failed to pass it's showing this in the output logs
no such package '@@rules_bison+//bison/internal': java.io.IOException: Error downloading [https://github.com/jmillikin/rules_bison/releases/download/v0.4/rules_bison-v0.4.tar.xz] I have no idea what does this imply. Please have a look into this when you have time.
Thank you.

[maliberty]

I restarted that pipeline as it seems to be some dockerhub flakiness

[hzeller]

I don't understand this change.

The openroad readline integration works, and tcl is also compiled with readline.

We are using readline from BCR already. So we should use that.
https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/MODULE.bazel#L75

Edit:
ah ,I see that readline dependency was added in this PR; I remember that I had to add it bazelbuild/bazel-central-registry#7476 for OpenROAD to work.

If tcclreadline is a separate repo, it should be upstreamed to BCR, not http-archive fetched here.

[hzeller]

if this is adding functionality, probably not rollback, but next follow-up is upstreaming the bazel rule to BCR