捕获构建时编译器调用及参数，为Make构建的多语言项目做静态代码分析

针对用Make构建的大型项目，要保证静态分析的准确性，核心就是让分析工具拿到和编译器完全一致的宏定义、头文件路径这些参数——我之前在处理这类需求时，常用这几个靠谱的方案：

1. 用Bear生成标准编译数据库（首推） #

这是最省心的方案，Bear是专门为捕获构建过程中编译器调用而生的工具，它会自动拦截Make调用的所有编译命令，生成Clang格式的compile_commands.json文件，里面包含每个源文件对应的完整编译参数（宏定义、头文件路径、编译选项等）。

使用方法超级简单：

bear -- make

生成的compile_commands.json可以直接被绝大多数C/C++静态分析工具识别，比如：

• Clang-Tidy：直接指定该文件即可，无需手动传参数
• Cppcheck：通过--project=compile_commands.json加载参数
• Clang Static Analyzer：配合scan-build使用时也能自动读取这个文件

对于Python、Java这类语言，Bear虽然不直接支持，但它们的静态分析工具通常有自己的路径/依赖处理方式（比如Python的PYTHONPATH、Java的classpath），可以单独处理。

2. 自定义Shell脚本拦截并记录编译命令 #

如果因为环境限制用不了Bear，你可以临时替换Make的SHELL变量，让它先把执行的命令记录下来，再实际执行。

步骤如下：

1. 写一个简单的记录脚本record_cmds.sh：

#!/bin/bash
# 把执行的命令追加到日志文件
echo "$@" >> compile_cmds.log
# 实际执行原命令
exec "$@"

2. 给脚本加执行权限：

chmod +x record_cmds.sh

3. 用这个脚本来运行Make：

make SHELL="./record_cmds.sh"

之后compile_cmds.log里会记录所有的构建命令，你可以用awk、grep等工具提取出C/C编译器（gcc/g/clang）的调用，过滤出-D（宏定义）和-I（头文件路径）参数，再传给静态分析工具。

比如用awk提取参数：

# 提取所有gcc/g++命令中的-D和-I参数
grep -E '(gcc|g\+\+)' compile_cmds.log | awk '{for(i=1;i<=NF;i++) if($i ~ /^-D/ || $i ~ /^-I/) print $i}' | sort | uniq > analysis_args.txt

然后把这些参数传给分析工具，比如Cppcheck：

cppcheck src/ -- $(cat analysis_args.txt)

3. 手动提取Make变量（适合简单项目） #

如果你的项目Make结构比较简单，没有太多复杂的目标-specific参数，可以直接从Makefile里提取预定义的编译变量。

运行make -p可以打印出所有展开后的Make变量，你可以从中提取CPPFLAGS（包含预处理器宏和头文件路径）、CFLAGS、CXXFLAGS这些关键参数：

# 提取并展开CPPFLAGS和CXXFLAGS
make -p | grep -E '^CPPFLAGS =|^CXXFLAGS =' | cut -d'=' -f2- | tr '\n' ' '

然后把这些参数直接传给静态分析工具，比如Clang-Tidy：

clang-tidy src/*.cpp -- $(make -p | grep -E '^CPPFLAGS =|^CXXFLAGS =' | cut -d'=' -f2-)

不过要注意，大型项目中不同源文件可能有不同的编译参数，这种方法可能无法覆盖所有情况，准确性不如前两种方案。

其他语言的小提示 #

• Python：静态分析工具（如pylint、flake8）通常依赖PYTHONPATH来识别自定义模块，你可以在运行分析前设置好该环境变量，或者在工具配置文件（如.pylintrc）中指定模块路径。
• Java：Checkstyle、SpotBugs这类工具需要classpath，可以通过构建工具获取，比如Maven的mvn dependency:build-classpath，或者Gradle的gradle printClasspath任务，然后把结果传给分析工具的-classpath参数。

内容的提问来源于stack exchange，提问作者Grigory Rechistov