635 字
3 分钟
关于C/C++编译链浅显的理解

简单介绍一下ninja,make,cmake,clang,clangd,llvm之间的关系

按照使用顺序:clangd->ninja->make->cmake->llvm/clang

这基本上就是大概的使用顺序;

clangd#

首先clangd需要区别于VSCode中的clangd插件,clangd插件的作用是把你在编辑器里的动作翻译成指令发给 clangd.exe,再把 clangd.exe 的分析结果画在屏幕上(比如红色的波浪线),他们两个缺一不可。

ninja/make#

这两个都是构建工具,可以直接用ninja替代make,但是ninja的配置文件和make不同,不能手写,只能用工具生成。

cmake#

是用于生成构建构建工具的配置文件的工具,就是说是用来生成make/ninja配置文件的工具,它的配置是CMakeList.txt,这个文件一般需要用户手写。

llvm/clang#

llvm是一整个编译器框架,提供中间表示(IR)、优化器、后端代码生成等模块,它里面包含整个编译链所需要的所有东西,比如它里面有clangd,clang,也有gdb用于调试

注意事项#

在VSCode使用clangd插件时,因为clangd调用clangd.exe时需要传递参数,一般情况下传递的是compile_commands.json。

有时可以正常编译,但是clangd一直报错找不到头文件经查阅资料可知当clangd找不到头文件时:

  1. 首先根据compile_commands.json文件中分析,观察是否是有-I相关的目录,去寻找头文件(.clangd文件是对compile_commands文件的补充)。
  2. 然后compile_commands.json查找失败时,就会根据已有的信息自己猜。
  3. 在.clangd中添加的额为信息最重要的不是准确目录信息而是--target=x86_64-w64-windows-gnu,因为传入了这个信息clangd就可以知道这是一个 MinGW / GNU ABI 的工具链,自动启用 MinGW toolchain 探测逻辑而不是像 MSVC 或“未知平台”那样瞎猜,此时就算传入错误的准确*include/*路径,clangd也会自动根据已有信息自动猜测出正确的路径。
  4. 比如我使用的mingw-mstorsjo-llvm-ucrt工具链是一个非官方构筑的工具链,如果使用官方的clangd.exe就必须告诉他我使用的是一个什么类型的工具链,它才能找到准确的头文件,但是我的这个工具链里面自带一个clangd.exe,作者在第三方构筑时就已经传入自己工具链的信息,那么我使用它的时候就无需传入类型信息,他可以自己正确寻找工具链头文件。
关于C/C++编译链浅显的理解
https://fuwari.vercel.app/posts/关于c和cpp编译链浅显的理解/
作者
哈轰轰轰
发布于
2025-12-22
许可协议
CRAZY KF-C-V 5.0