bazel: wrapped_clang is not built with the requested Xcode versions
Description of the problem / feature request:
Currently wrapped_clang is built as part of the local_config_cc setup:
Currently it doesn’t take into account what you pass for --xcode_version. Because of this if you change your xcode-select on macOS and build with a different version of Xcode than is requested with this flag, you produce a different wrapped_clang. This ends up breaking remote cache compatibility with other versions even if the build would otherwise be done with the correct Xcode version.
Bugs: what’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
sudo xcode-select -s /Applications/Xcode-10.2.1.appbazel build some_ios_target --xcode_version=10.2.1 --remote_http_cache=...bazel clean --expungesudo xcode-select -s /Applications/Xcode-11beta3.appbazel build some_ios_target --xcode_version=10.2.1 --remote_http_cache=...
With the second build, you will get nearly no remote cache hits because wrapped_clang differs as an input to every action, even though you requested the same Xcode version from the command line.
What operating system are you running Bazel on?
macOS
What’s the output of bazel info release?
release 0.28.0
About this issue
- Original URL
- State: open
- Created 5 years ago
- Reactions: 4
- Comments: 21 (21 by maintainers)
Commits related to this issue
- Consider DEVELOPER_DIR when building wrapped_clang Resolves #11716, which partially addresses #8902. With this change, and some careful environment manipulation (probably in a wrapper script) you can... — committed to bazelbuild/bazel by brentleyjones 4 years ago
- Build wrapped_clang and wrapped_clang_pp in action This compiles wrapped_clang and wrapped_clang_pp inside of an action. https://github.com/bazelbuild/bazel/issues/8902 has a larger definition of the... — committed to jerrymarino/bazel by jerrymarino 3 years ago
- Ensure Bazel uses the correct Xcode version when compiling This is three changes: - On the command-line, set `--xcode_version` to whatever `xcode-select` is set to - In Xcode, set `--xcode_version` t... — committed to MobileNativeFoundation/rules_xcodeproj by brentleyjones 2 years ago
- Ensure Bazel uses the correct Xcode version when compiling (#1099) This is three changes: - On the command-line, set `--xcode_version` to whatever `xcode-select` is set to - In Xcode, set `--xcode... — committed to MobileNativeFoundation/rules_xcodeproj by brentleyjones 2 years ago
- Revert runner set `--xcode_version` While `bazel_build.sh` should still have `--xcode_version`, to ensure that Bazel uses the version of Bazel you are building inside of, setting `--xcode_version` ba... — committed to MobileNativeFoundation/rules_xcodeproj by brentleyjones 2 years ago
- Revert runner set `--xcode_version` (#1100) While `bazel_build.sh` should still have `--xcode_version`, to ensure that Bazel uses the version of Xcode you are building inside of, setting `--xcode_v... — committed to MobileNativeFoundation/rules_xcodeproj by brentleyjones 2 years ago
- Ensure Bazel uses the correct Xcode version when compiling (#1099) This is three changes: - On the command-line, set `--xcode_version` to whatever `xcode-select` is set to - In Xcode, set `--xcode... — committed to chiragramani/rules_xcodeproj by brentleyjones 2 years ago
- Revert runner set `--xcode_version` (#1100) While `bazel_build.sh` should still have `--xcode_version`, to ensure that Bazel uses the version of Xcode you are building inside of, setting `--xcode_v... — committed to chiragramani/rules_xcodeproj by brentleyjones 2 years ago
copying that in is definitely an interesting idea, we also run some things in our build on Linux so I think we’d have to do that in a cross platform way though. Definitely handling the arch problem (although you could check fat binaries in there instead if you only supported macOS) would be necessary too
I think doing the input route is easier said than done because it’d be a bit of a circular dependency
@keith one way to sidestep this is to just use a custom
local_config_cc. e.g.YMMV for different host arch than x86_64 🤔
It might be possible to factor out the binaries into their own input to the cc rules rather than compiling in the repo rule, but I don’t know the long term plans for this / overlap with rules_cc off the top of my head!
One thing I realized with the
DEVELOPER_DIRworkaround is that if the user overwrites their Xcode.app with a newer version, theDEVELOPER_DIRwill not change, but the version of Xcode will. So that’s a case where this workaround isn’t enough 😞Using DEVELOPER_DIR in a wrapper around bazel definitely works around the original issue, but it would be nice if it was solved for everyone without having to manually do that.
This would be less of an issue if changing Xcode versions globally with
xcode-selectinvalidated wrapped_clang, but this requires aclean --expungeto recover from