Make allowlist_include_directories more flexible for paths

[keith]

When trying to write a toolchain with the new rule based mechanism, on macOS we likely need some feature like this:

cc_args(
    name = "apple_sysroot",
    actions = [
        "@rules_cc//cc/toolchains/actions:compile_actions",
        "@rules_cc//cc/toolchains/actions:link_actions",
    ],
    allowlist_include_directories = [
        "/",
    ],
    args = [
        "-isysroot",
        "__BAZEL_XCODE_SDKROOT__",
    ],
)

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.

[pzembrod]

Wouldn't allowlisting include dir "/" disable all hermeticity? I probably don't really understand your proposal yet.

[keith]

/ 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

[armandomontanez]

I haven't had time to polish it up in a way that's more widely sharable, but it's possible to allowlist these directories on macOS with a little elbow grease. This is how the project I primarily work on adds these directories:

https://cs.opensource.google/pigweed/pigweed/+/main:pw_toolchain/xcode.bzl
https://cs.opensource.google/pigweed/pigweed/+/main:pw_toolchain/host_clang/macos_sysroot.BUILD

I took a quick look at the link provided, and it seems like it should be feasible to translate the existing approach in apple_support.