vscode tasks.json配置

今天在使用vscode时，需要对多个.c文件进行编译调试，才发现以前只会在vscode中进行单个.c文件的编译调试。这部分内容涉及vscode 中tasks.json文件的配置，遂有本文。

认识tasks.json

tasks.json 文件在 VSCode 中用于定义和配置任务，例如编译代码、运行脚本或执行测试。它允许用户自定义自动化流程，以便在开发过程中提高效率。

配置tasks.json

在默认情况下vscode的针对c程序的tasks.json文件内容如下：（加注释版本）

{
    "tasks": [
        {
            "type": "cppbuild", // 任务类型，表示这是一个 C/C++ 构建任务
            "label": "C/C++: gcc.exe 生成活动文件", // 任务标签，用于在任务列表中标识此任务
            "command": "D:\\ProgramData\\mingw64\\bin\\gcc.exe", // 要执行的命令，这里是 GCC 编译器的路径
            "args": [ // 传递给命令的参数列表
                "-fdiagnostics-color=always", // 始终启用诊断信息的颜色输出
                "-g", // 生成调试信息
                "${file}", // 当前活动文件的路径
                "-o", // 指定输出文件的选项
                "${fileDirname}\\${fileBasenameNoExtension}.exe" // 输出文件的路径和名称（与源文件同名但扩展名为 .exe）
            ],
            "options": {
                "cwd": "${fileDirname}" // 设置命令执行的当前工作目录为当前文件所在的目录
            },
            "problemMatcher": [
                "$gcc" // 使用 GCC 的问题匹配器来解析编译输出中的错误和警告
            ],
            "group": {
                "kind": "build", // 任务组的类型，这里是构建任务
                "isDefault": true // 是否为默认任务
            },
            "detail": "调试器生成的任务。" // 任务的详细描述
        }
    ],
    "version": "2.0.0" // 任务配置文件的版本
}

以以上的内容来说，它将你编译生成c程序的内容写成一个自动化脚本，只要根据脚本中的内容执行，就能将.c文件编译成exe程序

认识 label

"label": "C/C++: gcc.exe 生成活动文件"

label 设置的是任务标签，用于在任务列表中标识此任务。单单这样一句话可能任然让你比较迷惑，不知道这个标签的意义是什么。所以我们来实际找到一下它看看：

我们先点击右上角的设置符号，然后查看通过gcc.exe那一个选项，注意查看黄色狂出的小字，preLaunchTask:表示执行这个任务的前置任务为：C/C++:gcc.exe 生成活动文件 是不是与label标签的内容一模一样，尝试更改tasks.json中的label内容：为test

注意这里 preLaunchTask:的内容变为test了。

认识command

"command": "D:\\ProgramData\\mingw64\\bin\\gcc.exe" 这句话的作用是在定位gcc编辑器。因为我们是通过gcc来编译运行我们的.c文件，所以vscode需要知道gcc在哪里，接下看来的指令需要输给哪个程序来执行。

我们照样按照路径打开文件夹来看看：

gcc果然就在对应的路径下。

认识args

"args": [ // 传递给命令的参数列表
                "-fdiagnostics-color=always",
                "-g", 
                "${file}", 
                "-o", 
                "${fileDirname}\\${fileBasenameNoExtension}.exe" 
            ],

在 tasks.json 中，"args" 是一个数组，包含要传递给命令（在这里是 GCC 编译器）的参数。这些参数决定了编译器如何处理源文件，并控制编译过程的行为。总结一下，args中的内容就是我们要在gcc中输入的指令。这里相当于自动套公式来完成这一步骤。而这里的公式就相当是：${file} ${fileDirname} ${fileBasenameNoExtension}

为什么能这么写？

VSCode 支持使用变量替换机制，在任务配置文件（如 tasks.json）或其他配置文件中，可以使用 ${} 的形式来引用当前工作空间或编辑器的一些动态值。VSCode 会在任务运行时将这些变量替换为实际的值。

常用的VSCode变量

• ${file}：当前活动文件的完整路径（包含文件名和扩展名）。
• ${fileDirname}：当前文件所在的目录路径。
• ${fileBasename}：当前文件的文件名（包含扩展名，不包含路径）。
• ${fileBasenameNoExtension}：当前文件的文件名（不包含扩展名）。
• ${workspaceFolder}：当前工作区的根目录。
• ${workspaceFolderBasename}：工作区文件夹的名称。
• ${relativeFile}：当前文件相对于工作区根目录的相对路径。
• ${lineNumber}：当前文件中光标所在的行号。
• ${selectedText}：当前文件中选中的文本。

假设你正在编辑文件 C:\Projects\myprogram.c，那么：

• ${file} 会被替换为 C:\Projects\myprogram.c。
• ${fileDirname} 会被替换为 C:\Projects。
• ${fileBasename} 会被替换为 myprogram.c。
• ${fileBasenameNoExtension} 会被替换为 myprogram。

认识options

"options": {
                "cwd": "${fileDirname}"
            },

的意思是为任务执行设置 当前工作目录 （cwd），也就是执行命令时所在的目录。具体来说：

• options ：表示为任务执行配置一些选项。
• cwd ：这是 “current working directory” 的缩写，表示执行命令时的当前工作目录。这里它被设置为 ${fileDirname}。

当然options除了设置cwd外，还有很多其他可以设置的选项，我们来逐一了解一下。

env - 环境变量

允许为任务指定自定义的环境变量，这些变量在任务运行时会被添加到系统的环境变量中。

"env": {
  "MY_CUSTOM_VARIABLE": "value",
  "ANOTHER_VARIABLE": "anotherValue"
}

作用 ：添加、覆盖或修改环境变量，可以影响任务执行过程中的系统行为（如命令查找、路径查找等）。

shell - 自定义 Shell

允许为任务指定使用哪个 Shell 来运行命令。

"shell": {
  "executable": "path/to/shell",
  "args": ["arg1", "arg2"]
}

作用 ：可以自定义执行命令时所使用的 Shell 程序，例如默认是 cmd，你可以改用 bash、PowerShell 等。

shellArgs - Shell 参数

"options": {
  "shell": {
    "executable": "/bin/bash"
  },
  "shellArgs": ["-l", "-i"]
}

让你可以更加灵活地控制 Shell 的行为。

windows、osx、linux - 平台特定选项

options 字段支持按操作系统分别配置不同的选项，这对于跨平台开发非常有用。

"windows": {
  "env": {
    "MY_VAR": "WindowsValue"
  }
},
"osx": {
  "env": {
    "MY_VAR": "MacValue"
  }
},
"linux": {
  "env": {
    "MY_VAR": "LinuxValue"
  }
}

允许在不同操作系统上针对性的配置任务，增强跨平台的兼容性。

timeout - 超时时间

用于设置任务运行的最大时间（以毫秒为单位）。如果任务超时，会被强制终止。

"timeout": 10000 // 设置任务的超时时间为 10 秒

控制任务的运行时间，避免某些任务因意外情况而卡住。

detached - 后台任务

设置为 true 时，任务会作为后台任务运行，不会阻塞其他任务或终端。

"detached": true

作用 ：允许任务在后台独立运行，通常用于守护进程类任务。

appendPath - 是否将工作目录添加到系统路径中

设置为 true 时，会将当前工作目录 (cwd) 添加到系统的 PATH 环境变量中。

"appendPath": true

作用 ：确保在执行任务时，可以从当前目录找到可执行文件，而无需显式提供路径。

认识problemMatcher

"problemMatcher": [
                "$gcc" // 使用 GCC 的问题匹配器来解析编译输出中的错误和警告
            ]

"problemMatcher" 是 VSCode 中的一种配置，用于定义如何解析命令输出中的错误和警告信息。

作用

1. 错误和警告识别 ：

• problemMatcher 允许 VSCode 识别编译或运行任务中的错误和警告信息，并将其解析为可点击的条目。这样，开发者可以快速定位到源代码中的具体问题。

1. 提供反馈 ：

• 当你执行编译任务时，如果存在错误或警告，VSCode 会在 “问题” 面板中显示这些信息，并提供相关的文件和行号，方便你快速修复代码。

我们注意到，"problemMatcher" 是一个数组，你可以添加多个问题匹配器。这样，任务的输出可以根据多个工具或编译器的不同格式来解析。

内置的常用问题匹配器

VSCode 提供了许多内置的标准问题匹配器，用于各种编译器、构建工具和代码检查工具。以下是一些常用的内置问题匹配器：

1. $gcc ：用于解析 GCC 编译器的输出。
2. $g++ ：用于解析 G++ 编译器的输出。
3. $tsc ：用于 TypeScript 编译器 (tsc) 输出。
4. $eslint ：用于解析 ESLint（JavaScript 和 TypeScript 的静态分析工具）的输出。
5. $msCompile ：用于解析 MSVC（微软 C++ 编译器）的输出。
6. $jshint ：用于解析 JSHint（JavaScript 静态代码检查工具）的输出。
7. $go ：用于解析 Go 编译器的输出。
8. $rustc ：用于解析 Rust 编译器的输出。
9. $pylint ：用于解析 Pylint（Python 静态代码分析工具）的输出。

同时problemMathcer支持自定义的问题匹配器，这里先不再深入。

认识group

"group": {
                "kind": "build", // 任务组的类型，这里是构建任务
                "isDefault": true // 是否为默认任务
            },

"group" 字段在 tasks.json 中用于将任务分组，这样你可以更好地组织和管理任务。通过对任务分组，你可以指定任务的类型和它们的执行方式，还能通过 VSCode 的快捷方式或菜单更方便地执行这些任务。

group 配置选项

1. kind ：定义任务的类别（类型）。VSCode 支持以下几种预定义的任务组：

• build ：表示这是一个 构建任务 ，通常用于编译代码。
• test ：表示这是一个 测试任务 ，通常用于运行单元测试或其他类型的测试。
• none ：表示该任务不属于任何特定的组，不会被 VSCode 标记为构建或测试任务。

2. isDefault ：是否为该组中的 默认任务 。设置 isDefault: true，表示这是该组中的默认任务，用户可以通过快捷方式执行该任务。

• 如果设置为 true，当你通过快捷键或菜单触发构建或测试操作时，VSCode 会默认执行这个任务。
• 例如：按 Ctrl + Shift + B（Windows/Linux）或 Cmd + Shift + B（Mac）快捷键执行默认的构建任务。

我们来看看这两个选项的效果：

kind选项

bulid组

为方便看kind选项的效果，我们先将isDefault 设置为false。

我们按 Ctrl + Shift + B 让vscode执行构建任务，就是编译、打包、生成可执行文件、或执行其他构建相关操作的任务。

我们可以看到三个选项，其中一个就是我们修改的tesk.json，由于我之前将其改名为test方便区分，点击它，就会按照我们之前的配置生成可执行文件，但是不会运行。

test组

打开命令面板（Ctrl + Shift + P），输入并选择 Tasks: Run Test Task 。

由于我们现在还没有设置test组，所以没有选项：

我们将tasks.json中的build修改为tast后,我们再次打开，即可看见：

test与build的区别

1. 目标与执行内容不同

• build 组 ：用于编译、打包、生成可执行文件或构建项目的任务。这是开发流程中的一个关键步骤，通常用于将源代码转换为可运行的形式。
• 典型任务：编译代码（如 C/C++ 编译）、打包应用程序、链接库等。
• 例子 ：
  • 在 C/C++ 项目中，运行 gcc 或 g++ 编译代码。
  • 在 Java 项目中，运行 javac 编译 Java 文件。
  • 在 JavaScript 项目中，运行 npm run build 生成打包文件。
• test 组 ：用于运行各种测试任务，确保代码的正确性。它是质量保证流程中的一部分，常常在编译/构建完成之后执行，用于验证构建出来的项目是否正确运行，或检查功能是否符合预期。
• 典型任务：运行单元测试、集成测试、功能测试等。
• 例子 ：
  • 在 JavaScript 项目中，运行 npm test 执行测试（使用 Jest、Mocha 等）。
  • 在 Python 项目中，运行 pytest 或 unittest 进行测试。
  • 在 Java 项目中，运行 mvn test 或 gradle test 来执行 JUnit 测试。

2. 开发流程中的角色不同

• 构建任务（build 组） ：通常是开发流程中的 第一步 ，用于将源代码转换为可执行的应用程序或库文件。没有构建就没有产品，构建任务往往是整个开发流程中的基础。
• 测试任务（test 组） ：是开发流程中的 验证步骤 ，用于确保在构建完成后，项目的功能符合预期并且没有引入错误。测试任务主要关注代码的质量和正确性，尤其是在持续集成或发布前阶段，测试任务是关键的一环。

3. 默认快捷方式与执行方式不同

• build 组 ：
• 默认的构建任务通常通过快捷键 Ctrl + Shift + B（Windows/Linux）或 Cmd + Shift + B（Mac）来执行。
• 构建任务主要用于生成项目的最终产品。
• test 组 ：
• 默认的测试任务通常通过 Tasks: Run Test Task 命令或快捷键 Ctrl + Shift + T（Windows/Linux）或 Cmd + Shift + T（Mac）来执行。
• 测试任务用来验证项目的代码质量。

4. 为何要分开

5. 职责明确 ：

• 构建任务的目标是生成项目的最终产品，因此它专注于如何从源代码生成可运行或可发布的文件。
• 测试任务的目标是验证代码的正确性和质量，确保构建出来的产品在功能上是正确的。
• 将两者分开，可以让每个任务专注于其独特的职责，避免混乱。

1. 灵活性 ：

• 开发者可以独立运行构建任务或测试任务，而无需强制执行另一个步骤。例如，开发者可能只想验证某个功能测试，而不需要每次都重新编译整个项目。
• 分开后，可以更加灵活地控制开发流程，按需选择是要构建、测试，还是同时执行。

1. 自动化工作流 ：

• 在持续集成（CI）或持续交付（CD）流程中，构建和测试是两个不同的阶段：
  • 构建阶段 ：生成代码的可执行版本。
  • 测试阶段 ：验证代码的正确性。
• 将任务分开有助于自动化工具（如 Jenkins、GitLab CI）清晰地识别每个阶段的任务，确保整个开发工作流的顺利执行。

1. 提高效率 ：

• 在开发中，频繁的构建和测试可能导致重复的无效操作。将构建与测试任务分开后，开发者可以根据需要只运行测试任务或只运行构建任务，避免重复的编译过程。
• 这有助于节省时间，提高开发效率。

5. 总结

• build 组专注于 生成产品 ，其目的是将源代码编译、打包为可执行文件。
• test 组专注于 验证产品的质量 ，目的是确保代码在构建后按预期运行。
• 两者分开有助于提高开发流程的清晰性、灵活性和效率，确保每个步骤都有明确的职责并可以独立运行。

isDefault

是否为该组中的 默认任务 。设置 isDefault: true，表示这是该组中的默认任务，用户可以通过快捷方式执行该任务。

在kind中的演示我们都是在 isDefault: false的选项下进行的，若设置某一个task为build中的default，那么当你按下Ctrl + Shift + B时，不会弹出子选项，而是直接运行默认的task，简化了流程。

认识detail

"detail": "调试器生成的任务。" 在 tasks.json 文件中的作用是提供关于任务的 详细描述 。这个字段的内容通常不会影响任务的执行逻辑或行为，但它可以帮助开发者和其他使用者更好地理解任务的用途和背景。