-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Update unknown Xcode version error message and provide an environment variable to force re-evaluation #19512
Conversation
… variable to force re-evaluation As of c747ae7, you need to run `bazel sync --configure` instead of `bazel shutdown`, to force re-finding of Xcode versions. Certain setups have a hard time running that new command, versus previously only having to cause Bazel to restart. To accommodate that, I’ve also added the `XCODE_VERSION` variable to `environ` (to match a similar use defined here: bazelbuild/apple_support@ddf25c2), which allows those setups to force the re-evaluation by using `--repo_env`. Signed-off-by: Brentley Jones <github@brentleyjones.com>
@brentleyjones Could you elaborate on what challenges are linked to running (The PR is totally fine, I just want to understand this better.) |
In rules_xcodeproj we have nested Bazel invocations and output bases. Users don't run commands on the nested output bases, so if they run |
Signed-off-by: Brentley Jones <github@brentleyjones.com>
@bazel-io flag |
@bazel-io fork 6.4.0 |
… variable to force re-evaluation As of c747ae7, you need to run `bazel sync --configure` instead of `bazel shutdown`, to force re-finding of Xcode versions. Certain setups have a hard time running that new command, versus previously only having to cause Bazel to restart. To accommodate that, I’ve also added the `XCODE_VERSION` variable to `environ` (to match a similar use defined here: bazelbuild/apple_support@ddf25c2), which allows those setups to force the re-evaluation by using `--repo_env`. And since the `default` attribute is influenced by `DEVELOPER_DIR`, I've included that in `environ` as well. Closes bazelbuild#19512. PiperOrigin-RevId: 565610471 Change-Id: Ideca7165308ce53fdf1ce22b31eeb7a9e681dedc
…ironment variable to force re-evaluation (#19540) As of c747ae7, you need to run `bazel sync --configure` instead of `bazel shutdown`, to force re-finding of Xcode versions. Certain setups have a hard time running that new command, versus previously only having to cause Bazel to restart. To accommodate that, I’ve also added the `XCODE_VERSION` variable to `environ` (to match a similar use defined here: bazelbuild/apple_support@ddf25c2), which allows those setups to force the re-evaluation by using `--repo_env`. And since the `default` attribute is influenced by `DEVELOPER_DIR`, I've included that in `environ` as well. Closes #19512. Commit 19979e6 PiperOrigin-RevId: 565610471 Change-Id: Ideca7165308ce53fdf1ce22b31eeb7a9e681dedc Co-authored-by: Brentley Jones <github@brentleyjones.com>
The changes in this PR have been included in Bazel 6.4.0 RC1. Please test out the release candidate and report any issues as soon as possible. If you're using Bazelisk, you can point to the latest RC by setting USE_BAZEL_VERSION=last_rc. |
As of c747ae7, you need to run
bazel sync --configure
instead ofbazel shutdown
, to force re-finding of Xcode versions.Certain setups have a hard time running that new command, versus previously only having to cause Bazel to restart. To accommodate that, I’ve also added the
XCODE_VERSION
variable toenviron
(to match a similar use defined here: bazelbuild/apple_support@ddf25c2), which allows those setups to force the re-evaluation by using--repo_env
. And since thedefault
attribute is influenced byDEVELOPER_DIR
, I've included that inenviron
as well.