-
Notifications
You must be signed in to change notification settings - Fork 4.2k
wrapped_clang is not built with the requested Xcode versions #8902
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
wrapped_clang is not built with the requested Xcode versions #8902
Comments
This would be less of an issue if changing Xcode versions globally with |
@scentini do you have a suggestion for how to fix this? Having to |
cc/ @hlopko |
@hlopko do you have any suggestion for how to fix this? |
This should also potentially consider the |
Would passing that through cause invalidation when the user's Xcode version changed? Maybe if we correctly accessed it in the workspace rule it could help? |
If the user set their Xcode version that way, then yes. But if all they did was change |
Yea, I was at least thinking that in your bazel wrapper you could always specify that var if it would fix this |
Ohh, yeah, it could read the set value and then export it. The workspace rule can state that it should invalidate based on the environment variable. I think that would work nicely. It would differ from |
If the PR above didn't fix this issue, please re-open. |
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. |
One thing I realized with the |
@keith one way to sidestep this is to just use a custom
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! |
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 in order to make the binary an input to the toolchain w/o a circle you'll need another rule to compile it: e.g. a rule that consumes only the relevant xcode config bits and not the custom toolchain. As the toolchain will be specific to macOS, you might need to override |
For what it's worth, it seems like making |
This compiles wrapped_clang and wrapped_clang_pp inside of an action. bazelbuild#8902 has a larger definition of the issue. This action needs the DEVELOPER_DIR as an input in order to select the correct clang. This is passed in from apple_common.XcodeVersionConfig. Note that this works for local execution and needs to address the TODO for cc_wrapper.sh in tools/cpp/osx_cc_configure.bzl.
I've put up a WIP commit to test out compiling the wrappers with a rule that depends on the Xcode env. It looks like we can compile this with the It seems like this is the right approach - plus fixing the last TODO is addressed on that commit. Does anyone see any downsides to compiling this with a rule? If not I can prepare that commit for a PR cc @keith @hlopko |
|
@brentleyjones yep passing the entire Xcode env is how I was looking to solve it for good. This is similar to how other C compiler rules work 👍 #11716 alone won't help the use case where people use Xcode mac app store to install Xcode to `/Applications/Xcode.app The 3 ways I know of to fix this are:
|
This is three changes: - On the command-line, set `--xcode_version` to whatever `xcode-select` is set to - In Xcode, set `--xcode_version` to `$XCODE_PRODUCT_BUILD_VERSION` - For both, set `--repo_env=USE_CLANG_CL= $XCODE_PRODUCT_BUILD_VERSION` to work around bazelbuild/bazel#8902
This is three changes: - On the command-line, set `--xcode_version` to whatever `xcode-select` is set to - In Xcode, set `--xcode_version` to `$XCODE_PRODUCT_BUILD_VERSION` - For both, set `--repo_env=USE_CLANG_CL= $XCODE_PRODUCT_BUILD_VERSION` to work around bazelbuild/bazel#8902
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` based on `xcode-select` can counter-act some people's use of `--xcode_config`. We leave the `--repo_env` though to at least try to fix bazelbuild/bazel#8902.
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_version` based on `xcode-select` can counter-act some people's use of `--xcode_config`. We leave the `--repo_env` though to at least try to fix bazelbuild/bazel#8902.
…iveFoundation#1099) This is three changes: - On the command-line, set `--xcode_version` to whatever `xcode-select` is set to - In Xcode, set `--xcode_version` to `$XCODE_PRODUCT_BUILD_VERSION` - For both, set `--repo_env=USE_CLANG_CL= $XCODE_PRODUCT_BUILD_VERSION` to work around bazelbuild/bazel#8902
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_version` based on `xcode-select` can counter-act some people's use of `--xcode_config`. We leave the `--repo_env` though to at least try to fix bazelbuild/bazel#8902.
To recap since this has bitten me again: if you have We probably want a fix that uses |
Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team ( |
@bazelbuild/triage not stale |
Uh oh!
There was an error while loading. Please reload this page.
Description of the problem / feature request:
Currently
wrapped_clang
is built as part of thelocal_config_cc
setup:bazel/tools/cpp/osx_cc_configure.bzl
Lines 111 to 121 in 0b5f341
Currently it doesn't take into account what you pass for
--xcode_version
. Because of this if you change yourxcode-select
on macOS and build with a different version of Xcode than is requested with this flag, you produce a differentwrapped_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.app
bazel build some_ios_target --xcode_version=10.2.1 --remote_http_cache=...
bazel clean --expunge
sudo xcode-select -s /Applications/Xcode-11beta3.app
bazel 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
The text was updated successfully, but these errors were encountered: