You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Where __BAZEL_XCODE_SDKROOT__ is some internal bazel magic to support hermetic actions that point to arbitrary paths to Xcode itself, since that cannot be vendored as a sysroot. In this case we currently have some very liberal allowed include directories:
so that bazel allows us to include things from these system paths. As far as I can tell with the current mechanism there's no way to allow this, since we can't create a rule pointing to these files without breaking the hermiticity goals.
The text was updated successfully, but these errors were encountered:
/ isn't particularly the best example, although folks might actually want to use that with docker images they control. But you can see at the link above there are arbitrary system paths, especially on macOS, where we "know" there will never be headers we're worried about, but there might be some SDK components that need to be allowed
When trying to write a toolchain with the new rule based mechanism, on macOS we likely need some feature like this:
Where
__BAZEL_XCODE_SDKROOT__
is some internal bazel magic to support hermetic actions that point to arbitrary paths to Xcode itself, since that cannot be vendored as a sysroot. In this case we currently have some very liberal allowed include directories:https://github.com/bazelbuild/apple_support/blob/27149c867d593302e5edf31347f565fc70871826/crosstool/osx_cc_configure.bzl#L34-L44
so that bazel allows us to include things from these system paths. As far as I can tell with the current mechanism there's no way to allow this, since we can't create a rule pointing to these files without breaking the hermiticity goals.
The text was updated successfully, but these errors were encountered: