Let consumers extend the rules-based toolchain's include allowlist#617
Merged
Merged
Conversation
Adds an extra_include_directories label_flag (default: an empty cc_args)
appended to the toolchain's args. Consumers whose SDKs and toolchains
live outside the standard install locations — for example hermetic
Xcode.app copies vendored into external repositories — can point the
flag at a cc_args with allowlist_absolute_include_directories entries
for those locations:
--@apple_support//toolchain:extra_include_directories=//your:cc_args
This replaces the approach from bazelbuild#616 (which patched the legacy
autoconf's extra include dirs): the flag is analysis-time, additive, and
lets the allowlist be as narrow as the specific developer directories,
avoiding overly broad builtin include entries that can break dependency
tracking (bazelbuild/bazel#29613).
AttilaTheFun
requested review from
aaronsky,
adincebic,
brentleyjones,
keith,
luispadron and
mattrobmattrob
as code owners
AttilaTheFun
added a commit
to AttilaTheFun/hermetic_apple_toolchains
that referenced
this pull request
Jul 6, 2026
The extra_include_directories label_flag is now pending upstream as bazelbuild/apple_support#617; pin the fork commit carrying it (upstream main + that one change) instead of applying a local patch.
AttilaTheFun
added a commit
to AttilaTheFun/hermetic_apple_toolchains
that referenced
this pull request
Jul 6, 2026
* Migrate to apple_support's rules-based CC toolchain Replaces the forked legacy-crosstool changes (bazelbuild/apple_support PR 616) per review feedback. The rules-based toolchain (enabled with APPLE_SUPPORT_RULES_BASED_TOOLCHAIN=1) is driven by the xcode_config at analysis time — a path-valued Xcode version flows straight into DEVELOPER_DIR — and does no fetch-time compiler probing, so the hermetic_apple_cc override repo is gone entirely. Its two version-gated linker features are unconditional, so the path-valued version-check change is moot. apple_support is now stock upstream main (git_override, pinned) plus a ~15-line patch adding an extra_include_directories label_flag to the toolchain, which the hub's new :xcode_include_directories cc_args plugs into to allowlist the vendored developer directories for include validation. The allowlist is deliberately narrow: covering the external root (as the old fork did) silently breaks .d-file change detection for every external repository's headers (bazel#29613). Verified: example builds and simulator runs on both Xcodes (stamps 17F42/23F73 and 27A5209h/24A5370g), rules_xcodeproj generation, and a headless xcodebuild of the generated project. * Point the apple_support override at the upstream PR branch The extra_include_directories label_flag is now pending upstream as bazelbuild/apple_support#617; pin the fork commit carrying it (upstream main + that one change) instead of applying a local patch.
keith
approved these changes
Jul 6, 2026
keith
left a comment
keith
left a comment
Member
There was a problem hiding this comment.
technically users could pass any cc_args here which might not be ideal, but at least the naming is specific enough that if we break that somehow they shouldn't be surprised. I think an extra flag for this feels a bit bad but if we combined it with any other flag you might have conflicting use cases since the flags can only take 1 label at a time.
AttilaTheFun
added a commit
to AttilaTheFun/hermetic_apple_toolchains
that referenced
this pull request
Jul 6, 2026
The extra_include_directories flag merged upstream (bazelbuild/apple_support#617); pin bazelbuild/apple_support directly. The git_override remains only until the toolchain ships in a tagged release, after which a plain bazel_dep suffices.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to the review feedback on #616 — migrating to the rules-based toolchain worked (thanks for the pointer, it removed almost everything we needed from that PR), with one remaining gap: include validation for SDK/toolchain headers that live outside the standard install locations.
This adds an
extra_include_directorieslabel_flag (default: an emptycc_args) appended to the toolchain's args. Consumers whose developer directories live elsewhere — for example verbatim Xcode.app copies vendored into external repositories (hermetic_apple_toolchains) — point the flag at acc_argswithallowlist_absolute_include_directoriesentries for those locations:Being analysis-time and additive, this lets the allowlist stay as narrow as the specific developer directories (avoiding the overly broad builtin include entries from the previous approach, which per bazelbuild/bazel#29613 can silently break dependency tracking for anything under the output base).
Verified with hermetic Xcode 26.5 and 27 beta copies in external repositories: builds, simulator runs, and rules_xcodeproj-generated projects all pass with the flag supplying the vendored developer dirs; without it, compiles of anything touching the SDK fail include validation.