--incompatible_remove_ctx_apple_fragment

[dabanki]

Motivation

Part of Starlarkifying native Bazel flags: move language-specific flags out of the Bazel binary and into the rule set's .bzl definitions. This gives rules owners (in this case, primarily rules_apple) more ownership over their logic and decouples the flag definitions from Bazel releases.

This Starlarkifies flags previously defined in AppleCommandLineOptions.java.

This removes ctx.fragments.apple.

Description

When flipped, this flag causes Bazel to no longer provide the native apple fragment. ctx.fragments.apple will no longer exist.

A new rules_apple release will use the absence of this fragment as a signal to read all equivalent flag values from Starlark-defined build settings within the rules_apple repository.

This is intended to be a user no-op for most Apple builds. However, there are some differences meriting an incompatible flag:

1. Setting Starlark flags requires an equals sign: $ bazel build //foo --//my:flag=value must be used instead of $ bazel build //foo --//my:flag value. Since we will be aliasing the old native flags to the new Starlark flags, this means users must use the --flag=value syntax for the affected Apple flags.
2. Your repository must load rules_apple for the Apple Starlark flags to be defined and resolved. This should generally already be true for Apple builds, but could affect scenarios like select() statements on Apple flags in non-Apple rules if rules_apple isn't loaded.
3. If you have custom .bzl code or aspects that read from ctx.fragments.apple, this will break. You need to update your code to read the equivalent Starlark build settings defined in rules_apple. Please comment on this issue if you need guidance on mapping old fragment fields to the new Starlark settings.

This change only affects Bazel 10+ (or whatever version this flag is enabled in). Older Bazel versions will continue to work with any version of rules_apple (both old and new, assuming the new rules_apple maintains backward compatibility for older Bazel versions).

Incompatible Flag

--incompatible_remove_ctx_apple_fragment

Migration Guide

• If using Bazel 10.0+: Update to a recent rules_apple version that supports Starlark-based flags. Release information for the required rules_apple version is TBD. Ensure all invocations of former native Apple flags use the --flag=value syntax.
• If using Bazel <10.0: No action is needed. The native fragment will still be available.

In which Bazel LTS version will this incompatible change be enabled?

Targeting Bazel 10 (or possibly earlier patch into 9).

TODO List

• Prepare and release the version of rules_apple that reads from Starlark settings when ctx.fragments.apple is not present.
• Add flag aliases to rules_apple/MODULE.bazel to map old native flag names to the new Starlark settings (e.g., flag_alias("ios_minimum_os", "//:ios_minimum_os")).
• Flip the flag default to true in Bazel.
• Eventually, remove the native Apple fragment and options class from the Bazel binary.

[brentleyjones]

FYI, we might need to do some/all of this in apple_support as well.

[dabanki]

Yeah, I did see references to the flags we plan to move over are also in apple_support and rules_swift. Is there any complication there? I had planned on still doing the Starlarkified version of these flags in:

https://github.com/bazelbuild/rules_apple/tree/9c9f156783068065e23bcdd982706675361f0068/apple/build_settings

assuming that rules_apple will always be included so that the new flags will be available when needed.

[brentleyjones]

apple_support is probably the correct home, being depended on by both rules_apple and rules_swift. rules_swift can't depend on rules_apple.