-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Register apple toolchains #1106
Conversation
cc @meteorcloudy @Wyverald Is this the right way to register toolchains? They are already registered in apple_support repository. Without registering them here the build fails. It might also be the case that registering them hides an underlying bug. (Also note there is a platform_mapping with @@ in use for bzlmod) |
How did it fail? Is there a log or an error message? |
Oh, it's in #1103? |
It looks like this means it's picking up unexpected toolchains. It might have to do with order of registrations. |
I thought you mentioned The order of the toolchain registration is a BFS order from the root module. Can you enable toolchain debug to check what was going on? |
Is it possible the toolchain registered from |
Here's output of toolchain_resolution_debug Working case (register toolchain also in rules_swift):
Failing case (register toolchain only in apple_support):
Diff is in middle 3 labels: Meaning that Bazel supplied C++ toolchains were selected instead of apple_support ones. |
The fix is probably to consolidate C++ toolchain configuration in Apple Support with the ones in bazel_tools / rules_cc. Maybe also make rules_swift less dependent on the strings in C++ toolchains. @keith can you look into this? |
@meteorcloudy: |
cc @katre At risk of developing a specification in a comment, I think the order should be BFS and then @bazel_tools. Within BFS, the order in MODULE.bazel should be respected, that is the order of deps inside. |
Yes, I guess a better order would be
No, the toolchain defined in root-module will definitely prevail. |
This seems related to an internal issue about making toolchain priority more flexible (bug 262537944 for googlers). I'd rather address that, and mark |
definitely seems worth a fix, having to make users do this duplicate registration seems unexpected |
This will ensure toolchains registered from bazel_dep in users's MODULE.bazel take priority over the ones registered in `bazel_tools`. Context: bazelbuild/rules_swift#1106 RELNOTES: None PiperOrigin-RevId: 563702381 Change-Id: I0b207cb24f34c1d2906123787216bba59ce5d442
- This will ensure toolchains registered from bazel_dep in users's MODULE.bazel take priority over the ones registered in `bazel_tools`. - If the root module already has an override for a builtin module, then the default builtin module override is ignored. Context: bazelbuild/rules_swift#1106 RELNOTES: None PiperOrigin-RevId: 566969573 Change-Id: I0b207cb24f34c1d2906123787216bba59ce5d442
- This will ensure toolchains registered from bazel_dep in users's MODULE.bazel take priority over the ones registered in `bazel_tools`. - If the root module already has an override for a builtin module, then the default builtin module override is ignored. Context: bazelbuild/rules_swift#1106 RELNOTES: None PiperOrigin-RevId: 566969573 Change-Id: I0b207cb24f34c1d2906123787216bba59ce5d442
…19573) - This will ensure toolchains registered from bazel_dep in users's MODULE.bazel take priority over the ones registered in `bazel_tools`. - If the root module already has an override for a builtin module, then the default builtin module override is ignored. Context: bazelbuild/rules_swift#1106 RELNOTES: None PiperOrigin-RevId: 566969573 Change-Id: I0b207cb24f34c1d2906123787216bba59ce5d442
Fixes: #1103 (comment)