开发工具构建工具【免费下载链接】swift-package-managerThe Package Manager for the Swift Programming Language项目地址https://gitcode.com/gh_mirrors/sw/swift-package-manager点击查看免费下载在 Swift Package Manager 中PackageDescription框架的Platform类型是编写Package.swift清单时的基石它用于声明包所支持的平台、为构建设置如cSettings、swiftSettings、linkerSettings与目标依赖添加按平台过滤的条件以及声明各平台的最低部署版本。本文以仓库中的 Platform 文档 为主线结合 SupportedPlatforms.swift 与 Platform.swift 等源码实现系统讲解Platform的每一个预定义成员、custom(_:)自定义扩展方法、版本约束校验规则以及它在清单中的真实应用场景。读完本文你将能够准确地在Package.swift中声明平台、写出正确的平台条件表达式并理解Platform在包加载与构建决策中的底层机制。Platform是什么清单 API 与内部模型的双重视角Platform在 SwiftPM 中存在两个不同层级的定义理解它们的区别有助于避免混淆。清单侧PackageDescription 运行时在 SupportedPlatforms.swift 中Platform被定义为/// A platform supported by Swift Package Manager. public struct Platform: Equatable, Sendable { /// The name of the platform. let name: String private init(name: String) { self.name name } }它本质上是平台名字符串如macos、ios的轻量封装只暴露name一个内部存储属性并通过一组public static let常量向外提供预定义平台。该结构体同时声明了Equatable与Sendable协议遵循因此它可以安全地跨并发域传递也可以直接用/!比较。模型侧核心库内部在 Platform.swift 中核心库的PackageModel.Platform是更丰富的模型额外携带oldestSupportedVersion该平台最旧的受支持部署版本public struct Platform: Equatable, Hashable, Codable, Sendable { public let name: String public let oldestSupportedVersion: PlatformVersion ... }两个Platform通过清单序列化层衔接清单中的平台名会被写进 PackageDescriptionSerialization.swift 的Serialization.Platform仅含name: String并在包加载阶段PackageBuilder.swift由PlatformRegistry解析成完整的内部模型若名字不在注册表中则回退为PackageModel.Platform.custom(name:oldestSupportedVersion:)版本为.unknown。这正是Platform.custom自定义平台能够贯穿清单声明 → 序列化 → 内部模型全链路的原因。预定义平台常量13 个内置平台与它们的引入时机Platform通过static let提供 13 个预定义平台常量全部定义在 SupportedPlatforms.swift平台常量内部 name 值PackageDescription 引入版本说明Platform.macOSmacos5.0基础 APImacOS 桌面平台Platform.macCatalystmaccatalyst5.5Mac CatalystiPad 应用运行于 MacPlatform.iOSios5.0基础 APIiPhone / iPad 平台Platform.tvOStvos5.0基础 APIApple TV 平台Platform.watchOSwatchos5.0基础 APIApple Watch 平台Platform.visionOSvisionos5.9Apple Vision Pro 平台Platform.driverKitdriverkit5.5DriverKit 驱动开发平台Platform.linuxlinux5.0基础 APILinux 发行版Platform.androidandroid5.2AndroidPlatform.windowswindows5.2WindowsPlatform.wasiwasi5.3WebAssembly System InterfacePlatform.openbsdopenbsd5.8OpenBSDPlatform.freebsdfreebsd当前工具链源码标记为999.0占位FreeBSD对应源码节选/// The macOS platform. public static let macOS: Platform Platform(name: macos) /// The Mac Catalyst platform. public static let macCatalyst: Platform Platform(name: maccatalyst) /// The visionOS platform. public static let visionOS: Platform Platform(name: visionos) /// The Linux platform. public static let linux: Platform Platform(name: linux) ... /// The FreeBSD platform. available(_PackageDescription, introduced: 999.0) public static let freebsd: Platform Platform(name: freebsd)注意两个细节带available标注的常量是受清单工具版本约束的windows、android要求清单工具版本 ≥ 5.2wasi≥ 5.3openbsd≥ 5.8freebsd源码中使用999.0占位表示随当前工具链引入。如果Package.swift声明的工具版本// swift-tools-version:过低使用这些常量会直接触发编译错误——这是 SwiftPM 保证旧工具链清单可移植性的手段。这些常量与SupportedPlatform的静态方法同名但用途不同Platform.iOS是平台标识而SupportedPlatform.iOS(_:)是平台 最低版本的组合。前者用于PlatformCondition条件表达式后者用于platforms:声明。自定义平台custom(_:)类型方法当内置的 13 个平台无法覆盖目标平台时Platform.custom(_:)提供了逃生通道。其定义位于 SupportedPlatforms.swift/// Creates a custom platform. /// /// Use this function if none of the predefined platform names match the platform you are targeting. /// - Parameter platformName: The name of the platform. /// - Returns: A Platform instance. available(_PackageDescription, introduced: 5.6) public static func custom(_ platformName: String) - Platform { return Platform(name: platformName) }引入版本custom(_:)自 PackageDescription 5.6 起可用因此Package.swift需声明// swift-tools-version:5.6或更高。参数platformName是平台的字符串名可以是任意值——例如一个尚未被 SwiftPM 收录的新操作系统名。实现它只是把传入的字符串包进Platform(name: platformName)与预定义常量走完全相同的构造路径。一个典型的应用场景是配合SupportedPlatform.custom(_:versionString:)同样 5.6 引入在platforms:中声明自定义平台的最低部署版本// swift-tools-version:5.6 import PackageDescription let package Package( name: MyLibrary, platforms: [ .custom(myos, versionString: 1.0) ], ... )在源码中SupportedPlatform.custom(_:versionString:)还会先调用CustomPlatformVersion.validateVersion(versionString)校验版本格式失败时把错误追加进全局errors数组SupportedPlatforms.swift而CustomPlatformVersion的minimumMajorVersion为 0意味着自定义平台可以声明0.x这样的小版本号。内部模型侧包加载器通过 PackageBuilder.swift 的PackageModel.Platform.custom(name:oldestSupportedVersion: .unknown)承接未知平台名形成完整的闭环。平台条件表达式Platform在清单中的主要用途除了在platforms:中声明部署版本Platform最常见的用法是作为条件过滤的输入。SwiftPM 的清单 API 提供了三类以平台为条件的表达式1. 构建设置条件BuildSettingCondition在 BuildSettings.swift 中BuildSettingCondition.when(platforms:)允许为 C、C、Swift 与链接器设置按平台定向swiftSettings: [ .define(DISABLE_SOMETHING, .when(platforms: [.iOS], configuration: .release)), ], linkerSettings: [ .linkedLibrary(openssl, .when(platforms: [.linux])), ]上述BuildSettingCondition的platforms属性类型正是[Platform]?因此你可以传入任意预定义平台或Platform.custom(...)的混合数组。2. 目标依赖条件TargetDependencyCondition在 Target.swift 中TargetDependencyCondition.when(platforms:)用于按平台限定依赖是否生效。注意 5.7 起该 API 的两个变体available(_PackageDescription, obsoleted: 5.7)的旧版本接受可空platforms: [Platform]?已被标记废弃5.7 引入的新版本接受非空platforms: [Platform]并在传入空数组时返回nil即不产生条件6.1 起还可以同时传入traits: SetString让依赖条件同时受平台与 trait 约束。dependencies: [ .target(name: Helper, condition: .when(platforms: [.macOS, .linux])) ]3. 平台条件PlatformCondition清单中的平台条件会在包加载阶段被 PackageBuilder.swift 的buildConditions(from:)解析条件中出现的每个平台名先到PlatformRegistry.default.platformByName查找命中则使用内置平台的oldestSupportedVersion未命中则回退为.custom(name: .unknown)。预定义平台名单定义在 PlatformRegistry.swift 的_knownPlatforms数组中包含 android、driverKit、iOS、linux、macOS、macCatalyst、openbsd、freebsd、tvOS、visionOS、wasi、watchOS、windows 共 13 项——与清单侧预定义常量一一对应。!操作符基于Equatable的默认实现Platform声明遵循Equatable因此自动获得!操作符。文档 Platform-notEqual.md 明确说明对于任意值 a 和 ba ! b蕴含a b为 false。这是任何遵循Equatable的类型的 not-equal-to!操作符的默认实现。在实践中比较两个平台等价于比较它们的name字符串let p Platform.custom(myos) p ! .macOS // truemyos ! macos Platform.iOS .iOS // true因为Platform是结构体且仅含name一个存储属性Swift 合成的Equatable实现会逐字段比较行为确定且可预期。平台校验规则无效声明的错误处理SupportedPlatform的文档见 SupportedPlatforms.swift 中SupportedPlatform的注释总结了 SwiftPM 对平台声明的校验纪律默认部署版本若不显式配置platforms:SwiftPM 会为每个受支持平台分配一个预定义的最低部署版本——即已安装 SDK 对某平台支持的最旧部署目标macOS 特例从 10.10 起步。这一点在内部模型中体现为Platform.oldestSupportedVersion如当前源码中 macOS 为12.0、iOS 为15.0、watchOS 为9.0、driverKit 为21.0见 Platform.swift。无效输入会报错包括空数组、对同一平台的重复声明、以及非法的版本规格。依赖部署版本约束若某个依赖的最低部署版本高于顶层包的部署版本SwiftPM 会报错——依赖的部署目标必须小于或等于顶层包对应平台的部署目标。版本字符串的格式校验实现在 SupportedPlatforms.swift 的validateVersion(_:)版本必须是点分十进制整数序列如10.10、10.10.1前两个组件必须是正整数且主版本号不得低于该平台定义的minimumMajorVersion如 macOS 为 10、iOS 为 2、tvOS 为 9、watchOS 为 2、visionOS 为 1、DriverKit 为 19、Mac Catalyst 为 13。违规时错误会以invalid 平台名 version 值; ...的格式进入诊断输出。版本演进各平台版本常量与弃用轨迹SupportedPlatform为每个 Apple 平台维护一套vX_Y风格的版本常量如SupportedPlatform.MacOSVersion.v12并随 PackageDescription 版本逐步增补、弃用。以 macOS 为例SupportedPlatforms.swift5.0 引入v10_10v10_145.1v10_155.3v11同时v10_16被标记unavailable并重命名为v115.5v125.7v13并将v10_10v10_12标记为废弃提示macOS 12.0 是最旧受支持版本5.9v146.0v156.2v26v16被标记unavailable并重命名6.4v27。同样地iOS 平台自 5.5 起以v15为分界v8v14逐步废弃watchOS 以v9为分界tvOS 以v15为分界visionOS 从 5.9 的v1演进到 6.4 的v27DriverKit 从 5.5 的v19演进到 6.4 的v27。这些常量在清单中可以直接作为强类型版本使用// swift-tools-version:6.0 platforms: [ .macOS(.v15), .iOS(.v18), .watchOS(.v11), .tvOS(.v18), .visionOS(.v2) ]也可以传入格式合法的字符串如.iOS(15.0)两种重载在 SupportedPlatforms.swift 中一一对应字符串版本同样经过validateVersion校验。与SupportedPlatform的分工何时用哪个最后梳理一下最容易混淆的一对类型Platform平台标识name用于条件表达式BuildSettingCondition、TargetDependencyCondition、以及作为SupportedPlatform的内部组成部分支持custom(_:)扩展。SupportedPlatform平台 最低部署版本的组合仅用于Package(platforms:)声明它提供的iOS(_:)、macOS(_:)等静态方法返回的是SupportedPlatform不是Platform。判断方法很简单凡是要写最低部署版本的地方用SupportedPlatform凡是要写哪些平台的地方用Platform。两个类型都声明了EquatablePlatform的!见 Platform-notEqual.mdSupportedPlatform的对应文档见 SupportedPlatforms.md且都在 PackageDescription.docc 的 DocC 文档体系中有完整条目可供查阅。通过以上剖析可以看到Platform虽然表面上只是 13 个常量加一个custom(_:)但它串联起了清单声明platforms:、条件过滤.when(platforms:)、序列化Serialization.Platform与包加载PlatformRegistryPackageBuilder的完整链路。掌握它的用法是编写跨平台、多条件 Swift 包的基础功。赞分享开发工具构建工具【免费下载链接】swift-package-managerThe Package Manager for the Swift Programming Language项目地址https://gitcode.com/gh_mirrors/sw/swift-package-manager点击查看免费下载相关推荐Flet geolocator 扩展 GeolocatorPositionAccuracy 定位精度枚举详解从枚举值到平台底层实现Flet geolocator 扩展 GeolocatorPositionAccuracy 定位精度枚举详解从枚举值到平台底层实现 GeolocatorPos前端跨平台桌面应用移动开发终极指南如何通过Knative Serving自定义资源定义扩展Kubernetes无服务平台功能终极指南如何通过Knative Serving自定义资源定义扩展Kubernetes无服务平台功能 Knative Serving是一个基于Kubernete云原生后端微服务Forensia红队后渗透阶段的终极反取证工具15足迹清除功能全解析 Forensia红队后渗透阶段的终极反取证工具15足迹清除功能全解析 在红队评估和渗透测试的后渗透阶段清除操作足迹是确保隐蔽性和延长驻留时间的关键上一篇XiaoMusic技术方案基于FastAPI的智能音箱音乐播放系统架构解析下一篇Alexandria多列布局与排版设置专业级阅读体验配置指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
