Support hermetic developer directories in the crosstool#616
Closed
AttilaTheFun wants to merge 1 commit into
Closed
Support hermetic developer directories in the crosstool#616AttilaTheFun wants to merge 1 commit into
AttilaTheFun wants to merge 1 commit into
Conversation
- Allow callers of configure_osx_toolchain to pass extra builtin include directories, so toolchains and SDKs vendored into external repositories (hermetic developer directories) are not flagged as undeclared inclusions. - Treat a path-valued Xcode version (an absolute developer directory path, as already supported by xcode_support.is_xcode_at_least_version and by Bazel's DEVELOPER_DIR handling) as the latest Xcode in the cc_toolchain_config feature checks instead of failing to compare it against a dotted version.
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 4, 2026
The macos-26 arm64 runner image ships Xcode 26.5 preinstalled; CI registers it as a hermetic Xcode by path (rewriting the marked machine-local block in MODULE.bazel), builds the example, checks the app's DTXcodeBuild stamp against the registered Xcode, and runs it in the runner's iOS 26.5 simulator, asserting on the app's log output. Switch the apple_support override from local_path_override to a git_override of the fork commit backing bazelbuild/apple_support#616 so checkouts (and CI) build without a sibling apple_support checkout; local development uses --override_module in the gitignored .bazelrc.user. Claude-Session: https://claude.ai/code/session_01JRwE8au75o3HEuL2CdzUXW
keith
reviewed
Jul 6, 2026
| repository_ctx.file(dest, content = repository_ctx.read(src)) | ||
|
|
||
| def configure_osx_toolchain(repository_ctx): | ||
| def configure_osx_toolchain(repository_ctx, extra_include_dirs = []): |
Member
There was a problem hiding this comment.
this api isn't meant to be called externally and is being replaced by the rules based toolchain. can you use that one instead?
also i believe the value you're passing to this in your current rules is wrong and will ignore everything in external, which will break all header discovery bazelbuild/bazel#29613
Contributor
Author
There was a problem hiding this comment.
oh let me see if this is even necessary with the rules based implementation. if not I can just drop it or else fix it another way
Contributor
Author
|
Closing in favor of the rules-based toolchain per the review — migrating to it removed the need for both changes here. The one remaining gap (include validation for vendored developer dirs) is addressed additively in the follow-up PR. |
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.
Two small changes needed by hermetic_apple_toolchains, which registers verbatim Xcode.app copies inside external repositories and drives the build with a path-valued
--xcode_version(an absolute developer directory path, which Bazel uses directly asDEVELOPER_DIR).configure_osx_toolchaingains anextra_include_dirsparameter so a wrapping repository rule can allow builtin includes from the external repository root, where the vendored Xcodes live. (Without this, headers resolved from the hermetic SDKs are flagged as undeclared inclusions, since they are outside the default /Applications and /Library include roots.)cc_toolchain_config.bzltreats a path-valued Xcode version as the latest Xcode in its two inline>=feature checks (no_warn_duplicate_libraries,reproducible_linker_flag) instead of failing with an unparseable dotted version.The path-as-version semantics in the second bullet are not new — this extends an existing, Apple-contributed convention to the last place that still hard-fails on it:
XCODE_VERSION_OVERRIDEis used directly asDEVELOPER_DIR("Directly use version as DEVELOPER_DIR when a path is passed",XcodeLocalEnvProvider.java).xcode_support.is_xcode_at_least_versionreturnsTruefor path-valued versions since fix(xcode_support): handle Xcode version starting with path separator #481 ("We're gonna assume that if the user passes Xcode as a directory, they're ok managing the features themselves, and we'll assume they're on the latest and greatest Xcode")._is_xcode_at_least_versiondoes the same since fix(toolchain): handle Xcode version starting with path separator rules_swift#1597.The new helper in
cc_toolchain_config.bzlmirrors those implementations; the two inline comparisons were added later (for the Xcode 15 and Xcode 26 linker flags) and never picked up the convention. Without this, analysis fails with a Starlark error when comparing the path againstapple_common.dotted_version("15.0").