基于Telegram二次开发 --- Bazel初探

我们先从 Xcode 来分析，在打包出 ipa 文件时，Xcode 是怎么做的：

手头的材料

代码文件（m/cpp/swift/c/h）、签名、资源文件（xcasset/png/json/html/...）、二进制文件（.a/.framework）

出来的产物

ipa：资源文件、二进制文件

Xcode 就是将手头的材料编译出我们需要的ipa；

进一步拆解 Xcode，会发现编译的过程就是调用 Tool Chains 的过程，Xcode 在编译过程中，调用了组合命令 xcodebuild， Xcode 其实就是一个壳。

将 xcodebuild 进行拆解，我们就可以得到一系列的编译工具，clang/actool/ibtool/... 等等一系列工具，当我们有了这些命令，我们就可以自己对原料进行加工，输出产物；不再依赖于 Xcode 即可进行编译。

---

而 Bazel 正是一个现代化的多语言构建/测试工具，它由 Google 内部 Blaze 的开源，具有正确、快速、可管理、可扩展的特点。

Bazel 的设计原则：

1. 效率：多级 Cache，每一层可以做高效的缓存，本地、远程，来支持增量构建
2. 可扩展性：多种不同的语言可以抽象成一类 Action 进行编译
3. 灵活性：提供内置规则，基于 starlark 的扩展，可以实现各种用户自定义的 rules
4. 正确性：文件缓存是基于文件内容的（而 Xcode 是基于文件时间戳的）
5. 可重复性：有沙盒，不被研发环境影响

Bazel 需要以下支持文件:

- BUILD：描述文件
- WORKSPACE：用于描述项目所需的构建规则

因为是基于 Telegram 二次开发对 Bazel 的探索，所以我们主要研究 - BUILD 描述文件，- WORKSPACE 已经在 Clone 下来的 Telegram-iOS 文件夹目录下配置好了。

---

Bazel Version : 5.1.0

---

一、Objective-C 组件包

先打开 Telegram 的 Xcode 工程目录，我们用 third-party 文件下 ZipArchive 来分析

image.png

ZipArchive 分为三部分

BUILD：描述文件
PublicHeaders：需要向外暴露的头文件
Sources：.h .m .c 等实现文件

其实整个项目都是这样以文件夹为单位，一个个组件包组成的，BUILD 就是来描述这个组件包的构成，依赖项的 Starlark 语法的代码文件。

既然是代码文件，那就有对应 Starlark 语法

objc_library() : 描述 Objective-C 规则的函数，此规则会根据给定的 Objective-C 源文件生成一个静态库。

• name : 组件名称。
• enable_modules : 启用 clang，为 True 时，可支持系统头文件 import，默认为 False 。
• module_name : 模块名称，默认名称是模块路径，所有特殊符号都会被替换成 _ 。
• srcs : 编译源文件；函数 glob() 可以帮助我们匹配满足路径格式的文件。
• hdrs : 需要暴露出来的头文件。
• includes : #include / #import 头文件搜索路径文件夹。
• copts : 需要传递给编译器的额外编译选项：
  -x 编译语言比如 Objective-C
-arch 编译的架构，比如 arm7
-f 以 -f 开头的，代表“旗帜”，定义控制代码生成中使用的接口约定
-W 以 -W 开头的，可以通过这些定制编译警告
-D 以 -D 开头的，指的是预编译宏，通过这些宏可以实现条件编译
-iPhoneSimulator10.1.sdk 编译采用的 iOS SDK 版本
-I 把编译信息写入指定的辅助文件
-F 需要的 Framework
-c 标识符指明需要运行预处理器，语法分析，类型检查，LLVM 生成优化以及汇编代码生成 .o 文件
-o 编译结果
• sdk_frameworks : 需要依赖的 Framework ；为 iOS、tvOS 和 watchOS 平台构建时，始终包含 "UIKit" 和 "Foundation" 。对于 macOS，始终包含 "Foundation" 。
• visibility : 可见性，控制此包是否可以在其他包中使用；
  "//visibility:public" : 授予对所有包的访问权限；
  "//visibility:private" : 不授予任何额外的访问权限；只有在这个包中的可以使用；
  "//xxx/xx:__pkg__" : 授予 //xxx/xx 访问权限，但不授予其子包；
  "//xxx/xx:__subpackages__" : 授予 //xxx/xx 及其所有直接，间接子包的访问权限；

二、swift 组件包

若我们的组件包是 swift 包，我们以 submodules 文件夹下的 AccountContext 举例

image.png

AccountContext 分为两部分

BUILD：描述文件
Sources：.swift 实现文件

因为 swift 跟 Objective-C 相比，是没有 .h 头文件的，所以并不需要向外暴露头文件的 PublicHeaders 文件夹；

我们还注意到 BUILD 文件第一行，跟 Objective-C 下的 BUILD 相比，多了一行

load("@build_bazel_rules_swift//swift:swift.bzl", "swift_library")

此 BUILD 文件第一行的 load 语句表明 swift_library 是一个外部依赖规则，它被定义在 WORKSPACE 中声明的 build_bazel_rules_swift 仓库内部，而 Objective-C 下的 BUILD 里却不需要声明 objc_library 规则，这是因为 objc_library 是 Bazel 内置规则。

swift_library() : 描述 swift 规则的函数，此规则会根据给定的 swift 源文件生成一个静态库。

里面属性跟 objc_library 是一致的，但因为 AccountContext 依赖了自身以外的其他组件包，所以，使用了属性 deps

• deps : 需要依赖的其他组件包，格式由 //submodules/TelegramAudio 相对路径 + :TelegramAudio 组件名 组成。

注意：在这里（swift_library()）编译选项 copts 填写的 -warnings-as-errors（objc_library() 为 -Werror），意思是在这个组件包内将所有警告 warning 当成 error 输出。这在 Telegram-iOS 中，几乎在其 所有非第三方（如 third-party 文件夹下的所有第三方依赖）的自定义组件包 内的 BUILD 文件里都存在，所以在日常开发中，没有 ⚠️ 存在，全都被爆红替代，举个例子，我们定义了一个属性，在这个属性 被使用前，Xcode 会一直出现该属性 未被使用 的报错，这让开发变得更加严谨。

后记

前面说到 Xcode 编译是个壳，其实 Xcode 还做了其他的很多事情的，比如说语法提示/高亮、LLDB 调试工具等等功能；平时开发还是离不开 Xcode。

Telegram 使用 tulsi 工具，将 Bazel 的配置文件，逆向生成 .xcodeproj 工程；

但是这个时候的 .xcodeproj 工程其实已经去掉了 Xcode 的编译功能了；这个时候 Xcode 就是个没有编译功能的壳，但是他还是有上面提到的语法提示/高亮、调试工具等一系列工具集合。

对于 Telegram 二次开发来说，只要了解基础的 BUILD 文件格式即可。

由于 BUILD 文件规则比较多，上面只是基于 Telegram 做简单介绍，详情参考:

Starlark：https://github.com/bazelbuild/starlark
Objective-C Rules：https://docs.bazel.build/versions/main/be/objective-c.html
rule_apple：https://github.com/bazelbuild/rules_apple/tree/master/doc
tulsi：https://tulsi.bazel.build/
Apple 应用和 Bazel：https://bazel.google.cn/docs/bazel-and-apple