22.4 C/C++ 开发环境
C/C++ 概述
C/C++ 是两门具有悠久历史的经典编程语言，至今仍在系统编程、高性能计算、嵌入式开发等领域占据核心地位。FreeBSD 作为一个以稳定性、高性能和完整内核源码开放著称的操作系统，其内核及大量用户态工具均以 C 语言编写，充分体现了 C 语言在系统级开发中的独特优势：可移植的底层内存操作能力、极小的运行时开销、与操作系统接口的高度契合性，以及长期积累的庞大生态基础。
本文旨在为初学者及有一定经验的开发者提供几种在 FreeBSD 环境下快速搭建 C/C++ 开发环境、编译程序并进行调试的实用方法，帮助读者在 FreeBSD 平台上快速开展 C/C++ 项目开发。
LLVM / Clang 概述
FreeBSD 基本系统内置 Clang 编译器，但并不包含 LLVM 中的其他组件，如 clangd（语言服务器，用于代码补全、编译错误提示和定义跳转等）、Clang-Tidy（代码风格诊断器）以及 clang-format（用于格式化 C/C++ 代码）。
因此需要安装 LLVM，这里可以使用各个版本的 LLVM，但其版本至少不应低于系统自带的 Clang。在 FreeBSD 15.0-RELEASE 中，基本系统中的 Clang 版本为 19。
查看 Clang 编译器的版本信息：
# clang -v
FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2)
Target: x86_64-unknown-freebsd15.0
Thread model: posix
InstalledDir: /usr/bin下文使用 LLVM 20，安装后对应的程序名为 clang20、clang++20、clangd20 和 clang-format20。系统自带的 Clang 程序名为 clang。如果使用不同版本，请注意对应的程序名称。
LLVM 项目上游的 LLVM 版本号
在 LLVM 项目上游的源代码中，在 LLVM 19 之前，LLVM 源代码的版本号规定在文件 llvm/CMakeLists.txt 中，在 [cmake] Exposes LLVM version number in the runtimes. 之后，LLVM 版本号规定在源文件 cmake/Modules/LLVMVersion.cmake 中。
FreeBSD 基本系统中的 LLVM 版本号
FreeBSD 将 LLVM 导入了基本系统源代码中，但是不是直接导入，而是经过了一定的处理，写作文章时 FreeBSD src 内置的 LLVM 仍为 LLVM 19，故而，注明版本号的文件路径位于 lib/clang/include/clang/Basic/Version.inc：
从 Ports 安装 Clang 环境包
基本系统内置的 Clang 版本可能较低，无法满足日常需要。因此需要从 Ports 安装。
使用 pkg 安装：
或者使用 Ports 安装：
参考文献
FreeBSD 部分 C/C++ 开发工具概览
Visual Studio Code 的开源版本，去除微软闭源组件和遥测功能，功能强大的可扩展代码编辑器。
TypeScript / JavaScript (Electron 框架)
轻度至中度（通过扩展可接近 IDE 功能）
使用 VSCode（Code-OSS） 开发 C/C++
考虑到 C 与 C++ 在语法、工具链及编译流程上具有高度的相似性，本文将以 C 语言为例，详细介绍开发环境的配置方法。 对于 C++ 的开发需求，读者可参考 C 语言的配置步骤，在编译器选择、项目设置等方面进行相应的调整即可。
安装 VS Code
使用 pkg 安装：
或者使用 Ports 安装：
需要注意的是，以这种方式安装的 VS Code 实际上是 Code - OSS 备份。Code - OSS 与 VS Code 的区别主要在于许可证不同以及可用的闭源资源不同，类似 Chromium 与 Chrome 的关系。
目前已知微软的 Python 插件以及 LLVM 的 clangd 插件都可以直接在 Code - OSS 上运行，但同步设置服务暂时无法使用。
设置中文环境
安装必要的软件
安装相关工具以在编辑器中正常运行和调试。
使用 pkg 安装：
使用 ports 安装：
可选：安装 GNU 套件 gcc、gdb。
安装所需插件
由于 FreeBSD Ports 中的 VSCode 实际为 Visual Studio Code 的开源版本 Code-OSS，该版本移除了微软的闭源组件及遥测功能，因此无法直接访问微软官方的扩展市场，也无法安装或使用依赖微软专有库的官方 C/C++ 扩展。为了在 FreeBSD 上获得完整的 C/C++ 开发支持，需要选用一组开源替代插件，以提供语言服务、调试适配及构建任务集成等核心功能。
请按以下步骤安装所需插件：
打开 VSCode 扩展视图（Ctrl+Shift+X）。
搜索并安装以下三个插件：
llvm-vs-code-extensions.vscode-clangd：基于 Clang 的语言服务器，提供代码补全、语法检查、跳转定义等功能。webfreak.debug：调试适配器客户端，支持多种调试器后端（如 lldb-mi）的集成。KylinIdeTeam.cppdebug：专为 C/C++ 设计的调试扩展，与 lldb-mi 等调试器配合，实现断点、变量监视等调试能力。
安装完成后，即可通过后续的配置文件（launch.json 和 tasks.json）将上述插件与底层工具链衔接，搭建起完整的 FreeBSD 下 C/C++ 开发环境。
鉴于 C/C++ 生态中可选的工具链与调试方案极为丰富，本篇仅选取三种典型组合作为示例，分别对应调试适配器 lldb-mi，以及构建系统 CMake + Ninja 和 Meson + Ninja。我们将以 Visual Studio Code 作为前端开发环境，演示如何将这些底层工具集成于编辑器之中。
需要说明的是，C/C++ 项目的配置并无“万能模板”，实际开发中需根据项目结构和构建需求灵活调整。因此，本节将以一个极简实例为切入点：项目名称为 test，仅包含一个源文件 main.c。通过此实例，读者可直观理解配置文件的编写逻辑，并以此为起点应对更复杂的项目场景。
调试器集成：基于 lldb-mi 的配置
首先，请进入项目根目录，即 test 文件夹，其下存在 main.c。在该目录下存在隐藏文件夹 .vscode（不存在则手动创建）。
随后，在 .vscode 文件夹内新建两个 VSCode 所需的配置文件：launch.json 用于定义调试器的启动参数与行为，tasks.json 则用于配置构建任务的执行流程。
这两个文件是 VSCode 与底层工具之间的桥梁，通过 launch.json 和 tasks.json 可以统一管理项目的调试与构建过程。
准备好后，在 launch.json 写入：
在 tasks.json 写入：
随后即可使用 VSCode 的运行与调试功能。
构建系统集成：CMake + Ninja
因为要用到 CMake，所以在项目根目录创建一个 CMakeLists.txt 文件。
把以下内容写入该文件中：
提示
这是一个最简单的 CMake 配置，读者应根据实际情况进行调整。
然后同理，在 .vscode 文件夹下创建 launch.json 和 tasks.json 文件。
在 launch.json 写入：
在 tasks.json 写入：
构建系统集成：Meson + Ninja
Meson 构建系统以 meson.build 文件为核心配置文件，用于定义项目的构建规则。
在项目的根目录创建该文件，并写入：
技巧
这是一个最简单的 Meson 配置，读者应根据实际情况进行调整。
然后同理，在 .vscode 文件夹下创建 launch.json 和 tasks.json 文件。
在 launch.json 写入：
在 tasks.json 写入：
使用 CLion 开发 C/C++
安装 CLion
使用 pkg 安装：
或者使用 ports 构建：
配置 CLion
由于 CLion 使用 CMake，所以使用方法相较于 VSCode 更简单，只需正确配置 CMakeLists.txt 即可（可参照上文 VSCode 的配置），不再赘述。
注意
在 FreeBSD 上使用 CLion 进行 C/C++ 的开发，如果不是特殊情况，尽量使用 gcc 和 gdb 套件以避免一些错误。
故障排除
需要注意的是，从 FreeBSD 软件源获取来的 CLion 可能无法正常打开，会报错如下：
要修复这个问题，就得编辑 CLion 的 /usr/local/share/jetbrains/clion/plugins/plugin-classpath.txt 文件：
然后把里面开头的乱码删除即可（删至 <idea-plugin 作为开头），重启 CLion 后可正常进入软件。参见 Bug 290663 - devel/jetbrains-clion: fails to start。
使用 Zed 开发 C/C++
安装 Zed
使用 pkg 安装:
或者使用 ports 构建：
配置 Zed
Zed 的调试功能主要基于调试适配器协议（Debug Adapter Protocol，DAP）实现，并默认依赖特定的调试适配器，例如 CodeLLDB（用于 LLDB 后端）或 GDB，以支持包括 Rust、C/C++ 在内的多种语言的调试。CodeLLDB 作为主要的 LLDB DAP 适配器，其官方支持平台仅限于 Linux、macOS 和 Windows，未包含 FreeBSD 或其他 BSD 变体。这导致在 FreeBSD 环境下，CodeLLDB 调试路径默认不可用，从而使 Zed 的内置调试功能受到显著限制。
Zed 本身支持 LLDB 作为调试后端（例如在调试 Zed 自身源码时可通过 rust-lldb 进行），但其通用调试系统严格依赖 DAP 协议，而非 LLDB 的 Machine Interface（MI）接口（如 LLDB-MI）。因此，直接集成 LLDB-MI 并非 Zed 的标准支持方式。若需使用 LLDB，必须通过兼容的 DAP 适配器（如 CodeLLDB 或官方 lldb-dap）实现，而这些适配器在 FreeBSD 上要么缺乏官方支持，要么存在兼容性问题。
理论上，可尝试通过 Zed 的扩展系统配置其他 DAP 适配器以实现调试支持，但 FreeBSD 并非 Zed 的官方支持平台，社区维护的 Ports 版本在调试功能上可能存在不稳定性或缺失部分依赖。因此，在 FreeBSD 环境下，即使 GDB 调试能够在 Zed 中运行，其行为本质上与在终端直接使用 GDB 相同，仅通过 Zed 的图形界面进行封装，仍需依赖手动输入命令。
基于上述情况，在当前阶段，建议将 Zed 定位为纯粹的代码编辑器，主要用于编码、文本编辑和高性能的界面体验，而将程序的构建、运行及调试工作交由命令行工具（如 clang、ninja、lldb、gdb）或其他专用调试前端完成。若未来 Zed 项目或社区扩展对 FreeBSD 的调试支持得到完善，则可重新评估其作为完整开发环境的适用性。
故障排除与未竟事宜
思考题
本文介绍的开发方法主要围绕编译器、调试器以及基础的构建工具展开，并未将 NeoVim、Emacs 等高度可定制化的编辑器作为核心推荐。
这些工具的功能和配置方式在本书其他章节中已有简要说明，可供参考。
然而，每个开发者的学习习惯和目标各不相同：
你是否认为投入大量时间配置和美化编辑器，能够实质性地提升你的编码能力或学习效率？
在初学阶段，将精力集中于理解语言特性、系统接口和调试技巧，与沉浸于工具定制之间，你更倾向于如何权衡？
有人将深度定制工具链视为一种“苦难哲学”（即以复杂配置为荣），你认为这种观点是否适用于你自己的学习路径？
请根据自身的实际需求和长期目标，审慎选择适合的开发环境与工作流程。
最后更新于