Gradle 使用约定优于配置的方法来构建原生项目。如果您来自另一个原生构建系统,这些概念起初可能不太熟悉,但它们旨在简化构建脚本的编写。
我们将在本章详细介绍 Swift 项目,但大多数主题也适用于其他支持的原生语言。
简介
Swift 项目最简单的构建脚本是应用 Swift 应用程序插件或 Swift 库插件,并可选择设置项目版本
plugins {
`swift-application` // or `swift-library`
}
version = "1.2.1"
plugins {
id 'swift-application' // or 'swift-library'
}
version = '1.2.1'
通过应用任一 Swift 插件,您将获得一系列功能
-
compileDebugSwift
和compileReleaseSwift
任务,分别用于编译 src/main/swift 下 Swift 源文件,针对已知的 debug 和 release 构建类型。 -
linkDebug
和linkRelease
任务,用于将编译后的 Swift 对象文件链接成可执行文件(用于应用程序)或共享库(用于具有共享链接的库),针对 debug 和 release 构建类型。 -
createDebug
和createRelease
任务,用于将编译后的 Swift 对象文件组装成静态库(用于具有静态链接的库),针对 debug 和 release 构建类型。
对于任何非平凡的 Swift 项目,您可能需要一些文件依赖项和特定于您的项目的其他配置。
Swift 插件还将上述任务集成到标准的 生命周期任务中。生成开发二进制文件的任务附加到 assemble
。默认情况下,开发二进制文件是 debug 变体。
本章的其余部分解释了在构建库和应用程序时,根据您的需求自定义构建的不同方法。
介绍构建变体
原生项目通常可以生成几种不同的二进制文件,例如 debug 或 release 版本,或者针对特定平台和处理器架构的版本。Gradle 通过维度和变体的概念来管理这一点。
维度只是一个类别,每个类别都与其他类别正交。例如,“构建类型”维度是一个类别,包括 debug 和 release。“架构”维度涵盖处理器架构,如 x86-64 和 x86。
变体是这些维度的值的组合,每个维度恰好包含一个值。您可能有一个“debug x86-64”或“release x86”变体。
Gradle 内置了对多个维度以及每个维度内多个值的支持。您可以在原生插件参考章节中找到它们的列表。
声明您的源文件
Gradle 的 Swift 支持直接使用来自 application 或 library 脚本块的 ConfigurableFileCollection
来配置要编译的源集。
库区分私有(实现细节)和公共(导出给消费者)头文件。
您还可以为每个二进制构建配置源,以用于仅在某些目标机器上编译源的情况。

管理您的依赖
绝大多数项目都依赖于其他项目,因此管理项目的依赖关系是构建任何项目的重要组成部分。依赖管理是一个很大的主题,因此我们在这里仅关注 Swift 项目的基础知识。如果您想深入了解细节,请查看依赖管理入门。
Gradle 提供支持,从 Gradle [1]发布的 Maven 仓库消费预构建的二进制文件。
我们将介绍如何在多构建项目中添加项目之间的依赖关系。
为您的 Swift 项目指定依赖关系需要两个信息
-
依赖的识别信息(项目路径、Maven GAV)
-
它的用途,例如编译、链接、运行时或以上所有。
此信息在 Swift application
或 library
脚本块的 dependencies {}
块中指定。例如,要告诉 Gradle 您的项目需要库 common
来编译和链接您的生产代码,您可以使用以下片段
application {
dependencies {
implementation(project(":common"))
}
}
application {
dependencies {
implementation project(':common')
}
}
Gradle 对这三个元素的术语如下
-
配置(例如:
implementation
)- 依赖项的命名集合,为了特定目标(例如编译或链接模块)而分组在一起 -
项目引用(例如:
project(':common')
)- 由指定路径引用的项目
您可以在此处找到更全面的依赖管理术语词汇表。
就配置而言,主要的关注点是
-
implementation
- 用于编译、链接和运行时 -
swiftCompileVariant
- 用于编译您的生产代码但不需要成为链接或运行时过程一部分的依赖项 -
nativeLinkVariant
- 用于链接您的代码但不需要成为编译或运行时过程一部分的依赖项 -
nativeRuntimeVariant
- 用于运行您的组件但不需要成为编译或链接过程一部分的依赖项
您可以在原生插件参考章节中了解更多关于这些以及它们之间关系的信息。
请注意,Swift Library 插件创建了一个额外的配置 — api
— 用于编译和链接模块以及任何依赖于它的模块所需的依赖项。
我们在这里只触及了表面,因此我们建议您在熟悉使用 Gradle 构建 Swift 项目的基础知识后,阅读专门的依赖管理章节。
一些常见的需要进一步阅读的场景包括
-
定义自定义的 Maven 兼容 仓库
-
声明兄弟项目作为依赖项
-
通过复合构建(比发布到和消费来自Maven Local更好的替代方案)测试您对第三方依赖项的修复
您将发现 Gradle 具有用于处理依赖项的丰富 API — 需要时间才能掌握,但在常见场景中易于使用。
编译和链接您的代码
如果您遵循约定,编译您的代码可能非常容易
-
将您的源代码放在 src/main/swift 目录下
-
在
implementation
配置中声明您的编译依赖项(请参阅上一节) -
运行
assemble
任务
我们建议您尽可能遵循这些约定,但这不是强制性的。
正如您接下来将看到的,有几个自定义选项。
所有 SwiftCompile 任务都是增量且可缓存的。 |
支持的工具链
Gradle 支持 macOS 和 Linux 的官方 Swift 工具链。当您构建原生二进制文件时,Gradle 将尝试在您的机器上找到可以构建该二进制文件的工具链。Gradle 选择可以为目标操作系统、架构和 Swift 语言支持构建的第一个工具链。
对于 Linux 用户,Gradle 将使用系统 PATH 发现工具链。 |
自定义文件和目录位置
假设您正在迁移一个遵循 Swift Package Manager 布局的库项目(例如,生产代码的 Sources/ModuleName_
目录)。传统的目录结构将不起作用,因此您需要告诉 Gradle 在哪里找到源文件。您可以通过 application
或 library
脚本块来完成。
每个组件脚本块以及每个二进制文件都定义了其源代码所在的位置。您可以使用以下语法覆盖约定值
extensions.configure<SwiftLibrary> {
source.from(file("Sources/Common"))
}
library {
source.from file('src')
}
现在 Gradle 将仅在 Sources/Common 中直接搜索源。
更改编译器和链接器选项
大多数编译器和链接器选项都可以通过相应的任务访问,例如 compileVariantSwift
、linkVariant
和 createVariant
。这些任务的类型分别为 SwiftCompile、LinkSharedLibrary 和 CreateStaticLibrary。阅读任务参考以获取最新和全面的选项列表。
例如,如果您想更改编译器为所有变体生成的警告级别,可以使用此配置
tasks.withType(SwiftCompile::class.java).configureEach {
// Define a preprocessor macro for every binary
macros.add("NDEBUG")
// Define a compiler options
compilerArgs.add("-O")
}
tasks.withType(SwiftCompile).configureEach {
// Define a preprocessor macro for every binary
macros.add("NDEBUG")
// Define a compiler options
compilerArgs.add '-O'
}
也可以通过 application
或 library
脚本块上的 BinaryCollection
找到特定变体的实例
application {
binaries.configureEach(SwiftStaticLibrary::class.java) {
// Define a preprocessor macro for every binary
compileTask.get().macros.add("NDEBUG")
// Define a compiler options
compileTask.get().compilerArgs.add("-O")
}
}
application {
binaries.configureEach(SwiftStaticLibrary) {
// Define a preprocessor macro for every binary
compileTask.get().macros.add("NDEBUG")
// Define a compiler options
compileTask.get().compilerArgs.add '-O'
}
}
选择目标机器
默认情况下,Gradle 将尝试为主机操作系统和架构创建一个 Swift 二进制变体。可以通过在 application
或 library
脚本块上指定 TargetMachine
集合来覆盖此设置
application {
targetMachines = listOf(machines.linux.x86_64, machines.macOS.x86_64)
}
application {
targetMachines = [
machines.linux.x86_64,
machines.macOS.x86_64
]
}
打包和发布
在原生世界中,您如何打包和可能发布您的 Swift 项目差异很大。Gradle 带有默认设置,但可以毫无问题地实现自定义打包。
-
可执行文件直接发布到 Maven 仓库。
-
共享库和静态库文件以及公共头文件的 zip 文件直接发布到 Maven 仓库。
-
对于应用程序,Gradle 还支持在已知位置安装和运行可执行文件及其所有共享库依赖项。
清理构建
Swift Application 和 Library 插件通过使用 base plugin 向您的项目添加一个 clean
任务。此任务只是删除 layout.buildDirectory
目录中的所有内容,因此这就是为什么您应该始终将构建生成的文件放在那里。该任务是 Delete 的实例,您可以通过设置其 dir
属性来更改它删除的目录。
构建 Swift 库
库项目的独特之处在于它们被其他 Swift 项目使用(或“消费”)。这意味着与二进制文件和头文件一起发布的依赖元数据(以 Gradle 模块元数据的形式)至关重要。特别是,您的库的消费者应该能够区分两种不同类型的依赖项:仅编译您的库所需的依赖项和编译消费者也需要的依赖项。
Gradle 通过 Swift Library 插件管理这种区别,该插件除了本章前面介绍的 implementation 配置外,还引入了 api 配置。如果来自依赖项的类型作为静态库的未解析符号或在公共头文件中出现,则该依赖项通过您库的公共 API 公开,因此应添加到 api 配置中。否则,该依赖项是内部实现细节,应添加到 implementation 中。
如果您不确定 API 和 implementation 依赖项之间的区别,Swift Library 插件章节有详细的解释。此外,您可以在相应的示例中看到构建 Swift 库的基本实际示例。
构建 Swift 应用程序
有关更多详细信息,请参阅 Swift Application 插件 章节,但以下是您获得内容的快速摘要
-
install
创建一个目录,其中包含运行它所需的一切 -
用于启动应用程序的 Shell 和 Windows Batch 脚本
您可以在相应的示例中看到构建 Swift 应用程序的基本示例。