在Debian/Ubuntu上，llvm包仅含运行时工具和共享库，不含头文件等开发资源；llvm-dev才提供头文件、静态库、CMake配置及llvm-config工具，开发LLVM Pass或链接libLLVM必须安装llvm-dev。
区分 llvm-dev 和 llvm 这两个包名
在 Debian/Ubuntu 系统上，llvm 包只含运行时工具（如 llc、opt、llvm-dis）和共享库（libLLVM.so），但不含头文件、静态库或 CMake 配置文件；而 llvm-dev 才提供开发所需的一切：包括 llvm-c.h、LLVMConfig.cmake、libLLVM.a，以及 llvm-config 工具本身。
如果你只是想跑 clang 编译 C 代码，或者用 lli 执行 bitcode，装 llvm 就够了。但只要你要写 LLVM Pass、链接 libLLVM、用 CMake find_package(LLVM)，就必须装 llvm-dev —— 否则 #include "llvm/IR/Module.h" 直接报错找不到头文件，llvm-config --cxxflags 也根本不存在。
macOS 上 Homebrew 的 llvm 包默认带开发内容
Homebrew 安装的 llvm（即 brew install llvm）实际等价于 Linux 下的 llvm-dev：它包含完整的头文件树、libLLVM.dylib、llvm-config、CMake modules，甚至 clang++ 前端。不需要额外装别的包。
但要注意路径问题：brew 安装的 LLVM 默认不进系统 PATH，二进制在 /opt/homebrew/opt/llvm/bin（Apple Silicon）或 /usr/local/opt/llvm/bin（Intel）。你得手动加进 shell 配置，否则敲 clang++ -x c++ -std=c++17 会提示 command not found。
另外，Homebrew 的 llvm 包默认启用 shared libs，但不带 static libs（libLLVM.a 被删了）。如果项目明确 require 静态链接（比如某些嵌入式构建脚本），就得自己从源码编译并指定 -DBUILD_SHARED_LIBS=Off。
Windows 上没有“dev vs runtime”包分离概念
MSVC 或 MinGW 环境下，LLVM 官方预编译包（从 releases.llvm.org 下载的 Clang+LLVM-*.msi）本身就是全量包：包含 include/、lib/（含 .lib 和 .dll）、bin/、share/ 全套。安装完就能直接用 llvm-config 和 #include "llvm/Support/raw_ostream.h"。
但容易踩的坑是：Windows 下 CMake 的 find_package(LLVM) 很容易找不到，因为官方包没把 LLVMConfig.cmake 放进标准路径。解决方法是显式传参：cmake -DLLVM_DIR="C:/Program Files/LLVM/lib/cmake/llvm" ...。另外，若用 MSVC 编译你的 Pass，必须确保和 LLVM 运行时用同一套 CRT（/MD vs /MT），否则链接时报一堆 LNK2038 不匹配错误。
源码编译时，开发包就是“默认输出”
从 GitHub 拉 llvm-project 并用 CMake 构建，只要没加 -DLLVM_BUILD_LLVM_DYLIB=Off 或 -DLLVM_INCLUDE_TESTS=Off 这类裁剪选项，build 目录里天然就有头文件、静态/动态库、llvm-config、CMake config 文件 —— 本质上就是“自带 dev 包”。
关键差异在 make install 阶段：DCMAKE_INSTALL_PREFIX 指向的目录，就是你未来项目要 find_package 的根。如果你跳过 make install 直接用 build 目录，CMake 可能因路径太深或含空格而失败；如果只 make 不 make install，别人 clone 你项目时就无法复现环境 —— 这点比包管理器更需主动管理。
最后提醒一个隐蔽点：LLVM 的 C++ ABI 在不同发行版间不兼容。比如 Ubuntu 22.04 自带的 llvm-dev 是基于 libstdc++13 编译的，而你自己用 Clang 18 编译的 Pass 若链接了 libc++18，运行时大概率 crash。真要混用，务必统一 toolchain 和 stdlib 版本。
