bazelbuild
[CC Toolchains] Enable access to bazel generated files for tool paths
Description of the feature request:
Allow tool_paths to access generated files for toolchains in a third party dependency.
Which category does this issue belong to?
C++ Rules
What underlying problem are you trying to solve with this feature?
I am attempting to create a hermetic cc toolchain for a project at our company. However the toolchain (specifically their version of "GCC") likes using absolute paths and requires an environment variable that represents an absolute path. Since the sandbox path changes at any given moment for the build, my goal is to create a wrapper script which will resolve the correct path and call "GCC" with the right arguments.
I have a third party dependency that wraps the toolchain. When I create the toolchain with the cc_toolchain rule, it takes in "all_files" as a filegroup. That filegroup also contains the wrapper script, which is generated via a "write_file" rule. However, when I can't seem to point tool paths to the wrapper script since it shows up in bazel-out/<blah>-fastbuild/bin instead of the repo directly. When I try to use some relative path or a non-normalized path (such as ../../bazel-out/...) it complains with the following error:
File "/virtual_builtins_bzl/common/cc/cc_toolchain.bzl", line 55, column 45, in _cc_toolchain_impl
File "/virtual_builtins_bzl/common/cc/cc_toolchain_provider_helper.bzl", line 173, column 37, in get_cc_toolchain_provider
File "/virtual_builtins_bzl/common/cc/cc_toolchain_provider_helper.bzl", line 78, column 17, in _compute_tool_paths
Error in fail: The include path '../../bazel-out/linux_x86_64_platform-opt-exec/bin/external/dep/wrapper_script.sh' is not normalized.
Which operating system are you running Bazel on?
Linux
What is the output of bazel info release?
7.0.2
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
No response
What's the output of git remote get-url origin; git rev-parse HEAD ?
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
For now I have a workaround (e.g adding the wrapper script to the external dep tar) but ideally don't have to keep them in sync and the wrapper script (being owned by us) lives in our codebase.
+1 on this request.. This would also allow toolchains to be downloaded dynamically without using repository rules which would decrease the setup-time, and disk usage, significantly when using remote-execution with build without the bytes.
