在 Debian 上做 C++ 开发，真正让人卡住的通常不是写代码，而是工具链怎么配、构建方式怎么选、项目做大后该不该切到 CMake。把这些环节拆开看，其实每一步都很明确：先把编译环境装齐，再根据项目体量决定构建方案，最后补上调试和打包。看完这篇，你可以快速判断自己的项目该停留在 g++ 命令行、升级到 Makefile，还是直接采用 CMake。
准备 Debian 下的 C++ 开发环境
在 Debian 系统上开始一个 C++ 项目，第一步是把基础工具链装好。最核心的是 build-essential，它通常包含 g++、make 等常用组件，足够支撑基础编译与构建流程。
sudo apt update
sudo apt install build-essential
如果你后面需要排查崩溃、断点跟踪或查看变量值，建议一并安装 gdb：
sudo apt install gdb
而对于采用 CMake 管理的项目，还要安装 cmake：
sudo apt install cmake
这套环境覆盖了从单文件练手程序到多模块工程的大部分场景。换句话说，只要这一步准备完整，后续无论是手动编译还是接入自动化构建，都不需要再回头补基础依赖。
先写代码，也要顺手把目录结构想清楚
环境就绪后，就可以创建项目目录和源文件。最简单的例子仍然是一个标准的 Hello World 程序：
#include
int main() {
std::cout << "Hello, Debian C++ Project!" << std::endl;
return 0;
}
这个示例很小，但它适合用来验证编译器、运行环境和后续构建配置是否正常。如果这一步能顺利编译并输出结果，说明你的开发链路已经通了。
不过，真正做项目时，别把所有代码都塞进一个文件里。随着逻辑变多，最好尽早把源文件和头文件拆分开，例如把业务代码放到 src/main.cpp、src/utils.cpp，把声明放进 include/utils.h。这样做的价值不只是“看起来整齐”，更关键的是便于增量编译、团队协作和后续接入 Makefile 或 CMake。
构建方式怎么选：g++、Makefile 还是 CMake
Debian 上的 C++ 构建没有唯一标准答案，关键看项目规模和维护成本。小程序可以直接用 g++，文件多了以后就该交给 Makefile，而一旦项目需要跨平台、依赖第三方库或团队协作，CMake 往往更合适。
手动编译：适合小型程序和快速验证
如果你只是写一个一两百行的小程序，直接调用 g++ 往往是最快的办法：
g++ -o hello main.cpp
如果希望开启警告并使用 C++11 标准，可以把参数写完整一些：
g++ -Wall -std=c++11 -o hello main.cpp
编译通过后，直接运行生成的可执行文件：
./hello
这种方式的优点是门槛低、反馈快，特别适合验证示例代码、测试一个最小功能或排查某个单文件问题。缺点也很明显：一旦源文件变多，每次修改后都要手动重复输入编译命令，效率会迅速下降。
Makefile：适合中型项目的自动化构建
当项目里已经有多个源文件，或者你不想每次都手敲编译参数时，Makefile 就能派上用场。它的核心价值是把“如何编译”写成规则，让 make 自动判断哪些文件需要重新编译。
下面是一个基础的 Makefile 示例：
# 定义编译器和选项
CXX = g++
CXXFLAGS = -Wall -std=c++11
# 目标可执行文件名
TARGET = hello
# 源文件列表
SOURCES = main.cpp
# 对象文件列表（将.cpp替换为.o）
OBJECTS = $(SOURCES:.cpp=.o)
# 默认目标：生成可执行文件
all: $(TARGET)
# 链接目标文件生成可执行文件
$(TARGET): $(OBJECTS)
$(CXX) $(CXXFLAGS) -o $@ $^
# 编译每个源文件为目标文件
%.o: %.cpp
$(CXX) $(CXXFLAGS) -c $< -o $@
# 清理生成的文件
clean:
rm -f $(OBJECTS) $(TARGET)
写好之后，在项目根目录执行：
make
如果需要清理中间文件和生成物，则执行：
make clean
对于源文件数量不算特别夸张、依赖关系也相对可控的中型项目，Makefile 依然是很实用的方案。它比手动编译稳定，也不需要引入额外一层构建描述工具。
CMake：适合大型工程、第三方库和跨平台场景
如果项目规模继续扩大，或者你需要在 Debian 之外兼顾别的系统，CMake 通常是更稳妥的选择。它不是直接负责编译，而是通过 CMakeLists.txt 描述项目，然后生成 Makefile 或其他构建脚本。
一个典型的项目结构可以写成这样：
MyProject/
├── CMakeLists.txt # CMake配置文件
├── main.cpp # 主源文件
└── include/ # 头文件目录（可选）
└── utils.h # 头文件（可选）
对应的 CMakeLists.txt 可以从最小配置开始：
# 设置最低CMake版本要求
cmake_minimum_required(VERSION 3.10)
# 定义项目名称和版本
project(MyProject VERSION 1.0 LANGUAGES CXX)
# 设置C++标准（强制使用C++11）
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED True)
# 添加可执行文件，指定源文件
add_executable(MyExecutable main.cpp)
# 若有多个源文件，可通过aux_source_directory获取
# aux_source_directory(src SRCS)
# add_executable(MyExecutable ${SRCS})
# 若使用外部库，可通过find_package查找并链接
# find_package(OpenCV REQUIRED)
# target_link_libraries(MyExecutable ${OpenCV_LIBS})
然后在单独的构建目录中执行生成和编译：
mkdir build
cd build
cmake ..
make
构建完成后，生成的可执行文件位于 build 目录下，运行方式如下：
./MyExecutable
CMake 的实际优势主要体现在三个方面。第一，源码目录和构建目录分离，清理构建产物时不容易污染源码树；第二，项目接入外部依赖时可以借助 find_package 组织得更清楚；第三，跨平台迁移时通常只需要调整少量配置，而不用重写整套构建逻辑。
编译通过后，怎么测试和调试
构建成功不代表程序一定没问题，最基本的检查就是直接运行生成的可执行文件。不同构建方式对应的启动命令如下：
./hello # 手动编译或Makefile生成的可执行文件
./MyExecutable # CMake生成的可执行文件
如果结果不符合预期，或者程序在运行中崩溃，就该进入调试环节。使用 gdb 之前，先在编译时加入 -g 选项，把调试信息写进可执行文件：
g++ -g -o hello main.cpp # 编译时添加调试信息
gdb ./hello # 启动调试
(gdb) break main # 在main函数处设置断点
(gdb) run # 运行程序
(gdb) next # 单步执行
(gdb) print variable # 查看变量值
这套命令已经覆盖了最常见的排错起点：能不能停在入口、能不能逐步执行、能不能观察变量。如果这些基本动作都掌握了，很多入门阶段的逻辑错误都能自己定位出来，而不必反复依赖打印日志。
需要分发给别人时，再考虑打包成 .deb
如果项目只在本机运行，到这里其实已经够用了。但如果你需要把程序交付给其他 Debian 或 Ubuntu 用户，打包成 .deb 会更省事，安装和卸载都更符合系统习惯。
先准备 Debian 安装包目录结构
myprogram/
├── DEBIAN/ # 存放控制文件
│ └── control # 控制文件（描述包信息）
└── usr/local/bin/ # 存放可执行文件
└── myprogram # 编译后的可执行文件
这里的重点是两部分：DEBIAN/control 用来描述包的元数据，usr/local/bin/ 则放最终交付给用户的可执行文件。
控制文件里至少要写清这些信息
Package: myprogram
Version: 1.0
Section: utils
Priority: optional
Architecture: amd64
Maintainer: Your Name
Description: A simple C++ program that outputs "Hello, World!".
其中 Package、Version、Architecture 这些字段直接关系到包的识别和安装行为，最好从一开始就命名清楚，避免后续升级或发布时混乱。
编译程序并生成 .deb 安装包
# 编译程序（假设main.cpp在项目根目录）
g++ -o myprogram main.cpp
# 创建目录结构
mkdir -p myprogram/usr/local/bin
# 复制可执行文件
cp myprogram myprogram/usr/local/bin/
# 打包
dpkg-deb --build myprogram
执行完成后，会得到一个 myprogram.deb 文件。用户安装时可以这样操作：
sudo dpkg -i myprogram.deb
后续如果需要卸载，也可以使用 dpkg -r。这意味着你的 C++ 程序不再只是“能跑的二进制文件”，而是一个可以按 Debian 习惯安装、管理和移除的软件包。
一条够用的 Debian C++ 构建路径
把整个流程串起来看，Debian 下的 C++ 项目开发其实就是四个关键判断：工具链是否装齐，代码结构是否适合扩展，构建方式是否匹配项目规模，交付阶段是否需要标准化打包。小程序用 g++ 就能完成验证，中型项目引入 Makefile 能减少重复劳动，而大型或跨平台工程则更适合从一开始就使用 CMake。
对于大多数开发者来说，先把这条主链路走通，比一开始追求复杂的工程体系更重要。等你真的遇到团队协作、第三方依赖、持续集成或发布分发需求时，再往这套流程上叠加单元测试、版本控制和 CI/CD，会更顺手也更稳妥。
