Update to rules_apple 3.0.0 #759

jszumski · 2023-08-31T14:30:18Z

Changes

Uses new provider initialization pattern
This is now private API in rules_apple as of Move to new provider API initialization pattern bazelbuild/rules_apple#2184 but visibility was relaxed in Remove bzl visibility for now bazelbuild/rules_apple#2225 to avoid breaking us.
Drops support for i386 slices in xcframeworks
Dropped upstream in Removing any support for Xcode prior to 14 from the rules. bazelbuild/rules_apple#2155.
Passes through minimum_os_version to all test rules
Required upstream in Require minimum_os_version bazelbuild/rules_apple#2124.
Uses new split transition
Core's apple_common.multi_arch_split was removed in Bazel 7 and replaced by rules_apple's apple_platform_split_transition: Replace apple_common.multi_arch_split with new transition bazelbuild/rules_apple#2034

Remaining work

~~Update project generation rules~~
Run buildifier
Decide if we should try to make these changes backwards-compatible no
Decide if this is a good time to drop Bazel 5 support yes

jerrymarino · 2023-09-05T22:01:02Z

rules/framework.bzl

@@ -25,6 +25,7 @@ load("@build_bazel_rules_apple//apple/internal:apple_toolchains.bzl", "AppleMacT
 load("@build_bazel_rules_apple//apple/internal:swift_support.bzl", "swift_support")
 load("@build_bazel_rules_apple//apple/internal/utils:clang_rt_dylibs.bzl", "clang_rt_dylibs")
 load("@build_bazel_rules_apple//apple:providers.bzl", "AppleBundleInfo", "IosFrameworkBundleInfo")
+load("@build_bazel_rules_apple//apple/internal:providers.bzl", "new_applebundleinfo")


Do we need to rely on yet another internal provider from rules_apple here? It seems like it would continue to work well on 5.x.x pretty easily w/o the change?

Also the issue with this line is everyone will have to run a commit later than:
bazelbuild/rules_apple#2194

It's incompatible because the initializer intentionally fails here in _make_banned_init:

AppleBundleInfo, new_applebundleinfo = provider( doc = ..., fields = { ... }, init = _make_banned_init(provider_name = "AppleBundleInfo"), )

Keeping rules_ios close to the head of rules_apple was intentional with this change.

Yeah what I'm wondering, is how to make it work backwards with older versions:

e.g.

# in rules_ios/framework.bzl or util module def _wrapped_bundule_init(**kwargs): if old_version: return AppleBundleInfo(kwargs) else: return new_applebundleinfo(kwargs)

Though the initializer moving to a private API which used to be public is another story 😮‍💨

jszumski · 2023-09-06T16:41:31Z

rules/library.bzl

-                if (arch == "armv7s" or arch == "arm64e"):
-                    # unsupported platform-arch by rules_apple
+                # unsupported platform-arch by rules_apple
+                unsupported_platforms = ["armv7", "armv7s", "i386"]


Dropping arm64e was intentional here since it exists in rules_apple

Does this works on 2.5?

jerrymarino

I'm going to review this update and see what it takes to support older versions.

Use new provider initialization pattern, use new apple_platform_split_transition, drop support for i386 slices in xcframeworks, passthrough minimum_os_version to all test rules.

jerrymarino

It seems like with few quick changes there isn't a reason it wouldn't support 2.5.x by making some of these conditional. Likely this can be done with wrappers to further centralize the calling of rules_apple APIs here

jerrymarino · 2023-09-27T20:31:18Z

rules/library.bzl

-                if (arch == "armv7s" or arch == "arm64e"):
-                    # unsupported platform-arch by rules_apple
+                # unsupported platform-arch by rules_apple
+                unsupported_platforms = ["armv7", "armv7s", "i386"]


Does this works on 2.5?

jerrymarino · 2023-09-27T20:35:07Z

rules/framework.bzl

@@ -664,8 +675,11 @@ def _bundle_dynamic_framework(ctx, is_extension_safe, avoid_deps):
    resource_deps = ctx.attr.deps + ctx.attr.transitive_deps + ctx.attr.data
    current_apple_platform = transition_support.current_apple_platform(apple_fragment = ctx.fragments.apple, xcode_config = ctx.attr._xcode_config)
    platform_type = str(current_apple_platform.platform.platform_type)
-    rule_descriptor = rule_support.rule_descriptor_no_ctx(platform_type, apple_product_type.framework)
-    platform_prerequisites = _platform_prerequisites(ctx, rule_descriptor, platform_type)
+    rule_descriptor = rule_support.rule_descriptor(


Any way to plumb in the rule_descriptor from above?

jerrymarino · 2023-09-27T20:36:39Z

rules/framework.bzl

@@ -694,6 +708,7 @@ def _bundle_dynamic_framework(ctx, is_extension_safe, avoid_deps):
        ctx,
        avoid_deps = avoid_deps,
        entitlements = None,
+        exported_symbols_lists = ctx.files.exported_symbols_lists,


# If this isn't backwards compatible with 2.5.0 if rules_apple_api_version_3: kwargs["exported_symbols_lists"] = ctx.files.exported_symbols_lists else: kwargs[" executable_name"] = bundle_name

jerrymarino · 2023-09-27T20:39:28Z

rules/framework.bzl

@@ -1053,23 +1073,23 @@ apple_framework_packaging = rule(
        ),
        "deps": attr.label_list(
            mandatory = True,
-            cfg = apple_common.multi_arch_split,
+            cfg = rules_apple_transition_support.apple_rule_transition,


Possible to add conditional assignment at the top of framework.bzl or in some other file? e.g. :

if rules_apple_api_version_3: apple_dep_transition = rules_apple_transition_support.apple_rule_transition else: apple_dep_transition = apple_common.multi_arch_split

Then - consuming it here:

cfg = apple_dep_transition

jerrymarino · 2023-09-27T20:39:59Z

rules/precompiled_apple_resource_bundle.bzl

@@ -52,6 +53,7 @@ def _precompiled_apple_resource_bundle_impl(ctx):

    platform_prerequisites = platform_support.platform_prerequisites(
        apple_fragment = ctx.fragments.apple,
+        build_settings = None,


May or many not need fixing if it passes CI with 2.5 / LTS enabled

jerrymarino · 2023-09-27T20:40:48Z

tools/vmd/vm_test_runner.bzl

@@ -19,7 +19,7 @@
 """iOS test runner rule."""

 load(
-    "@build_bazel_rules_apple//apple/testing:apple_test_rules.bzl",


Might need other way to load it

Can you conditionalize load statements? I didn't think so but maybe I'm wrong

Yeah sure - we can unify the sims in a starlark file we load in “rules ios dependencies” - based on the api version.

jerrymarino · 2023-09-29T19:27:49Z

@jszumski last night I pulled this down and looked at at bit. It seems like there are 2 distinct issues here:

making rules_ios work correctly with rules_apple 3.0.0 - this is easier said than done and the errors you have in the CI job are the tip of the iceberg. I'm trying to find the simplest way for to unblock you and others.
cleanup and refactoring some stuff to better support pt1 and also consequently older rules_apple.

jerrymarino · 2023-09-29T21:52:15Z

Submitting and end to end implementation of this.

jerrymarino reviewed Sep 5, 2023

View reviewed changes

jszumski commented Sep 6, 2023

View reviewed changes

jszumski force-pushed the jszumski/update-rules-apple-3.0.0 branch from 9009b1a to 7e1d2aa Compare September 6, 2023 18:48

jszumski changed the base branch from master to jszumski/drop-bazel-5 September 6, 2023 18:49

jszumski force-pushed the jszumski/drop-bazel-5 branch from 305a4f7 to fb044b7 Compare September 6, 2023 19:59

jszumski force-pushed the jszumski/update-rules-apple-3.0.0 branch from 7e1d2aa to 771a0cb Compare September 6, 2023 20:36

jerrymarino reviewed Sep 7, 2023

View reviewed changes

Update to rules_apple 3.0.0

3b4e5ef

Use new provider initialization pattern, use new apple_platform_split_transition, drop support for i386 slices in xcframeworks, passthrough minimum_os_version to all test rules.

jszumski force-pushed the jszumski/update-rules-apple-3.0.0 branch from 771a0cb to 3b4e5ef Compare September 7, 2023 20:57

jerrymarino reviewed Sep 27, 2023

View reviewed changes

jerrymarino mentioned this pull request Sep 27, 2023

Update rules_apple to 3.0.0 #771

Closed

jerrymarino closed this Sep 29, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update to rules_apple 3.0.0 #759

Update to rules_apple 3.0.0 #759

jszumski commented Aug 31, 2023 •

edited

Loading

jerrymarino Sep 5, 2023

jerrymarino Sep 5, 2023

jszumski Sep 5, 2023 •

edited

Loading

jerrymarino Sep 6, 2023 •

edited

Loading

jszumski Sep 6, 2023

jerrymarino Sep 27, 2023

jerrymarino left a comment

jerrymarino left a comment •

edited

Loading

jerrymarino Sep 27, 2023

jerrymarino Sep 27, 2023

jerrymarino Sep 27, 2023

jerrymarino Sep 27, 2023

jerrymarino Sep 27, 2023

jerrymarino Sep 27, 2023

jszumski Sep 28, 2023

jerrymarino Sep 28, 2023

jerrymarino Sep 28, 2023

jerrymarino commented Sep 29, 2023

jerrymarino commented Sep 29, 2023

Update to rules_apple 3.0.0 #759

Update to rules_apple 3.0.0 #759

Conversation

jszumski commented Aug 31, 2023 • edited Loading

Changes

Remaining work

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jszumski Sep 5, 2023 • edited Loading

Choose a reason for hiding this comment

jerrymarino Sep 6, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jerrymarino left a comment

Choose a reason for hiding this comment

jerrymarino left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jerrymarino commented Sep 29, 2023

jerrymarino commented Sep 29, 2023

jszumski commented Aug 31, 2023 •

edited

Loading

jszumski Sep 5, 2023 •

edited

Loading

jerrymarino Sep 6, 2023 •

edited

Loading

jerrymarino left a comment •

edited

Loading