# 构建 libwebrtc · depot_tools、GN 与 Ninja

> 把 libwebrtc 这个庞然大物编译出来本身就是一门学问——它用 Chromium 的构建体系：depot_tools 拉代码、GN 生成构建、Ninja 编译。这一章讲清这套工具链、为什么构建这么重（自带整套依赖与工具链的 hermetic 设计），以及实际的构建步骤。

- 作者：David（道雾轩）
- 专栏：音视频与 WebRTC 详解（https://daiw.org/manual/webrtc.md）
- 最后更新：2026-07-15
- 原文：https://daiw.org/manual/webrtc/building-webrtc
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# 构建 libwebrtc · depot_tools、GN 与 Ninja

读了这么多源码，一个很实际的问题：**怎么把 libwebrtc 真正编译出来**？这不是 `./configure && make` 那么简单——WebRTC 用的是 **Chromium 的整套构建体系**，自成一个世界。这一章讲清它，让你从“读源码”走到“能构建”。

## 三件套：depot_tools、GN、Ninja

WebRTC 不用 CMake、不用 Make，而是（[根目录的 `.gn`、遍地的 `BUILD.gn` 就是证据](https://daiw.org/manual/webrtc/reading-the-source)）：

<Callout type="info">
  **WebRTC 的构建靠 Chromium 三件套：**

  - **depot_tools** —— Google 的工具集合，含 `fetch`、`gclient`（拉代码 + 依赖）、`gn`、`ninja`。第一步是把它加进 `PATH`。
  - **GN**(Generate Ninja) —— **元构建系统**：读 `BUILD.gn`（[根 `BUILD.gn` 就有 2000 多行](https://daiw.org/manual/webrtc/reading-the-source)）里声明的目标和依赖，**生成** Ninja 构建文件。`gn gen out/Default` 干这事。
  - **Ninja** —— 真正执行编译的构建器，追求**极致的增量构建速度**（Chromium 那种体量，编译速度是刚需）。`ninja -C out/Default` 开编。

  为什么是“[GN 生成 Ninja、而非直接写 Ninja](https://daiw.org/manual/webrtc/reading-the-source)”？因为 WebRTC 要[跨这么多平台 / 架构](https://daiw.org/manual/webrtc/platform-overview)（[Win/mac/Linux/Android/iOS × x86/arm](https://daiw.org/manual/webrtc/what-is-webrtc)），配置组合爆炸。GN 用[声明式的 `BUILD.gn` + 参数](https://daiw.org/manual/webrtc/building-webrtc)描述“要构建什么”，再据目标平台生成对应的 Ninja 文件——**一套构建描述、生成各平台的实际构建**，和[一套 C++ 核心服务各平台](https://daiw.org/manual/webrtc/platform-overview)是同构的思路。
</Callout>

## 典型构建流程

一次从零构建大致是这几步：

```bash
# 1. 装 depot_tools 并加入 PATH
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
export PATH="$PWD/depot_tools:$PATH"

# 2. 拉源码 + 全部依赖(gclient 按 DEPS 文件拉)
mkdir webrtc && cd webrtc
fetch --nohooks webrtc
gclient sync                    # 拉下 third_party 里的一切

# 3. GN 生成构建配置
gn gen out/Default              # 可加 --args='target_os="android"' 等

# 4. Ninja 编译
ninja -C out/Default
```

关键是第 2 步的 `gclient sync`：它读 **`DEPS`** 文件，把 WebRTC 依赖的[一切第三方库](https://daiw.org/manual/webrtc/building-webrtc)拉进 `third_party/`——而这个“一切”大得惊人。

## 为什么构建这么重：hermetic 单体

<Callout type="info">
  **libwebrtc 构建“重”是出了名的——拉下来几个 GB、首次编译动辄几十分钟。根源是它**hermetic（自足）**：不依赖你系统里装了什么，而是**自带整套依赖和工具链**。** `third_party/` 里 vendored（内置）了它需要的所有东西：

  - **底层库** —— [BoringSSL](https://daiw.org/manual/webrtc/boringssl-integration)（[加密](https://daiw.org/manual/webrtc/srtp-encryption)）、[libvpx/libaom](https://daiw.org/manual/webrtc/video-encoder-abstraction)（[VP8/VP9/AV1 编解码](https://daiw.org/manual/webrtc/simulcast-svc)）、[Opus](https://daiw.org/manual/webrtc/audio-codecs)（[音频编解码](https://daiw.org/manual/webrtc/audio-codecs)）、[abseil-cpp](https://daiw.org/manual/webrtc/units)（基础库）……全在里面。
  - **构建工具链** —— 连编译器（特定版本的 Clang）、sysroot 都自带，不用你系统的。

  好处是**构建结果高度可复现**：任何人、任何机器，拉同一个版本编出的二进制一致，不受“你本地装了什么版本的 OpenSSL”干扰——这对[一个要在无数环境一致运行的库](https://daiw.org/manual/webrtc/what-is-webrtc)至关重要。代价就是**重**：你下载的不只是 WebRTC 代码，而是[整个自足的构建宇宙](https://daiw.org/manual/webrtc/building-webrtc)。这也解释了[本教程用的源码](https://daiw.org/manual/webrtc/reading-the-source)为何常按“[扁平化的单一源码树](https://daiw.org/manual/webrtc/source-map)”分发——完整 checkout 太庞大。
</Callout>

## 对读者的实际意义

多数人**不需要**从头构建 libwebrtc——用[预编译库](https://daiw.org/manual/webrtc/platform-overview)、或直接用浏览器内建的 WebRTC 就够。你需要自己构建，通常是为了：**改核心源码做定制**（如加个 [field trial](https://daiw.org/manual/webrtc/observability-recap)、改[拥塞控制参数](https://daiw.org/manual/webrtc/rate-control)）、**调试深层问题**（[带符号的本地构建](https://daiw.org/manual/webrtc/observability-overview)配合[event log](https://daiw.org/manual/webrtc/rtc-event-log)）、或**移植到特殊平台**。真到那一步，记住：构建体系是 [Chromium 的 GN/Ninja](https://daiw.org/manual/webrtc/building-webrtc)，文档看官方 `webrtc.googlesource.com` 的构建指南，别指望用通用 C++ 构建习惯套。

## 小结与下一章

libwebrtc 用 **Chromium 构建体系**：**depot_tools**（`fetch`/`gclient`）拉代码与依赖、**GN**（[读 `BUILD.gn` 生成 Ninja](https://daiw.org/manual/webrtc/reading-the-source)，应对[跨平台配置爆炸](https://daiw.org/manual/webrtc/platform-overview)）、**Ninja**（极速编译）。流程是 `fetch webrtc` → `gclient sync`（按 [`DEPS`](https://daiw.org/manual/webrtc/building-webrtc) 拉 `third_party`）→ `gn gen` → `ninja`。构建“重”因它 **hermetic 自足**：[vendored 了 BoringSSL/libvpx/Opus/abseil](https://daiw.org/manual/webrtc/boringssl-integration) 和整套工具链，换来[高度可复现](https://daiw.org/manual/webrtc/what-is-webrtc)、代价是庞大。多数人用[预编译库即可](https://daiw.org/manual/webrtc/platform-overview)，要自己构建多为[定制核心 / 深度调试](https://daiw.org/manual/webrtc/observability-overview)。

平台集成的全部拼图到齐了。最后一章，为整个专栏画上句号。👉 [全专栏回顾与结语](https://daiw.org/manual/webrtc/webrtc-recap)。

## 参考资料

- [1] libwebrtc 源码.`.gn`、`BUILD.gn`、`DEPS`（GN/gclient 配置）。
- [2] WebRTC 官方构建文档（`webrtc.googlesource.com/src/+/main/docs/native-code/`）、Chromium depot_tools。
- [3] 关联[第三方集成 BoringSSL](https://daiw.org/manual/webrtc/boringssl-integration)、[编解码器](https://daiw.org/manual/webrtc/video-encoder-abstraction)、[平台策略](https://daiw.org/manual/webrtc/platform-overview)。