Remote caching broken on macOS with Xcode

[kastiglione]

Description of the problem request:

Remote caching with Bazel 1.1 (#9982) was broken by #8495. That changes embeds an absolute path in cc_wrapper.sh. For example:

# Call the C++ compiler
/private/var/tmp/_bazel_iosci/1ec83befa5e62d8b1339d3693738f87a/external/local_config_cc/wrapped_clang "$@"

This has both username and workspace path hash. This wrapper is an input to pretty much every compilation command, causing an extremely degraded cache hit rate.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

We saw this with remote builds. An easier repro might be to use local --disk_cache between to separate local checkouts of a project.

What operating system are you running Bazel on?

macOS

What's the output of bazel info release?

release 1.1.0

[meisterT]

cc @allevato

[allevato]

That was an unanticipated effect of that change.

So the issue here is that the C++ actions in crosstool invoke cc_wrapper.sh instead of wrapped_clang (which the Objective-C actions do), and previously cc_wrapper.sh was invoking clang directly (via the cc substitution). That meant that those actions didn't get any of the Bazel placeholder substitutions that wrapped_clang does.

cc_wrapper.sh needs to call wrapped_clang in order to have the right behavior, but since wrapped_clang is also built from source when the repository is initialized, it ends up in an output directory that has all those non-hermetic path segments in it.

I'm not sure what the best solution here is. @keith, you were experimenting with something that would replace the cc substitution in osx_cc_configure.bzl with a shell script fragment that computed cc_wrapper.sh's location and executed wrapped_clang relative to it. #10187 notwithstanding, did that work?

@hlopko, does that sound like a reasonable approach?

[kastiglione]

@allevato: Keith's PR for calling wrapped_clang relatively is here: #10185