Keith Smiley
Keith Smiley
maybe https://github.com/bazelbuild/bazel/pull/24690 is the better solve here
++, details on how this could be fixed here https://github.com/bazelbuild/rules_swift/issues/1211
with bazel 8.x+ (I think, maybe earlier) we can actually drop all the logic that uses that tool since this codepath https://github.com/bazelbuild/rules_cc/blob/71bdd947587c95c147687d0ac2aacdd1c25e3fcd/cc/private/toolchain/unix_cc_toolchain_config.bzl#L907-L909 makes it so rewrites aren't necessary
Ah yea if you want to use this executable in your own action that's a different case from what I assumed you meant
looks like this fails on bazel 8.x, smells like it needs a rules update of some sort
I submitted https://github.com/bazelbuild/bazel/pull/27863 which at least adds this for test targets.
probably the same local env issues as discussed on https://github.com/bazelbuild/bazel/issues/23111
yea for sure we can check for `None` in that codepath and error. It just doesn't come up too much so folks haven't been super motivated to improve it
this specific logic is doing non-hermetic stuff to make sure the absolute path to Xcode doesn't appear in the action keys. specifically the resulting path here https://github.com/bazelbuild/bazel/blob/2d14aa2e3f4e7b7b9893c23b26fdb32f84e5fef3/src/main/java/com/google/devtools/build/lib/exec/local/XcodeLocalEnvProvider.java#L95-L96 is absolute and...
here's a fix for this crash https://github.com/bazelbuild/bazel/pull/27043 that I think is reasonable. But there are some outstanding UX issues we should fix. 1. How should just the command line tool...