概述
虽然我这里使用CMake，但是它只是一个用于编译生成可执行文件的工具，完全不影响将工具换成g++，gcc等，这套配置是完全通用的
- 右上角一键编译运行的内部流程
- task.json格式概述
- launch.json格式概述
- CMake格式概述
- 攒起来，组合成通用开发环境
一键编译运行的内部流程
- 点击
运行 C/C++ 文件(或按下F5) - vscode调用launch.json挑选调试器、根据参数配置运行环境
- 调用task.json生成可执行文件
- 启动调试器，加载用task.json生成的可执行文件
- 开始调试
task.json格式概述
- 举例
{
"label": "CMake: Build",
"type": "shell",
"command": "cmake",
"args": ["../"],
"options": {
"cwd": "${workspaceFolder}/build"
},
"dependsOn": ["create"]
},
概述
- task.json中，在 “tasks”: [ ] 方括号中的，每一组用 { } 括起来“东西”，都是一个task，也是这个文件真正要去执行的事
- 将一系列task组合起来，就可以实现一个完整的目标（有点类似于shell脚本，只不过shell以指令为单位，task.json以任务为单位）
具体变量解释
- “label” 表示当前任务的名称，
- “type” 表示当前任务的类型，不同类型对应了该任务不同的执行的方式
- “shell”，在终端执行；
- “process”，在一个新的进程中直接执行，常用于避免 shell 特定的行为或环境变量影响
- “customExecution”，使用一个扩展来提供自定义的任务执行逻辑
- “npm”，专门用于执行 npm 脚本
- “command” 表示执行时要使用的指令
- “args” 表示执行指令时要输入的参数
- “cwd” 表示执行该任务的目录
- “dependsOn” 表示该任务依赖于其他什么任务，填入需要在此之前执行完的任务名称
完整task.json
实现了一个完整的清除build，重新编译生成的全流程
{
"version": "2.0.0",
"tasks": [
{
"label": "clean",
"type": "shell",
"command": "rm",
"args": ["-r", "build"],
"options": {
"cwd": "${workspaceFolder}"
}
},
{
"label": "create",
"type": "shell",
"command": "mkdir",
"args": ["build"],
"options": {
"cwd": "${workspaceFolder}"
},
"dependsOn": ["clean"]
},
{
"label": "CMake: Build",
"type": "shell",
"command": "cmake",
"args": ["../"],
"options": {
"cwd": "${workspaceFolder}/build"
},
"dependsOn": ["create"]
},
{
"label": "make",
"type": "shell",
"command": "make",
"args": [],
"options": {
"cwd": "${workspaceFolder}/build"
},
"dependsOn": ["CMake: Build"] // make 依赖 CMake 生成 Makefile
},
{
"label": "build",
"dependsOn": ["clean", "create", "CMake: Build", "make"],
"dependsOrder": "sequence"
}
]
}
- 重点解释build任务
- 相当于将之前的所有任务都攒起来，变成一个完整的处理流程，launch只需要调用这个build任务，就可以完成一次清理并重建
- 最后一个属性"dependsOrder": “sequence”，指定了依赖任务的执行顺序。表示所有前置任务将按照它们在 “dependsOn” 数组中出现的顺序依次执行。
launch.json格式概述
{
"version": "0.2.0",
"configurations": [
{
"name": "CMake Debug",
"type": "cppdbg",
"request": "launch",
"program": "${fileDirname}/build/bsp",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
"miDebuggerPath": "/usr/bin/gdb",
"preLaunchTask": "build"
}
]
}
概述
launch很简单，只干三件事：
- 定义如何启动调试器（GDB）
- 调试前的构建任务（preLaunchTask）
- 调试目标程序的位置
具体变量解释
name:"CMake Debug"
作用: 调试配置的名称，显示在 VS Code 调试器下拉列表中。type:"cppdbg"
作用: 指定调试器类型为 C++ Debuggerrequest:"launch"
作用: 表示启动一个新的程序进行调试（而非附加到已运行的进程）。program:"${fileDirname}/build/bsp"
作用: 指定要调试的可执行文件路径。stopAtEntry:false
作用: 是否在程序入口（如main函数）自动暂停。设为false表示直接运行程序。cwd:"${workspaceFolder}"
作用: 调试程序的工作目录，此处设为工作区根目录。影响程序的文件读写路径（如相对路径的文件访问）。externalConsole:false
作用: 是否在外部系统终端中运行程序。设为false表示使用 VS Code 内置终端。MIMode:"gdb"
作用: 指定底层调试器为 GDB（GNU Debugger）。setupCommands
作用: 调试器启动时执行的初始化命令。通常我们不需要反汇编的，将自动生成的反汇编部分删除即可text: 向 GDB 发送-enable-pretty-printing命令，启用结构化数据（如 STL 容器）的友好显示。ignoreFailures: 即使命令执行失败，也不终止调试会话。
miDebuggerPath:"/usr/bin/gdb"
作用: 显式指定 GDB 的路径。缺省时，VS Code 会从系统环境变量中查找 GDB。preLaunchTask:"build"
作用: 在启动调试前自动执行tasks.json中定义的build任务（如编译代码）。在上面的task.json中已经着重介绍过build任务了。
CMake格式概述
CMake本质就是告诉编译器如何编译（生成makefile）
无非就是用相对简单的方式，管理结构比较复杂的程序，然后在不同平台的兼容性上相对好一些，和c_cpp_properties.json几乎是一样的功能
# 设置 CMake 最低版本要求
cmake_minimum_required(VERSION 3.10)
# 设置项目名称和编程语言
project(BSP_Project C)
# 添加头文件目录
include_directories(${CMAKE_SOURCE_DIR})
# 设置可执行文件输出目录（可选）
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_SOURCE_DIR}/build)
# 添加可执行文件
add_executable(bsp # 生成的可执行文件的名称
main.c # 两个用于生成可执行文件的源文件
bsp.c
)
target_include_directories(bsp PUBLIC ${CMAKE_SOURCE_DIR})
需要注意的是，生成的可执行文件名称，一定要和launch中的program对应，不然launch会找不到它