bazel: After install, openroad still reads file openroad.repo_mapping from build location

[fredowski]

Describe the bug

I moved the openroad exe and the openroad runtime directory to another location to have the applicaton standalone. After deleting the build environment, starting the application results in a crash for the gui. For the cli, the tcl.init is not found - indicating a wrong access to the runtime.

I traced this with strace and found that still the openroad.repo_mapping file is accessed in the build directory.

When I delete the MANIFEST file in the runtime, then it works.

I opened an issue in rules_cc: bazelbuild/rules_cc#620

Expected Behavior

No remaining files in the build directory needed.

Environment

debian 13 aarch64

To Reproduce

• Build openroad with bazel
• Copy the exe and the runtime out of the bazel-bin directory to /tmp/install with cp -r -L openroad.runtime /tmp/install/and cp openroad /tmp/install/
• run bazelisk clean or rename ~/.cache
• run /tmp/install/openroad -gui => crash

Relevant log output

Screenshots

No response

Additional Context

No response

[QuantamHD]

This might be somewhat intended behavior. If you want a relocatable distribution I believe you're supposed to use the rules_pkg package rules to generate a tar https://bazelbuild.github.io/rules_pkg/latest.html#pkg_tar

[fredowski]

But we have this //:install ?

[maliberty]

My guess is that it is not correct then. It was probably vibe coded (see Co-authored-by: gemini-code-assist[bot])

[QuantamHD]

In particular you need to make sure to pass include_runfiles = True. The rules can also generate rpms and debs. The other reason it's important to use these rules is that the things in bazel-bin dir are often symlinked multiple times, and when you just naively copy the folder you're often breaking the symlinks and or not actually including the real contents of the files.

[oharboe]

My guess is that it is not correct then. It was probably vibe coded (see Co-authored-by: gemini-code-assist[bot])

Yes.

Note that this has been enormously useful in day-to-day development since DependencyInstaller/CMake no longer works for me.

Also, I think we are agreed on the interface to the user here, but the implementation is "rough".

For deployment we use the docker build.

[oharboe]

@fredowski I think that your expecation here, that it should be legal to move it is reasonable and that it is a surprise to the user that it doesn't work.

[gadfort]

It seems like what @QuantamHD is suggesting we should use is the pkg_tar and then installing is just untarring the files

[fredowski]

I tried the pkg_tar in BUILD.bazel

# Produce a tarfile including the binary and the runtime files
# The layout is
# ./openroad
# ./openroad.runfiles/...
# This can be untarred and run standalone
# This includes
# ./openroad.runfiles/_main/openroad
# which is again the binary.

pkg_tar(
    name = "tarfile",
    srcs = [
        ":openroad",
    ],
    include_runfiles = True,
    package_file_name = "openroad.tar",
)

which provides a tarfile with a file setup that works. However the binary is in there twice.

openroad
openroad.runtime/_main/openroad

I did not manage with pkg_files and friends to get rid of the _main/... files. Maybe this is a bug?

[fredowski]

Maybe we can also just fix the install.sh which is at least understandable. My proposal:

• Delete MANIFEST
• Delete openroad.runfiles/_main...