Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remote caching broken on macOS with Xcode #10184

Closed
kastiglione opened this issue Nov 6, 2019 · 3 comments
Closed

Remote caching broken on macOS with Xcode #10184

kastiglione opened this issue Nov 6, 2019 · 3 comments
Assignees

Comments

@kastiglione
Copy link
Contributor

@kastiglione kastiglione commented Nov 6, 2019

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

This comment has been minimized.

Copy link
Member

@meisterT meisterT commented Nov 7, 2019

@allevato

This comment has been minimized.

Copy link
Member

@allevato allevato commented Nov 7, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@kastiglione kastiglione commented Nov 7, 2019

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

@bazel-io bazel-io closed this in c76c3e5 Nov 12, 2019
philwo added a commit that referenced this issue Nov 12, 2019
After this change #8495 the path
to CC embedded in this file was absolute, which caused cache misses for
all compile actions. This change depends on this file relative to the
cc_wrapper itself instead.

Fixes #10184

Closes #10185.

PiperOrigin-RevId: 279960066
philwo added a commit that referenced this issue Nov 14, 2019
After this change #8495 the path
to CC embedded in this file was absolute, which caused cache misses for
all compile actions. This change depends on this file relative to the
cc_wrapper itself instead.

Fixes #10184

Closes #10185.

PiperOrigin-RevId: 279960066
philwo added a commit that referenced this issue Nov 20, 2019
After this change #8495 the path
to CC embedded in this file was absolute, which caused cache misses for
all compile actions. This change depends on this file relative to the
cc_wrapper itself instead.

Fixes #10184

Closes #10185.

PiperOrigin-RevId: 279960066
philwo added a commit that referenced this issue Nov 25, 2019
After this change #8495 the path
to CC embedded in this file was absolute, which caused cache misses for
all compile actions. This change depends on this file relative to the
cc_wrapper itself instead.

Fixes #10184

Closes #10185.

PiperOrigin-RevId: 279960066
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.