概述
虽然我这里使用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++ Debugger -
request:"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会找不到它