Globally override tool path

[timokau]

Description of the problem / feature request:

This falls somewhere in between a support request and a feature request. I hope this is the right place. I'd like to be able to authoritatively override the location of a tool like ar during a bazel build, for example by setting an environment variable:

export BAZEL_TOOLS_OVERRIDE="ar=/some/path/to/ar"

Bazel should then give this override priority over all other possible sources of information about that tool. This makes sense from a distro packaging context. The distro knows better than bazel or the package being built where the tools are. The package manager is responsible in this case to select the right tool for cross compilation, not bazel.

Feature requests: what underlying problem are you trying to solve with this feature?

I am trying to package tensorflow with cuda support. ar is not located in /usr/bin. The build fails with errors of this type:

[34 / 306] Compiling external/protobuf_archive/src/google/protobuf/extension_set.cc [for host]; 2s local ... (14 actions, 11 running)
ERROR: /build/output/external/double_conversion/BUILD.bazel:12:1: Linking of rule '@double_conversion//:double-conversion' failed (Exit 1)
src/main/tools/process-wrapper-legacy.cc:58: "execvp(/usr/bin/ar, ...)": No such file or directory

What operating system are you running Bazel on?

NixOS

What's the output of bazel info release?

I run the NixOS bazel package version 0.26.1 (with the later explained debugging patches applied).

Extracting Bazel installation...
Starting local Bazel server and connecting to it...
release 0.26.1- (@non-git)

Have you found anything relevant by searching the web?

This issue, which suggested override the tool_path values in the project I'm trying to build. That is not ideal, since it requires patching the source. It also doesn't work in this case. I patched all tool_path occurrences (including those from external dependencies after bazel fetch) without success.

Any other information, logs, or outputs that you want to share?

I tried to make an override possible with this patch, but that apparently doesn't cover all use cases since bazel still failed with the above error.

I applied this patch in an attempt to figure out where the /usr/bin/ar path is coming from. The error still mentioned /usr/bin/ar, even though I had patched all occurences I could find within bazel and within tensorflow.

I then applied this patch to manually override the ar path. Since the error then reports /ar/path/overridden/ar, which tells me that the path somehow originates in tools/cpp/cc_toolchain_config_lib.bzl.

In summary, I have no idea where bazel gets the /usr/bin/ar from.

Also somewhat curiously, the bulid only fails when I build tensorflow with cuda support.

[timokau]

It turns out this already exists in some form, namely with --crosstool-top. Also my problem with tensorflow was a little bit more complicated than just forcing it to use the default system tools. It only occurs with cuda, since cuda requires a special set of tools (in addition to the normal ones) which are configured in third_party/gpus/cuda_configure.bzl. I didn't find or patch those initially, since the /usr/bin prefix is hidden behind a variable. Setting GCC_HOST_COMPILER_PREFIX to an appropriate value fixed the build for me.

Sorry for the noise. Turns out this was just a support request after all.