incompatible_objc_provider_remove_linking_info

[googlewalt]

This flag is part of the efforts to migrate ObjcProvider linking info to CcLinkingContext. It removes the Starlark APIs related to the definition and use of linking info in ObjcProvider. See #17377 for more details on the overall efforts.

Specifically, the flag does the following:

• apple_common.new_objc_provider() will stop taking the following linking related arguments: cc_library, dynamic_framework_file, flag, force_load_library, imported_library, library, link_inputs, linkopt, sdk_dylib, sdk_framework, static_framework_file, weak_sdk_framework.

• apple_common.new_dynamic_framework_provider() will no longer accept an objc argument. cc_info will be required, not optional.

• apple_common.new_executable_binary_provider() will no longer accept an objc argument. cc_info will be required, not optional.

• The following linking related APIs will be removed:

  • In ObjcProvider: cc_library, dynamic_framewrok_file, force_load_library, imported_library, library, link_inputs, linkopt, sdk_dylib, sdk_framework, static_framework_file, weak_sdk_framework, dynamic_framework_names, dynamic_framework_paths, static_framework_names, static_framework_paths.
  • In AppleDynamicFrameworkInfo: objc.
  • In AppleExecutableBinaryInfo: objc.

The flag will be available shortly, and will be kept disabled for 7.0. The flag will be flipped in coordination with OSS apple_rules.

[googlewalt]

@keith @brentleyjones FYI.

[brentleyjones]

Since all of these are removals, there is no way (afaict) to dynamically detect if this flag is flipped. So we will need a value on a fragment (or apple_common?) that we can check that reflects the value of this flag.

[googlewalt]

brentleyjones@ can you clarify why you need dynamic detection of this flag?

The idea is that by the time we get to this stage of the migration, all the APIs guarded by this flag no longer does anything useful, and can safely be deleted. Given the progress of rules_apple as indicated in #17377, I believe the version of rules_apple of used for 6.x and 7.x can safely remove all the deprecated APIs.

This migration mirrors that of the compile info migration (#11359), and back then we did not need value of such a flag.

[brentleyjones]

I believe the version of rules_apple of used for 6.x and 7.x can safely remove all the deprecated APIs.

I don't think we are there yet, but if that's the case, then yes, we won't need dynamic detection, we can just remove the APIs. I maybe misunderstood this purpose of the flag. Did rules_apple around the time of change maintain support for older Bazel versions? The key thing for us is that a single version of rules_apple needs to work for both Bazel 6 and 7.

[googlewalt]

I'm no familiar with development of OSS version rules_apple, but our plan discussed in #17377 was to get rules_apple to a state so that the previous flag, --incompatible_objc_linking_info_migration, could be enabled. Now that we have done that, rules_apple should be able to support both 6.0 and 7.0. Any cleanups related to this new flag can go in without breaking compatibility with 6.0.

[keith]

I noticed one case where we might have to conditionalize the rules for 6.x vs 7.x trying to land https://github.com/bazelbuild/rules_apple/pull/1872/files which removes uses of dynamic_framework_file. 6.x errors with:

Error in new_executable_binary_provider: new_executable_binary_provider() missing 1 required named argument: objc

Maybe I could provide an empty one in that case instead though

[googlewalt]

Good point. The relevant bazel change is https://github.com/bazelbuild/bazel/commit/28f905675c98c652badbcbc7510134aab08dc4fb. Using an empty objc should suffice.