bazel: use pkg_tar for the install procedure

[fredowski]

I updated the install procedure to use the pkg_tar module. The install works as before, but now you
can also install optionally to another location.

Closes: #9635

[gemini-code-assist]

Code Review

This pull request refactors the installation process to use pkg_tar for creating a distributable tarball. This is a good improvement that makes packaging more robust. The changes in the Bazel build files are correct, and the updated install.sh script correctly handles the new tar-based installation and adds support for custom installation paths. I've found one minor issue in the installation script that could cause it to fail, and I've provided a suggestion for a fix.

[gemini-code-assist]

This block for removing openroad.repo_mapping is brittle. The rm -r command on line 25 will cause the script to fail if openroad.repo_mapping does not exist, because set -e is active.

This can be simplified and made more robust by using rm -rf, which is idempotent and handles files, directories, and non-existent paths without error. This is also consistent with its use on the next line.

Suggested change

	if [ -e openroad.repo_mapping ]; then
	chmod u+w openroad.repo_mapping
	fi
	rm -r openroad.repo_mapping
	rm -rf openroad.repo_mapping

[github-actions]

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

[github-actions]

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

[QuantamHD]

Do you need to remove the repo mapping file?

[fredowski]

Do you need to remove the repo mapping file?

It will work also if I do not delete that file. But the relevant repo_mapping file is in openroad.runfiles/_repo_mapping. Without that, the gui crashes.

[oharboe]

The approach looks good — using pkg_tar with include_runfiles = True is the right way to make a relocatable install per Bazel conventions.

One request: the custom install path usage instructions are currently buried in comments inside bazel/install.sh:

# Run this from bazel build directory with
# bazelisk run --//:platform=gui //:install

# If you want to install to another location, e.g. /tmp, then do
# bazelisk run --//:platform=gui //:install -- /tmp

These should go into docs/user/Build.md instead, where users will actually find them. The Bazel install section there (lines 19-28) already documents the basic install command but doesn't mention the custom path option. Something like:

## Build and install with Bazel

Build OpenROAD with GUI support and install into ../install/OpenROAD/bin

    bazelisk run --//:platform=gui //:install

To install to a custom location:

    bazelisk run --//:platform=gui //:install -- /tmp/myinstall

To embed the real git version string, add `--config=release`:

    bazelisk run --config=release --//:platform=gui //:install

See [Bazel](Bazel.md) for more details on testing, profiling and build configurations.

Then remove the usage comments from install.sh — shell scripts shouldn't be the documentation surface for user-facing features.

[fredowski]

Good idea! I adapted the description in docs/user/Build.md and removed the comments in the install.sh script.

[github-actions]

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

[oharboe]

remove these comments, these days you can ask e.g. Claude to explain what is going on and it will read the README.md and these comments are only going to be out of date....

[fredowski]

Thanks for your review! I removed the comments.

[oharboe]

@fredowski FYI, this project prefers not force pushing because then the review history is preserved. This makes the commit history very messy, but it is more information. Perhaps in this day and age of AI, that is information that can be used to train an automatic reviewer 😄

[oharboe]

@fredowski and perhaps reading a messy git history automatically with AI to answer questions for hoomans will pay off...

[github-actions]

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

[fredowski]

O.k. - yes the history vanishes with the squashing...

[fredowski]

Thanks everybody for reviewing the code and spending your time on this topic!

[oharboe]

😌