原文地址:Envoy bazel 学习 & 踩坑

近一年有开始折腾 Envoy 了,在 bazel 这块踩了一些坑,总结记录下的,主要是个人的体感,不一定准确,欢迎批评指正。

bazel 是个啥

编译构建工具,跟常用的 Makefile 是类似的。

只是,bazel 更复杂,上手门槛更高,以我的个人的体验来看,主要是为了提升表达能力,可编程能力更强。

Makefile 通常是用于简单的描述,偶尔会搞个函数啥的;但是在 bazel 里,会看到大面积的自定义函数。

为啥 Envoy 需要 bazel

Envoy 是个 C++ 项目,C/C++ 这种比较老的语言,没有内置依赖包管理器这种先进特性(相比较而言,Go 语言在这块就先进了许多)。

我的理解,对于 Envoy 来说,bazel 一个主要的作用就是,补齐了依赖包管理。如果仅仅是编译,Makefile 之类的简单工具,应该也够用了。

几个概念

有几个常用的基本概念,先了解一下的

WORKSPACE

在项目的根目录,会有一个 WORKSPACE 文件,用于描述整个项目的,最主要是描述了依赖库,比较类似于 Go 语言中的 go.modgo.sum

比如 Envoy 的 WORKSPACE 文件中,有这样的描述:

load("//bazel:repositories.bzl", "envoy_dependencies")
envoy_dependencies()

其中,具体依赖库的详细信息,在 bazel/repository_locations.bzl 文件里。
比如下面这个示例:

    boringssl = dict(
        project_name = "BoringSSL",
        project_url = "https://github.com/google/boringssl",
        version = "098695591f3a2665fccef83a3732ecfc99acdcdd",
        sha256 = "e141448cf6f686b6e9695f6b6459293fd602c8d51efe118a83106752cf7e1280",
        strip_prefix = "boringssl-{version}",
        urls = ["https://github.com/google/boringssl/archive/{version}.tar.gz"],
    ),

描述的是依赖库 boringssl,是不是很像 go.modgo.sum

另外,在这里还可以频繁看到 @envoy @envoy_api 这种,这里也表示的一个依赖库的作用域。

BUILD

BUILD 文件会有很多个,用于描述一个目标的编译过程,类似于 Makefile 中描述一个目标的构建过程。

比如,这样子的:

envoy_cc_library(
    name = "lua_filter_lib",
    srcs = ["lua_filter.cc"],
    hdrs = ["lua_filter.h"],
    deps = [
        ":wrappers_lib",
        "//envoy/http:codes_interface",
        "@envoy_api//envoy/extensions/filters/http/lua/v3:pkg_cc_proto",
    ],
)

.bazelrc

这也是在项目根目录下的,用于描述 bazel 的默认配置。

比如,这个:

build:linux --copt=-Wno-deprecated-declarations

可以指定一些编译参数之类的。

执行

有了上面这些描述信息之后,最终要执行编译构建的命令就简单许多了

比如:

bazel build envoy

这里的构建目标 envoy,来自项目根目录下的 BUILD 文件。

也可以是这样子的:

bazel build //source/exe:envoy

此时的构建目标 //source/exe:envoy,来自项目根目录下的 source/exe/BUILD 文件了。

踩过的坑

除了上面这些一手体感,还有一些坑,也记录下的

变更编译器版本

有一次,想换个高版本的 gcc,但是修改了 PATH 后重新构建,始终不生效。

原来是,bazel 是增量编译的,所以会使用上一次编译时使用编译器,以保证整个项目是使用的同一个编译器。

所以,如果想更换编译器,需要清空下缓存:

bazel clean --expunge

split DWARF

较新版的 Envoy,启用了 -gsplit-dwarf 这个特性,也就是将调试符号放到独立的 .dwo 文件里了,以减少生成的二进制文件大小。

不过呢,这个特性还比较新,可能会有一些坑,至少在我的环境下(gdb 11,这个版本也不低了),就有 .dwo 读取错误。
比如这样子的:

DW_FORM_strp pointing outside of .debug_str section

所以,干脆关掉这个特性,就一切正常了(主要是 bt full 这类查看局部变量的功能)。

具体操作是,注释掉 .bazelrc 中的这一行:

# build:linux --features=per_object_debug_info

最后

记录下,我这边可以完整工作的环境:

  1. g++ 11
  2. gdb 11

在这个环境下,gdb 是可以完整工作的,局部变量都可以看。

之前在一个比较老的版本上,工作是不太顺利的。

如果觉得有意思,欢迎关注我的公众号 「豆浆大叔」~


doujiang24
209 声望1k 粉丝

Core developer of OpenResty.


引用和评论

0 条评论