给项目接上静态分析的时候，光靠把源码目录指给工具是远远不够的；对于C/C++test来说，它还得弄清楚每一个源文件到底用的是哪一款编译器、带着哪些宏定义、头文件去哪儿找，以及编译的时候都跟着哪些参数。如果项目是用CMake来构建的，那完全可以先准备一份compile_commands.json文件；而换作是别的构建系统，也能通过C/C++test自己提供的工具去生成一种bdf格式的文件；这两条路子的目的都一样，就是要把软件当初真实的构建环境给还原出来，单靠手工去添加源码肯定是应付不过来的。

　　一、怎样准备好编译数据库

　　在动手准备编译数据库以前，最好先看一眼你的项目，它是用CMake管的，还是靠着Makefile、Visual Studio，又或者是一套交叉编译脚本在跑；因为不同的构建方式，最后会生出不一样的数据文件，得区别对待才行。

　　1、CMake项目生成JSON文件

　　假如是CMake管理的项目，那么在生成构建目录的时候，可以顺手加上这样一个选项：-DCMAKE_EXPORT_COMPILE_COMMANDS=ON；等生成工作全部跑完之后，到那个构建目录里头去翻一翻，就能找到一份compile_commands.json文件，它里头会很实在地记录下每一个翻译单元所在的工作目录、源文件的路径，还有一整套完整的编译命令。CMake官方的说明里也讲清楚了，这项功能主要对Makefile和Ninja这两种生成器管用，要是用了别的生成器，那可能就不会输出这个文件了，这点最好心里先有个底。

　　2、检查数据库里的内容

　　拿到compile_commands.json文件之后，不要光盯着文件名就觉得万事大吉了，一定要把它点开，从里面抽出几条记录来瞧瞧；重点去核对那几个关键的字段，比方说directory、file还有command或者arguments，顺着这些信息看过去，确认编译器本身的路径能不能对得上，-I后面指出的那些头文件目录存不存在，-D后面跟着的宏定义有没有写全，源文件的路径又是不是真的能摸到。很多时候，文件虽然是成功生成了，可里面偏偏缺了一些要紧的内容，这样子勉强拿去分析，结果肯定也是靠不住的，所以内容有没有缺失比文件能不能生成更重要。

　　3、给非CMake的项目准备bdf文件

　　要是你的项目用着Makefile，或者是自己写了一套构建脚本，那就得换一种思路了；可以在完整构建命令的最前面加上一个cpptesttrace，比如敲成cpptesttrace make clean all这个样子，它会悄悄跟在构建过程的屁股后面，把那些真正执行过的编译和链接进程给一一记下来，最后写进一个bdf文件里面；有些场景下，也可以把cpptestscan当成编译器和链接器的前缀来接进构建脚本里，这两种手段都能帮助抓到实际用到的编译器命令，不至于漏掉一些藏在角落里的编译步骤。

　　4、一定要执行一次完整的重新构建

　　在准备数据库的时候，千万记得要先做一次清理，接着跑一次完整的构建，而不是光跑一下增量编译；如果只做了增量编译，那数据库里面很可能就只记录了那么一小部分发生变动的源文件，后面真正进行扫描的时候，就会不知不觉地漏掉很多文件，整个扫描范围就凭空小了一大块，结果也就不会完整了。

　　二、编译数据库导入失败该怎么排查

　　万一编译数据库在导入的时候报了错，先别急着一遍又一遍地重建整个项目，那样反而容易把人绕晕；按照文件格式、路径、编译器还有环境变量这么几条线索，一项一项地往后捋，更容易把真正的问题给揪出来。

　　1、确认导入参数有没有写对

　　如果在命令行底下做分析，可以用cpptestcli-input compile_commands.json这样的方式来直接导入CMake生成的那个JSON文件，也可以把事先拿到的bdf文件传给-input参数；根据Parasoft官方文档的描述，他们同时支持JSON格式的项目定义文件、bdf文件，还有Visual Studio的项目文件来作为分析的输入，所以先得保证自己选的这个参数，跟手里的文件类型是正好对得上的。

　　2、检查路径是不是已经失效

　　编译数据库里面，经常会保存一大堆绝对路径；假如把文件从当初做构建的那台电脑上，复制到了另一台完全不同的机器上，那原来记载的那些源码目录、工具链目录还有头文件目录，很可能早就不在原来的地方了；可以先抽查几条记录里的directory和file这两个字段，然后再去确认一下编译器这个可执行文件，在当前的环境当中到底能不能被系统找到，如果连编译器都找不到，那后面的所有步骤自然也没法往下走。

　　3、检查编译器的配置

　　交叉编译的项目被导入之后，要是报错比较扎堆，那很有可能是C/C++test还没有认出当前这个编译器到底是什么来路；碰到这种情况，可以试着用一下-list-compilers这个选项，去看一看目前有哪些可用的编译器配置，或者借助-detect-compiler来让工具帮忙自动识别一把；如果用的是自己定制的工具链，那就还得额外补上对应的编译器配置，不然工具没有办法按照预期去解释那些编译参数。

　　4、检查数据库本身完不完整

　　有时数据库倒是成功导进去了，可扫描到的文件却少得可怜，这种时候，通常就要回头去核实一下，这份数据库到底是不是从一次完整的重新构建里生出来的；另外，还要去确认那些自动生成的代码、第三方的库文件，还有测试用的目录，是不是按照项目的要求被正确地纳入了或者排除掉了，免得把扫描范围方面的问题，稀里糊涂地当成是规则配置出了岔子。

　　三、编译数据库导入后该怎样复核

　　等数据库能够顺利导入以后，还不能掉以轻心，最好再专门做一次范围的复核；否则工具虽然表面上开始吭哧吭哧地分析了，可结果里面却很有可能把某些关键的模块给漏掉了，那时候再回头看就会比较被动。

　　1、抽查一下源文件的数目

　　可以拿项目里实际的源文件个数，去跟扫描日志里记录下来的输入文件数目做一个对比；要是两边差得特别多，那就要重新回到构建命令那里，去查一查是不是不小心漏掉了哪一个子模块，或者是条件编译的分支没有覆盖全，这些都会导致很多文件被悄悄忽略掉。

　　2、抽查宏定义和头文件路径

　　找到一个依赖关系比较多的源文件，单独去检查它对应的那一条编译参数；一旦里面的宏定义缺了，或者头文件的路径指错了，解析的时候就会直接报出错误，还可能顺带引出很多不太可靠的报警，扰乱后面的判断，所以这一块也需要重点瞧一眼。

　　3、把生成流程固定下来

　　把生成编译数据库或者bdf文件的那几条命令，写进自动化的流水线里面，并且顺手记录一下此时用的是什么版本的工具、什么版本的编译器，以及构建时传入了哪些关键参数；这样等到以后扫描结果出现波动的时候，就可以很快分清楚，这究竟是代码本身起了变化，还是说输入进来的编译环境已经跟之前不一样了，不至于两边原因搅在一起分不开。

　　总结

　　关于C/C++test的编译数据库怎么去准备，以及导入失败以后又该怎么排查，大致的处理顺序可以这么来概括：首先根据项目采用的是哪种构建系统，生成对应的compile_commands.json或者bdf文件；接着仔细核对里面的编译命令、路径和工具链信息，把明显的错误先清理掉；最后再回头看一看扫描的范围符不符合预期。编译数据库越能够贴近软件当初真实的构建环境，后面静态分析得出来的结果也就会越容易去解释清楚，整个排查的工夫就花得更值当。