关于 WebRTC 的源码下载和 Demo 的编译运行,WebRTC 的官方文档已经有非常详细的说明。以 Linux 为例,过程大概是这样的:
- 下载并安装 depot_tools。这是 WebRTC 的代码下载及编译工具集,下载即是把源码 clone 下来,所谓安装只是把 depot_tools 的目录路径放进系统的环境变量 PATH 中即可。
准备目录
12$ mkdir webrtc$ cd webrtc下载代码
12$ fetch --nohooks webrtc$ gclient sync安装依赖。
编译运行。
安装依赖和编译运行具体可以参考 WebRTC 的官方文档。
在国内,由于大家都懂的原因,通过 WebRTC 的官方流程下载源码比较困难。笔者过去一直期待有人能够建立一套在国内可以访问的 WebRTC 代码的 mirror 仓库,只是可惜一直未能见到这样的东西。于是笔者就花了点时间看了下,将 WebRTC 的源码及其依赖的一些模块,在 GitHub 和 Bitbucket 上做了一份 fork,做了一点小改动,使得同仁基本可以按照 WebRTC 的官方流程下载编译 WebRTC 的源码。
( WebRTC 及其依赖的大部分模块源码 fork 在 GitHub 上,但由于对 repo 中文件的最大大小有限制,导致无法把 tools
的源码推到 GitHub 上,而 Bitbucket 从开源项目 import 创建 repo 非常方便,因而 tools
的源码就被放在了 Bitbucket 上。另外一个模块 third_party
,它的源码比较多,因而推到 GitHub 上也比较困难,所以也通过 import 创建 repo 在 Bitbucket 上建立 mirror。)
WebRTC 源码下载过程浅析
在上面 WebRTC 源码的官方下载流程中,首先需要执行 fetch --nohooks webrtc
命令。这个命令做的最主要的事情是,下载名为 .gclient
的源码下载配置文件:
这个文件的内容如下:
执行 fetch
之后,通过 gclient sync
下载完整的源码库。gclient
做的事情主要是两件:
克隆
.gclient
文件中url
字段指向的 repo,repo 的放置位置则由.gclient
文件中name
字段描述。如上面的.gclient
文件,gclient
工具将会克隆https://webrtc.googlesource.com/src.git
,并把repo 放在src
出。根据第一步中下载的 repo 中依赖文件的内容,下载所有的依赖,依赖文件的路径由
.gclient
文件中deps_file
字段描述,如上面的DEPS
。
WebRTC 源码库根目录下的 DEPS
文件描述了它依赖的所有东西,包括源码形式的模块,也包含二进制形式的模块,这个文件的内容如下面这样:
DEPS
文件的内容主要分为如下几个部分:
变量定义
vars
:这个部分定义了将会在后面被引用到的一些变量,如 Git 仓库的根地址,依赖的一些模块的 commit 等。依赖描述
deps
:这个部分描述了 WebRTC 依赖的所有模块,既包括 Git repo 形式的依赖,也包括 cipd 模块形式的依赖,既包括无条件的依赖,即适用于所有编译环境平台和目标平台的依赖,也包括有条件的依赖,即仅适用与一定条件的依赖。
无条件的 Git repo 形式依赖如:1234'src/base':Var('chromium_git') + '/chromium/src/base' + '@' + 'b8d7dd92d6132c1d168f75130ffeb79fbf94ac11','src/build':Var('chromium_git') + '/chromium/src/build' + '@' + 'fe39ce9fd1fd675cc28172aa15f919101deb475a',
有条件的 Git repo 依赖,如仅在为 iOS 编译时才需要的模块:
Git repo 主要用于存放源码,但也可以用于存放二进制文件,如 yasm 的二进制文件:
cipd 模块形式的无条件依赖如:
cipd 模块形式的有条件依赖,如仅适用于 Linux 的 gn 依赖的描述:
由于 cipd 主要是一套维护二进制文件的系统,因而 cipd 模块形式的依赖都是二进制文件。
每个依赖项的描述主要包含三个字段,packages
描述依赖项的详细路径和版本,dep_type
描述依赖项的类型,condition
描述依赖项启用的条件。
hooks
:由于在某些时间点执行的命令或工具。hook 项的描述主要包含四个字段,name
为名称,pattern
为模式,condition
为应用的条件,action
为具体执行的命令工具及其运行参数。如:12345678{'name': 'sysroot_x64','pattern': '.','condition': 'checkout_linux and checkout_x64',# TODO(mbonadei): change to --arch=x64.'action': ['python', 'src/build/linux/sysroot_scripts/install-sysroot.py','--arch=amd64'],},recursedeps
:循环依赖。include_rules
:定义源码中允许的 include 路径的规则。
不难想到,只要我们可以重新定义 .gclient
文件和 DEPS
文件的内容,就可以把 WebRTC 的依赖都指向我们在 GitHub 和 Bitbucket 的 Mirror。
WebRTC 源码下载
克隆 WebRTC 壳工程:
12$ clone https://github.com/asdfghjjklllllaaa/webrtc.git$ cd webrtc同步代码
1$ gclient sync
代码量比较大,同步代码比较简单,可能需要多次重试。
下载 cipd 依赖时需要访问主机 chrome-infra-packages.appspot.com
,这个主机经常无法访问。可以先通过 http://site.ip138.com/chrome-infra-packages.appspot.com/
查询这个主机的 IP 地址,然后找一个可以访问的 IP,并把域名/IP信息写入 hosts 来解决。
WebRTC 源码的编译,和 Demo 的运行,可以参考网上的其它文档,如 webrtc所有平台下载编译步骤详细说明 和 Windows下 WebRTC Demo运行: PeerConnection
gclient 同步代码结束后,会生成一个名为 .gclient_entries
的文件,描述实际同步的模块及其版本号,如:
笔者基于 .gclient_entries
文件的内容,写了一个简单的脚本,下载并迁移 WebRTC 依赖的这些 Git repo,脚本文件的如下:
这个脚本能工作的基础是,在 GitHub 上已经为它们创建了空 repo。这个脚本解析.gclient_entries
文件的内容,从中提取 git repo 的地址,把它们 clone 到本地,然后在推送到 github 上对应的 repo 中去。
不过,完美的解决方案,应该是解析 DEPS
文件的内容,而不是 .gclient_entries
文件的内容。
Done.