`ctx.attr._product_type` always being set to `apple_product_type.static_framework` in `apple_framework_packaging`

[Thiago Cruz]

Due to this default some bundling steps of apple_framework_packaging are running with product_type = apple_product_type.static_framework always. Even when the intent is bundling a dynamic framework (i.e. link_dynamic is True).

#741 helps with one of the steps and fixes MACH_O_TYPE in Xcode but we still rely on the hard coded value of ctx.attr._product_type in a few places:

• bundle_name, bundle_extension
• executable_name
• platform_prerequisites

Maybe there's more but these are the ones I've found on a first scan. Essentially, if you follow the code paths above, any step that under the hood instantiates rule_descriptor in rules_apple.

To fix this I see two paths (each with its own trade-offs):

1. Remove ctx.attr._product_type from apple_framework_packaging
   • The problem here is that the steps above that rely on rule_descriptor and hence ctx.attr._product_type being set will break so we'll have to get the same values some other way
2. Keep ctx.attr._product_type but conditionally instantiate apple_framework_packaging_* with different product_type values depending on link_dynamic being True/False
   • The problem here is that we'll need a rule_factory approach similar to rules_apple and instantiate two rules apple_framework_packaging_static and apple_framework_packaging_dynamic and instantiate those using the factory similar to what rules_apple does. That would break many things AFAICT, even if we use macro/alias to keep the name apple_framework_packaging and conditionally instantiate _static/_dynamic other rules/aspects/tools implemented by folks (in OSS or internally) would break due to the actual rule name changing and apple_framework_packaging not being a concrete rule anymore.

[Luis Padron]

For # 2, I know our tools definitely make assumptions about apple_framework_packaging being the top-level target so if that changes we'd need to update. This is fine with me if we think thats the best approach.

[Thiago Cruz]

Same, internally we do have tools that make assumptions on apple_framework_packaging being a thing. Same with the rules_xcodeproj integration. So if we go with 2. we need a plan to minimize breakages there.

One additional thing to consider in 1. is mimicking rules_apple code in rules_ios and use our own rule_descriptor, but that will likely imply transitively mimicking more things and further diverging from rules_apple which is not a great thing IMO.

[Jerry Marino]

I'd love to see some PRs that work end to end 🚢

[Jerry Marino]

At the EOD _product_type has always been an internal attribute so basically it's an implementation quirk and not super bad

[Thiago Cruz]

I'd love to see some PRs that work end to end

When possible I prefer those too, but if it requires discussion/learning/alignment I think it's better to iterate on steps and solve one sub-problem at a time.

[Jerry Marino]

Ah interesting, I think the rule apple_framework_pacakaging needed a simple cleanup to remove it. While _product_type was internal/ unused it still led to some perceived complexity #742