Make strip_include_prefix apply to textual_hdrs
Mirror of https://github.com/bazelbuild/bazel/pull/26327
cc @trybka
Still seeing failures internally, we might need to put this behind a flag if we don't want to block on Whatever Problems Google Has.
are you thinking a top level bazel flag, or a magic feature to opt out of this behavior, or?
also is there a bug in the implementation that only google is seeing? or is it just that maybe you have to update your #include if the textual_hdrs match the strip_include_prefix? (I thought you would still be able to access them through the fully path 🤔 )
I think we could handle it in semantics.bzl rather than a flag or a feature.
The former would need to either be in Java or Starlark Build Flags both of which seem pretty onerous, the latter of which would need to be yet-another-feature we need to check and we've already encoutered issues using features for this in the past (notably things like platform.flags dropping them on the floor: https://bazel.build/reference/be/platforms-and-toolchains#platform_flags_repeated).
pushed a boolean to that file which can disable this behavior, wdyt about that? idk how your replacements for that file work but I assume it might have the downside that it cannot be enabled in some places and not others (notably the original feature requester of this is a googler)
(Replied to the wrong PR...)
The goal would be to enable it internally soon as well, but to be able to approve this change without blocking on said clean-up.
(The buildkite failures are only in the other PR)
It looks like this is passing most of the builds that were failing before.