tcl: add a fallback from hardcoded TCLRL_LIBRARY path

[oharboe]

TL;DR This fixes the last niggling little deployment problem with non-Ubuntu systems and bazel-orfs GUI.

Not pretty, but good 'nuf to use around the house.

[github-actions]

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

[gadfort]

@oharboe why is this needed? If TCL readline is installed correctly the TCLRL_LIBRARY should be defined in the header:
https://github.com/flightaware/tclreadline/blob/20f1425cec34eeef8f24f1e942e0be4038b8df3a/tclreadline.h.in#L16
Also not a huge fan of hardcoding the version number into the embedded tcl script, second, you should either define this in a namespace for tcl do "find_path" isn't just a random function in the tcl environment or you need to cleanup after yourself.

I would like to know better what the actual issue was that this is addressing, since in a headless build for bazel, why add tclreadline?

[oharboe]

@oharboe why is this needed?

It is the final hack at the end of a long story...

If TCL readline is installed correctly the TCLRL_LIBRARY should be defined in the header: https://github.com/flightaware/tclreadline/blob/20f1425cec34eeef8f24f1e942e0be4038b8df3a/tclreadline.h.in#L16

Also not a huge fan of hardcoding the version number into the embedded tcl script,

Will fix.

second, you should either define this in a namespace for tcl do "find_path" isn't just a random function in the tcl environment or you need to cleanup after yourself.

Thanks! I think I can do without a proc entirely. Will fix.

I would like to know better what the actual issue was that this is addressing, since in a headless build for bazel, why add tclreadline?

In bazel we also use the user-interface.

In bazel-orfs we use the Docker image(as it is the point in the CI infrastructure that we can pick up a build), but we run the docker image without docker, which is possible if you run through some hoops.

This is the niggling little edge case that we didn't find out a way to sort out otherwise.

It doesn't change the behavior for any case where the library is found today, so hopefully the cruft will be acceptable.

[gadfort]

@oharboe why is this needed?

It is the final hack at the end of a long story...

If this cruft is to be "acceptable" I think it's worth knowing what the story is. Keep in mind there are no comments or anything describing the issue, so the next person who encounters this code will wonder why this is needed.

This feels like there is an issue with your tclreadline install and it would be better to fix that than have some code that isn't in opensta or the tclshrl builds.

[github-actions]

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

[oharboe]

@gadfort Added some gory details on why we have to look up the path dynamically.

[github-actions]

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

[github-actions]

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

[oharboe]

@maliberty I don't understand the pr-merge failure, pr-head passes and this PR is on top of the most recent master, so pr-merge and pr-head should be identical.

[maliberty]

I don't see any details there that explain how it is done. Its just a list of files and there is no mention of docker.

[oharboe]

Documentation on how this is done belongs in bazel-orfs. Admittedly it could be better.

[maliberty]

Why do you want to do this?

[oharboe]

Because running docker in bazel-orfs is extremely problematic; don't do it. Because I want CI, docker provides this. Because this is a solution that exists and is working, less this niggling litt nit.

[oharboe]

As to your question why I "want to dothis", I think it is more of a question as to which poison I want to pick. I have picked this poison.

[gadfort]

it seems like there is something not right about the usecase, which is leading to this solution. Personally, I would prefer not to bring this in, if the solution is to properly build OpenROAD for bazel (or whatever platform) instead of building on one platform and moving the binary around.

[oharboe]

It is not one or the other; there's no conflict here.

This PR is boarding up a broken window (lack of resources for CI + programming), longer term I hope to clean up bazel-orfs.

[gadfort]

How does @QuantamHD handle the OpenROAD build for his bazel setup? He must have encountered a similar issue

[maliberty]

I believe they use a monorepo and build from source.

[oharboe]

I also saw some patching of OpenROAD going on, so my short answer is that it would take a bit of time to investigate what they are doing.

In the future, I'd like to see an officially maintained bazel build of OpenROAD with an artifact repository that I can use, just like Docker images. Would save tons of building time for anyone involved + be single source of truth + better chance of everyone running the exact same version w.r.t. bug reports and communicating in the community...

Perhaps bazel_hdl could use it too?

That's not happening tomorrow though...

[maliberty]

This feels like there is an issue with your tclreadline install and it would be better to fix that than have some code that isn't in opensta or the tclshrl builds.

This is a good point. The sta app will not work with this approach. I believe you are sta for power reporting.

[github-actions]

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

[oharboe]

@maliberty mystery pr-merge error?

[maliberty]

I see the same two tests failed in many builds:
626 - psm.gcd_write_sp_test_vdd (Failed)
628 - psm.gcd_em_test_vdd (Failed)

I think it worth taking a look at it doesn't seem to be some random flakiness.

[oharboe]

@maliberty ctest --test-dir build -j 32 had failures locally without #5961

I propose to merge this as-is or that I wait for #5961 to be merged, then merge with master and do a rebuild of this PR.

[github-actions]

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

[oharboe]

@maliberty Fixed!