clang支持gcc兼容的依赖生成选项：-mm仅输出用户头文件依赖到stdout，-md自动生成同名.d文件供makefile集成，需配合-mp防头文件删除错误，并注意路径对齐与语言标准指定。
LLVM 本身不直接生成头文件依赖列表；实际干活的是 Clang（LLVM 的 C/C++ 前端），它复用了 GCC 的 -M 系列语义，但行为更严格、默认不包含系统头文件，且与现代构建系统（如 CMake + compile_commands.json）配合更自然。
Clang 的 -MM 和 -MD 怎么用
Clang 支持和 GCC 兼容的依赖生成选项，最常用的是 -MM（仅用户头文件）和 -MD（生成 .d 文件）。关键区别在于：-MM 只输出依赖关系到 stdout，适合调试或一次性检查；-MD 则自动写入同名 .d 文件，专为 Makefile 或 Ninja 集成设计。
-
-MM不包含<stdio.h></stdio.h>等系统头，避免污染构建逻辑 -
-MD默认输出到当前目录，文件名和输入源一致（如main.c→main.d），但路径需和目标对象文件对齐，否则 Make 会找不到 - 必须搭配
-MF显式指定 .d 路径，否则在子目录编译时容易出错（例如src/main.c编译到build/src/main.o，但main.d却生成在src/下） -
-MP强烈建议加上——它为每个依赖头文件生成一个空目标，防止头文件被删后 make 报 “No rule to make target” 错误
在 CMake 中让 Clang 自动生成 .d 文件
CMake 本身不调用 -MD，但可通过 COMPILE_OPTIONS 注入。不过更可靠的方式是启用 compile_commands.json 并配合外部工具解析依赖，因为 CMake 的依赖跟踪是“隐式”的，不落地为 .d 文件。
- 确保 CMake 配置时加了
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON，生成compile_commands.json - Clang 自身不提供“导出所有头依赖”的命令行模式，但可用
clang -Xclang -dependency-file -Xclang out.d -c main.c模拟-MD行为（-Xclang是绕过 Clang 前端参数校验的必要手段） - 若坚持用 Makefile 流程，推荐组合：
clang -MM -MP -MT '$@' -MF '$(@:.o=.d)' $，其中 <code>$@是目标（如main.o），$ 是源（如 <code>main.c） - 注意：Clang 14+ 对
-MT的处理更严格，不能含空格或 shell 元字符；若目标路径含斜杠，需用单引号包裹'build/src/main.o'
为什么 clang -M 输出为空或报错
Clang 默认禁用 -M 系列选项的完整模式（即不输出系统头），且比 GCC 更早校验参数合法性。常见失败点不是语法错，而是上下文缺失。
- 没传
-x c或-x c++：Clang 无法推断语言类型，拒绝生成依赖（尤其对无后缀的输入文件） - 没指定标准（如
-std=c11）：某些头文件宏展开失败，导致预处理中断，-MM直接退出 - 路径中含空格或中文：Clang 解析
-MF参数时可能截断，错误信息常为error: no such file or directory，实际是路径解析失败 - 用了
-fmodules或-fprebuilt-module-path：模块模式下传统头依赖生成被禁用，-MM会静默跳过或报module map not found
真正麻烦的不是生成依赖，而是让构建系统“持续感知”头文件变动——Clang 能写出 .d，但 Make 或 Ninja 必须在每次构建前重新 include 它们，且 .d 文件本身也要参与依赖链（即 main.d 依赖于 main.c 和所有头）。漏掉这一环，改了头文件也不会触发重编。这个细节在大型项目里最容易被忽略。
