我们先从 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 的设计原则：
- 效率：多级 Cache，每一层可以做高效的缓存，本地、远程，来支持增量构建
- 可扩展性：多种不同的语言可以抽象成一类 Action 进行编译
- 灵活性：提供内置规则，基于 starlark 的扩展，可以实现各种用户自定义的 rules
- 正确性：文件缓存是基于文件内容的（而 Xcode 是基于文件时间戳的）
- 可重复性：有沙盒，不被研发环境影响
Bazel 需要以下支持文件:
- BUILD：描述文件
- WORKSPACE：用于描述项目所需的构建规则
因为是基于 Telegram 二次开发对 Bazel 的探索，所以我们主要研究 - BUILD 描述文件，- WORKSPACE 已经在 Clone 下来的 Telegram-iOS 文件夹目录下配置好了。
Bazel Version : 5.1.0
一、Objective-C 组件包
先打开 Telegram 的 Xcode 工程目录，我们用 third-party 文件下 ZipArchive 来分析
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 举例
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
