依赖编译_【上手指引】剖析Envoy Filter的Bazel编译配置

引言

Envoy是一款使用现代C++语言编写的L4/L7网络代理，采用Bazel进行依赖管理与执行编译过程。本文将以官方一个简单的HTTP Filter作为例子，分析Bazel在filter编译构建过程中所起的作用，为希望快速开始开发与编译filter的开发者提供指引，帮助大家快速了解envoy filter的编译流程。

一、Bazel简介

Bazel是一种类似CMake的用于组织编译过程的一个构建工具，类似Make，Maven和Gradle。其特点是可读性较好，支持跨语言，跨平台编译；并且可以定义代码库之间的依赖关系，支持跨代码库的联合构建。Bazel定义构建的依赖关系和规则，并管理构建生成的临时文件及二进制文件，具体的编译工作是调用各个语言的编译工具如gcc, javac等完成的。

这里简单介绍一下两个Bazel最重要的文件与相关概念：

WORKSPACE

WORKSPACE文件，用于指定当前文件夹就是一个Bazel的工作区。工作区是一个存放了所有源代码和Bazel编译输出文件的目录，也就是整个项目的根目录，WORKSPACE文件总是存在于项目的根目录下。

BUILD

一个或多个BUILD文件，用于告诉Bazel怎么构建项目的不同部分。如果工作区中的一个目录包含BUILD文件，那么它就是一个package。一个BUILD文件包含了几种不同类型的指令。其中最重要的是编译指令，它告诉Bazel如何编译想要的输出，比如可执行二进制文件或库。BUILD文件中的每一条编译指令被称为一个target。

接下来我们将开始分析Bazel在envoy-filter-example项目中的配置与作用，为了能够更好地阅读本文，希望大家已经有了Bazel的一些基础入门知识或者概念。关于Bazel的基础入门，可以参考一下两篇文章，看完了基本上就对Bazel有个总体了解了：

• Bazel官方示例解读(CSDN): https://blog.csdn.net/elaine_bao/article/details/78668657

二、Filter示例的目录结构

首先，我们从github上clone下来filter的示例代码，并拉取子模块：

git clone https://github.com/envoyproxy/envoy-filter-example.git
cd envoy-filter-example
git submodule update --init

从仓库中，我们来分析一下使用Bazel编译时主要的目录结构：

.
├── WORKSPACE // 指定该目录是一个Bazel工作区，文件内容告诉Bazel如何去得到其他的工程源供BUILD使用
├── BUILD // 描述如何构建根目录Package
├── .bazelrc // 对envoy/.bazelrc进行了引用
├── .bazelversion // 文件内容表示该工作区需要使用的Bazel版本
├── echo2.cc
├── echo2.h
├── echo2_config.cc
├── echo2_integration_test.cc
├── bazel // 仅包含了一个get_workspace_status文件，根据envoy/.bazelrc的描述，构建时将使用其生成--workspace_status_command参数的值
├── envoy // envoy源码作外部源被引入
│   ├── WORKSPACE // envoy目录也是一个Bazel工作区，文件内容告诉Bazel如何去得到其他的工程源供BUILD使用
│   ├── BUILD // 描述了envoy根目录的构建规则
│   ├── .bazelrc // 包含了大量预定义的在执行bazel build时的默认参数，以及自定义扩展参数的描述
│   ├── .bazelversion // 文件内容表示该工作区需要使用的Bazel版本
│   ├── bazel // 文件夹中包含了大量自定义的Bazel配置文件，使用类似于Python的Starlark语言编写，会被BUILD与WORKSPACE文件引用
└── http-filter-example // http filter的源码目录，工作区的一个Package
├── BUILD // 定义了http filter这个Package的构建规则
├── http_filter.cc
├── http_filter.h
├── http_filter.proto
├── http_filter_config.cc
└── http_filter_integration_test.cc

三、WORKSPACE文件分析

envoy_filter_example的WORKSPACE文件与envoyproxy项目的WORKSPACE文件结构与内容大体一致，通过分析filter的WORKSPACE文件，我们也就明白envoy自身的工作区描述了。

workspace(name = "envoy_filter_example") # 工作区名称

# 使用local_repository引入通过git submodule拉下来的envoy项目，并将项目命名为envoy，后续可通过@envoy进行引用
local_repository( 
name = "envoy",
path = "envoy",
)

# 从envoy的bazel/api_binding.bzl中读取envoy_api_binding符号
load("@envoy//bazel:api_binding.bzl", "envoy_api_binding")

# envoy_api_binding函数会注册@envoy_api与@envoy_api_canonical两个外部依赖，分别指向envoy/generated_api_shadow以及envoy/api。
# 通过对函数注释的解读，以及对源码的全局搜索，可见envoy源码中仅使用了@envoy_api依赖引用，而@envoy_api则由@envoy_api_canonical通过脚本进行生成，从而能在编译时过滤掉不在使用，而又正在开发或已经废弃的api
envoy_api_binding()

# 从envoy的bazel/api_repositories.bzl中读取envoy_api_dependencies符号
load("@envoy//bazel:api_repositories.bzl", "envoy_api_dependencies"