原文地址:Envoy bazel 学习 & 踩坑
近一年有开始折腾 Envoy 了,在 bazel 这块踩了一些坑,总结记录下的,主要是个人的体感,不一定准确,欢迎批评指正。
bazel 是个啥
编译构建工具,跟常用的 Makefile 是类似的。
只是,bazel 更复杂,上手门槛更高,以我的个人的体验来看,主要是为了提升表达能力,可编程能力更强。
Makefile 通常是用于简单的描述,偶尔会搞个函数啥的;但是在 bazel 里,会看到大面积的自定义函数。
为啥 Envoy 需要 bazel
Envoy 是个 C++ 项目,C/C++ 这种比较老的语言,没有内置依赖包管理器这种先进特性(相比较而言,Go 语言在这块就先进了许多)。
我的理解,对于 Envoy 来说,bazel 一个主要的作用就是,补齐了依赖包管理。如果仅仅是编译,Makefile 之类的简单工具,应该也够用了。
几个概念
有几个常用的基本概念,先了解一下的
WORKSPACE
在项目的根目录,会有一个 WORKSPACE
文件,用于描述整个项目的,最主要是描述了依赖库,比较类似于 Go 语言中的 go.mod
,go.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.mod
,go.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
最后
记录下,我这边可以完整工作的环境:
- g++ 11
- gdb 11
在这个环境下,gdb 是可以完整工作的,局部变量都可以看。
之前在一个比较老的版本上,工作是不太顺利的。
如果觉得有意思,欢迎关注我的公众号 「豆浆大叔」~
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。