Add *_sdk_minimum_os attributes to xcode_version and XcodeProperties

[brentleyjones]

This allows rules to determine the minimum supported OS versions for a given Xcode version. One such use case is emulating Swift Package Manager’s SupportedPlatform spec.

This is a backwards compatible change. xcode_version accepts not setting these attributes, and will pass on None to the XcodeProperties constructor. The XcodeProperties constructor accepts not setting these attributes as well, defaulting to None. The XcodeProperties constructor converts None to be equal to default_*_sdk_version. And since when default_*_sdk_version is None a “reasonable default” is chosen, these new attributes will always have a value.

In the future we may want to use these values in xcode_config to set a better default *_minimum_os. That would be a breaking change though.

[brentleyjones]

@susinmotion This was the change we talked about. I would like to get this in now, rather than wait for the rules to be fully migrated to Starlark and moved over to apple_support, because I would like to cherry-pick a version of this into Bazel 7.2.0.

Here is an example of how we will use these values in rules_swift and rules_swift_package_manager: cgrindel/rules_swift_package_manager#892 (comment)

[allevato]

Hi Brentley! We've discussed this a bit internally and we'd like to hold off on changes to these rules while they're in flux; i.e., moving out of Bazel core. A couple reasons:

First, since we don't have an immediate use for this internally, it would become immediate tech debt that we'd be removing once we moved the initial versions of the rules into the apple_support repository and pushed them out to GitHub.

A more compelling reason, from a design-oriented point of view, is that I don't think that simply adding a new version number attribute to the existing xcode_version rule is the right solution here. I 100% agree that the SDKSettings.json files contain information that could be useful to other rules. In addition to the minimum supported OS version, it contains information like the OS versions where the Swift runtime was first distributed in the OS or where Swift concurrency was first in the OS; this information is currently duplicated in rules_apple in the form of hard-coded maps, and there's an opportunity to look at these cases more holistically. Just adding new batches of attributes per platform doesn't scale.

Thinking about it in this way, I can imagine rethinking the rules to look something like this:

xcode_version(
  name = "xcode_15_3",
  iphoneos_sdk = ":iphoneos_sdk_17_4",
  iphonesimulator_sdk = ":iphonesimulator_sdk_17_4",
  # Other SDKs...
)

xcode_sdk(
  name = "iphoneos_sdk_17_4",
  minimum_os_version = "12.0",
  sdk_version = "17.4",
  swift_concurrency_in_os_version = "15.0",
  swift_runtime_in_os_version = "12.2",
  # Other values from SDKSettings.json...
)

By introducing a new rule to represent SDKs and maintaining the relationship between the Xcode version and its SDKs as part of the build graph, it leaves a lot more room for extensibility and future modification than a new bespoke attribute for this one SPM use case, and clients who depend on the Xcode config can easily get any information they need through the providers that those rules would define.

[brentleyjones]

Thanks for your feedback @allevato. I'll both wait for the rules to be in apple_support, and take your different design into account.