Mac 从Makefile 编译 Rocksdb 源码的一些注意事项

文章目录

前言
Makefile 编译流程
- 1. 平台变量/环境变量的初始化。
- 2. 编译需要的源码文件变量初始化。
- 3. include 目录的设置。
- 4. 编译的执行逻辑。
- - 问题记录1：可能的打包命令`ar` 失效问题
- 5. 执行具体的编译指令
- - 问题记录2: jar 包编译

前言

最近在Mac 本地编译Rocksdb 过程中踩过不少坑，特此做一个记录，希望能帮助到大家。

Rocksdb 源码的本地编译需求来自于 Rocksdb 使用者对本地开发/测试环境的依赖，尤其是Java 开发的同学依赖更强，因为基本的开发和调试在本地的 IDEA 会方便无数倍。而且，RocksJava 的功能也会随着社区版本迭代，所以使用过程中需要编译不同版本的的 Rocksdb 的jar包。

本地编译原生主要是两种，一种是Makefile，另一种是CMakeList.txt，还有一种是bazel方式，官方也提供了TARGET文件。当然，用bazel从源码编译可能会更方便一些，符号信息也会更全一些，这里就看大家自己的选择了。

此外，本篇可能记录的是我遇到的一些坑，但不代表大家就一定能遇到，或者说大家遇到的我不一定能够遇到。所以整体提供的解决方法以及案例可能更偏向于方法论，就是告诉大家实际的编译流程，以及这个过程中的source文件,include文件，依赖库都是在哪里进行初始化的，以及可以在哪里进行补充，这样大家有了整个编译流程之后就能够根据自己的环境快速解决对应的问题。

描述之前，可以先做一些方便大家阅读makefile的准备工作，我这里使用的是ctags + vim。
好处是rocksdb 直接提供ctags的生成目录，在Makefile 所在目录执行命令make ctags -j就好了。可能需要大家安装cscope命令brew install cscope

有了ctags的辅助，我们就可以在Makefile中自由跳转了。

Makefile 编译流程

1. 平台变量/环境变量的初始化。

Makefile中会有一些类似 $(PLATFORM) 这样的外部变量，Makefile中的逻辑大多是根据这一些外部变量来判断自己的编译行为。比如不同的操作系统选择不同的编译库/编译逻辑，对系统依赖库的初始化设置。
所有这一些系统变量/环境变量的初始化都在这个文件中：
build_tools/build_detect_platform

像基本的系统库，是否使用fallocate, snappy, zstd等都是这里面设置的，还有我们编译打包的基础命令$(CC), $(CXX), $(AR) 的初始化也都是在这个文件中。

也就是说make static_lib 这条命令会先通过上面这个文件进行变量的初始化，而如果我们想要外部改变变量，则指定的ROCKSDB_DISABLE_GFLAGS=1 make static_lib -j也都是通过这个文件来生效的。

2. 编译需要的源码文件变量初始化。

我们在Makefile 有一些带有SOURCE 的关键字，他们一些保存源码路径的变量，用来编译一些库文件。

这个时候我们通过前面说的ctags 来跳转到声明ctrl + ] ，返回上一个位置ctrl + o。就能看到这一些初始化的变量是在
src.mk之中。

也就是大家如果想要补充一些自己修改的源码文件，即可到src.mk之中添加。
而在Makefile中 src.mk 变量被引入的方式是:

 include src.mkAM_DEFAULT_VERBOSITY = 0

如果有对rocksjni 的代码进行修改，则同样需要将对应的代码文件补充到src.mk中的JNI_NATIVE_SOURCES变量。

3. include 目录的设置。

我们想要设置一些编译依赖的头文件所在目录，可以在如下集中的一个地方进行设置：

CFLAGS += $(WARNING_FLAGS) -I. -I./include $(PLATFORM_CCFLAGS) $(OPT)
CXXFLAGS += $(WARNING_FLAGS) -I. -I./include $(PLATFORM_CXXFLAGS) $(OPT) -Woverloaded-virtual -Wnon-virtual-dtor -Wno-missing-field-initializers

也就是说如果大家遇到一些依赖库的问题，即通过-lxxx这样的方式解决不了的，则可以直自己从源码编译依赖库，在这里指定include 和 .dylib 所在位置就可以。

4. 编译的执行逻辑。

这个其实很简单，有了我们的ctags，我们很容易梳理出一个大体的执行流。从make static_lib来看，最终的成果物是一个librocksdb.a文件。

如上执行目标是static_lib，则$(LIBRARY)是实际的${LIBNAME}.a，也就是我们想要生成librocksdb.a，那就看$(LIBRARY)作为执行目标的位置。

这里我们就看到了真正生成librocksdb.a执行目标的位置了，下面的$(AM_V_at) 以及 $(AR)则是提前初始化好的打包命令，而$(LIBOBJECTS)则是要求从源码文件.cc编译成.o的文件集LIBOBJECTS = $(LIB_SOURCES:.cc=.o)。

如果再想仔细追溯每一个变量的源头，按照tags 跳转就好了。

问题记录1：可能的打包命令`ar` 失效问题

提一下，在6.6.0版本以前，on Mac的打包命令可能会失效，因为 on linux 和 on mac 的初始化AR变量有差异。
所以大家可以在build_tools/build_detect_platform中增加针对$(AR)的显式设置，这样不论什么时候$(AR) 变量都是一个有效的子命令。

 if test -z "$AR"; thenif [ -x "$(command -v gcc-ar)" ]; thenAR=gcc-arelif [ -x "$(command -v llvm-ar)" ]; thenAR=llvm-arelseAR=arfifi

5. 执行具体的编译指令

编译的时候我们一般会编译一些library或者一些测试工具，这里简单说明一下编译命令。

编译动态库/静态库 make static_lib -j6 或者 make shared_lib -j6，默认不带任何符号信息。
如果想要把符号信息也添加进去来方便调试，则需要设置DEBUG_LEVEL=1 make static_lib，会以 -O2 的方式进行编译，并将一些测试代码和符号信息也编译到库中。
编译rokcsdb 的测试工具：DEBUG_LEVEL=0 make db_bench
因为工具的运行需要一些依赖库，这里可能需要大家安装对应的依赖库。
gflags, snappy,zstd,zlib,lz4等，安装可以直接通过brew install xxx就可以，而像一些fallocate或者jemalloc 的依赖问题，如果不想安装，可以通过ROCKSDB_DISABLE_FALLOCATE=1 或者 ROCKSDB_DISABLE_JEMALLOC=1来禁用即可。
编译完成之后，可以通过otool -L db_bench 这样的命令来进行测试。

问题记录2: jar 包编译

编译jar包，建议通过 rocksdbjavastatic 来进行编译，否则一些jni的代码编译不进去，出来的jar 包无法独立使用，缺少一些jni的符号。
编译java的时候如果本地shell 环境没有设置JAVA_HOME，则需要单独指定。

通过执行/usr/libexec/java_home 来得到JAVA_HOME的路径
```
 $ /usr/libexec/java_home
/Library/Java/JavaVirtualMachines/jdk-15.0.1.jdk/Contents/Home
```
如果执行失败，则表示没有安装jdk，需要brew search jdk 并 brew install jdk@xxx 安装指定版本的jdk
通过 rocksdbjavastatic 编译的时候需要从网络上下载以及编译一些压缩算法，这里建议单独下载好到Makefile所在目录。
```
lz4-*.tar.gz .
snappy-*.tar.gz .
zlib-*.tar.gz .
zstd-*.tar.gz .
bzip2-*.tar.gz .
```
编译命令则建议通过ROCKSDB_DISABLE_JEMALLOC=0 DEBUG_LEVEL=0 JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-15.0.1.jdk/Contents/Home make rocksdbjavastatic -j6 进行安装。
编译完成之后会在java/target/目录下生成 jar 包和 librocksdbjni 的library。
```
 ls java/target
apidocs                       rocksdbjni-6.4.6-javadoc.jar
classes                       rocksdbjni-6.4.6-osx.jar
librocksdbjni-osx.jnilib      rocksdbjni-6.4.6-sources.jar
librocksdbjni-osx.jnilib.dSYM test-classes
```

jar 包的测试，可以通过java/samples/src/main/java/RocksDBSample.java 代码进行测试：

cd java/src
# 1. 编译测试代码
/Library/Java/JavaVirtualMachines/jdk-15.0.1.jdk/Contents/Home/bin/javac -d . -cp \
../target/rocksdbjni-6.4.6-osx.jar:. ../samples/src/main/java/RocksDBSample.java \
-Xlint:deprecation# 2. 运行测试代码 并指定db-dir
/Library/Java/JavaVirtualMachines/jdk-15.0.1.jdk/Contents/Home/bin/java -cp \
../target/rocksdbjni-6.4.6-osx.jar:. RocksDBSample db-dir

没有core 且生成db-dir 目录，则表示当前jar包无异常。

当然，也可以跑一下java的unitest，如果都过了，那也没什么问题。