Update rules_apple to 2.0.0
#633
Conversation
# Summary Only validate the dynamic frameworks (those with `apple_common.AppleDynamicFramework`) when calling the `partials.extension_safe_validation_partial` partial. This mimics the `rules_apple` approach more correctly: https://github.com/bazelbuild/rules_apple/blob/eb5c03a606b103e9f8b72de954103eb00cf127f7/apple/internal/ios_rules.bzl#L1049-L1053
mattrobmattrob
force-pushed
the
mr/update.rules_apple.to.2.0.0
branch
2 times, most recently
from
d20e203
to
0bf82ba
Compare
Update `rules_apple` to https://github.com/bazelbuild/rules_apple/releases/tag/2.0.0: - Handle bazelbuild/rules_apple@c23720d by adding `cc_info` param to `framework_provider_partial` call. - Handle bazelbuild/rules_apple@51d6273 by removing `bin_root_path`/`rule_label` param to `debug_symbols_partial` call. - Handle bazelbuild/rules_apple@a4de222 by removing the `apple_xcframework.framework_type` param.
This works around bazelbuild/rules_apple#1797.
mattrobmattrob
force-pushed
the
mr/update.rules_apple.to.2.0.0
branch
from
0bf82ba
to
c997703
Compare
There was a problem hiding this comment.
Nice one @mattrobmattrob 🥳 - LGTM but leaving a minor comment around this test case, the linked rules_apple code would fix a bug for me but if this unblocks it for you I can followup and fix it
| @@ -35,7 +35,6 @@ apple_xcframework( | |||
| name = "iOSSwiftXCFramework", | |||
| bundle_id = "com.google.example", | |||
| bundle_name = "c", | |||
| framework_type = ["dynamic"], | |||
There was a problem hiding this comment.
Does this now automatically detect this? If so - nice 👍 !
There was a problem hiding this comment.
It seems like it was only ever supported as a single value and now it's just not an attribute at all: bazelbuild/rules_apple@a4de222
| @@ -1,7 +1,7 @@ | |||
| load("//rules:framework.bzl", "apple_framework") | |||
|
|
|||
| apple_framework( | |||
| name = "NestedHeaders", | |||
There was a problem hiding this comment.
The nice thing here - detecting Headers captures and tests an obscure usage and some of bugs in rules_ios like
https://github.com/bazelbuild/rules_apple/pull/1798/files 🙈
Is there any way we can undo this now that you've got it fixed in rules_apple. Also I wonder why objc_import is even dealing with headers now - I think there was a limitation around it that caused it to only pull linkable files like .a or .so
There was a problem hiding this comment.
Yeah, since I've gotten it fixed in rules_apple, I'm happy to revert this change and update to an even newer rules_apple commit.
Handle https://github.com/bazelbuild/rules_apple/pull/1552/files or bazelbuild/rules_apple@5d7d31d by self-identifying the `modulemap` file(s) since the forwarding of them in `ObjcProvider` was removed.
mattrobmattrob
force-pushed
the
mr/update.rules_apple.to.2.0.0
branch
from
a1efa24
to
d740c4e
Compare
|
Asking for another look from you, @jerrymarino. Would be nice to get #632 merged before this one as well. |
|
And since this PR/ |
Update
rules_appleto https://github.com/bazelbuild/rules_apple/releases/tag/2.0.0:cc_infoparam toframework_provider_partialcall.bin_root_path/rule_labelparam todebug_symbols_partialcall.apple_xcframework.framework_typeparam..modulemapfiles in static/dynamic frameworks.apple_*_framework_importincorrectly classifies framework files withHeadersin path bazelbuild/rules_apple#1797 by renaming aNestedHeaders/directory toNested/for now.These parameter changes are likely breaking for folks with a different
rules_appleso we'll want to take that into account before merging this PR. This is currently blocked by #632.