cargo make --env ENV1=VALUE1 --env ENV2=VALUE2 -e ENV3=VALUE3

环境文件

也可以在 CLI 参数中提供环境文件路径，如下所示

cargo make --env-file=./env/production.env

这允许使用相同的 Makefile.toml，但使用从环境文件加载的不同环境变量集。

环境文件是一个简单的 key=value，类似于 dotenv，但只支持使用 ${} 语法进行变量插值。

#just a comment...
ENV1_TEST=TEST1
ENV2_TEST=TEST2
ENV3_TEST=VALUE OF ENV2 IS: ${ENV2_TEST}

可以在 Makefile.toml 的 env_files 键中全局定义环境文件路径，它们将按定义的顺序加载。所有相对路径都是相对于定义它们的 Makefile.toml 所在目录的相对路径。

注意： env_files 也可以在任务级别上使用。请注意，相对路径将相对于 当前工作目录。

env_files = [
    "./env1.env",
    "./env2.env"
]

要仅在变量尚未定义时加载环境变量，请使用 defaults_only 属性。

env_files = [
    { path = "./load_only_undefined.env", defaults_only = true },
    { path = "./load_all.env" }
]

使用 profile 属性仅在特定配置文件活动时加载环境变量。

要了解更多关于配置文件的信息，请查看 配置文件部分。

env_files = [
    { path = "./profile.env", profile = "development" },
    { path = "./env.env" }
]

环境设置脚本

环境设置脚本在环境文件和 env 块之后调用。它们由 env_scripts 属性全局定义。这些脚本可以在启动流程之前运行任何需要的操作。

对于由嵌入式运行时调用的 duckscript 脚本，可以直接修改 cargo-make 运行时环境变量。

例如

env_scripts = [
'''
#!@duckscript
echo first env script...

composite_env_value = get_env COMPOSITE
echo COMPOSITE = ${composite_env_value}

set_env COMPOSITE_2 ${composite_env_value}
''',
'''
#!@duckscript
echo second env script...

composite_env_value = get_env COMPOSITE_2
echo COMPOSITE_2 = ${composite_env_value}
'''
]

[env]
SIMPLE = "SIMPLE VALUE"
SCRIPT = { script = ["echo SCRIPT VALUE"] }
COMPOSITE = "simple value: ${SIMPLE} script value: ${SCRIPT}"

在这个例子中，由于 env 块在 env 脚本之前调用，所以 duckscript 可以访问 COMPOSITE 环境变量。
这些脚本使用该值创建一个新的环境变量 COMPOSITE_2，并在第二个脚本中打印它。

加载顺序

cargo-make 将按以下顺序加载环境变量

• 加载命令行提供的环境文件
• 设置内部环境变量（见 全局 部分）。**不包括任务特定变量**。
• 加载在 env_files 属性中定义的全局环境文件。
• 加载命令行提供的全局环境变量。
• 根据配置文件/附加配置文件加载在 env 块和相关的子 env 块中定义的全局环境变量。
• 加载在 env.[当前配置文件] 块中定义的全局环境变量。
• 加载在 env_scripts 属性中定义的全局环境设置脚本。
• 任务特定
  • 加载在 env_files 属性中定义的环境文件（相对于全局 env_files 处理方式不同）。
  • 设置 任务特定 内部环境变量（见 全局 部分）。
  • 加载在 env 块中定义的环境变量（与全局 env 块的行为相同）。

在每一步中，可以根据需要重新排序变量以确保指定所有依赖关系。环境变量将在每个任务运行之前进行插值。

关于顺序的说明

cargo-make 中环境变量的顺序在定义和评估之间不一定相同。相反，cargo-make 会查看值并根据提到的变量重新排序变量。

这种行为具有许多优点，例如可以自由地引用其他变量或在不同作用域中重新定义它们。

[env]
VAR1="${VAR2}"
VAR2=2

一种简单的实现可能会导致以下结果：VAR1=""，VAR2=2，这种行为可能会非常意外，尤其是在扩展环境变量的现有声明时。与 cargo-make 不同，它使用类似于 terraform 这样的工具的方法，它会识别出 VAR1 依赖于 VAR2，这将输出 VAR1=2，VAR2=2。

[env]
VAR1="${VAR2}"

[env.prod]
VAR2=2

[env.devel]
VAR2=3

这是一个扩展的例子，由于不同的配置文件与环境（基本上是追加）合并，所以简单的实现无法工作。然而，与 cargo-make 不同，它将识别依赖关系并正确解决所有值。

简单实现

--release=test
    VAR1=""
--release=prod
    VAR1=""
    VAR2=2
--release=devel
    VAR1=""
    VAR2=3

cargo-make 实现

--release=test
    VAR1=""
--release=prod
    VAR1="2"
    VAR2=2
--release=devel
    VAR1="3"
    VAR2=3

全局

除了手动设置环境变量外，cargo-make 还会自动添加一些环境变量，这在使用任务脚本、命令、条件等时可能很有帮助。

• CARGO_MAKE - 设置为 "true" 以帮助子进程识别它们正在从 cargo make 运行。
• CARGO_MAKE_TASK - 存储正在执行的主要任务名称。
• CARGO_MAKE_TASK_ARGS - 在任务名称之后提供的参数列表，参数之间用分号字符分隔。
• CARGO_MAKE_CURRENT_TASK_NAME - 存储当前正在执行的任务名称。
• CARGO_MAKE_CURRENT_TASK_INITIAL_MAKEFILE - 存储最初定义当前正在执行的任务的 makefile 的完整路径（对于内部核心任务不可用）。
• CARGO_MAKE_CURRENT_TASK_INITIAL_MAKEFILE_DIRECTORY - 存储包含最初定义当前正在执行的任务的 makefile 的目录的完整路径（对于内部核心任务不可用）。
• CARGO_MAKE_COMMAND - 调用 cargo-make 的命令（例如：cargo make 和 makers）
• CARGO_MAKE_WORKING_DIRECTORY - 当前工作目录（可以通过设置 --cwd CLI 选项来定义）
• CARGO_MAKE_WORKSPACE_WORKING_DIRECTORY - 工作区的原始工作目录。使工作区成员能够访问工作区级别的 CARGO_MAKE_WORKING_DIRECTORY。
• CARGO_MAKE_PROFILE - 当前配置文件名称的小写（不应由全局/任务环境块手动修改）
• CARGO_MAKE_ADDITIONAL_PROFILES - 额外配置文件名称的小写，用分号字符分隔（不应由全局/任务环境块手动修改）
• CARGO_MAKE_PROJECT_NAME - 对于独立包，这将与 CARGO_MAKE_CRATE_NAME 相同，对于工作区，它将默认为工作目录的基本名。
• CARGO_MAKE_PROJECT_VERSION 对于独立包，这将与 CARGO_MAKE_CRATE_VERSION 相同，对于工作区，它将是主包版本（主包由配置部分中的可选 main_project_member 属性定义）。
• CARGO_MAKE_CARGO_HOME - 根据cargo 文档中描述的路径到 CARGO_HOME
• CARGO_MAKE_CARGO_PROFILE - 从 CARGO_MAKE_PROFILE 映射的 cargo 配置文件名称（未映射的值将默认为 CARGO_MAKE_PROFILE 的值）
• CARGO_MAKE_RUST_VERSION - Rust 版本（例如 1.20.0）
• CARGO_MAKE_RUST_CHANNEL - Rust 频道（稳定版、beta版、nightly版）
• CARGO_MAKE_RUST_TARGET_ARCH - x86、x86_64、arm 等 ... （参见 rust cfg 功能）
• CARGO_MAKE_RUST_TARGET_ENV - gnu、msvc 等 ... （参见 rust cfg 功能）
• CARGO_MAKE_RUST_TARGET_OS - Windows、macOS、iOS、Linux、Android 等 ... （参见 rust cfg 功能）
• CARGO_MAKE_RUST_TARGET_POINTER_WIDTH - 32, 64
• CARGO_MAKE_RUST_TARGET_VENDOR - apple、pc、unknown
• CARGO_MAKE_RUST_TARGET_TRIPLE - x86_64-unknown-linux-gnu、x86_64-apple-darwin、x86_64-pc-windows-msvc 等 ...
• CARGO_MAKE_CRATE_TARGET_DIRECTORY - 获取 cargo 存储构建输出的目标目录，尊重 ${CARGO_TARGET_DIR}、.cargo/config.toml 和 ${CARGO_HOME}/config.toml，但不尊重 --target-dir 命令行标志。
• CARGO_MAKE_CRATE_CUSTOM_TRIPLE_TARGET_DIRECTORY - 与 CARGO_MAKE_CRATE_TARGET_DIRECTORY 类似，但尊重 .cargo/config.toml 中的 build.target。
• CARGO_MAKE_CRATE_HAS_DEPENDENCIES - 根据在 Cargo.toml 中是否定义了依赖项而持有 true/false（如果没有找到 Cargo.toml，则定义为 false）
• CARGO_MAKE_CRATE_IS_WORKSPACE - 根据是否为 workspace crate 而持有 true/false（即使没有找到 Cargo.toml，也会定义）
• CARGO_MAKE_CRATE_WORKSPACE_MEMBERS - 持有一个成员路径列表（如果没有找到 Cargo.toml，则定义为空值）
• CARGO_MAKE_CRATE_CURRENT_WORKSPACE_MEMBER - 持有正在构建的当前 workspace 成员的名称（仅当流程从 workspace 级别流程开始时）
• CARGO_MAKE_CRATE_LOCK_FILE_EXISTS - 如果当前工作目录中存在 Cargo.lock 文件，则持有 true/false（在 workspace 项目中，每个成员都有自己的工作目录）。
• CARGO_MAKE_CRATE_TARGET_TRIPLE - 获取默认构建的目标三元组，尊重 .cargo/config.toml 和 ${CARGO_HOME}/config.toml。
• CARGO_MAKE_WORKSPACE_PACKAGE_NAME - 持有当前工作目录中 Cargo.toml 文件中的 workspace 根包名称。
• CARGO_MAKE_WORKSPACE_PACKAGE_VERSION - 持有当前工作目录中 Cargo.toml 文件中的 workspace 根包版本。
• CARGO_MAKE_WORKSPACE_PACKAGE_DESCRIPTION - 持有当前工作目录中 Cargo.toml 文件中的 workspace 根包描述。
• CARGO_MAKE_WORKSPACE_PACKAGE_LICENSE - 存储工作区根包的许可证，来源于当前工作目录中的 Cargo.toml 文件。
• CARGO_MAKE_WORKSPACE_PACKAGE_DOCUMENTATION - 存储工作区根包文档链接，来源于当前工作目录中的 Cargo.toml 文件。
• CARGO_MAKE_WORKSPACE_PACKAGE_HOMEPAGE - 存储工作区根包主页链接，来源于当前工作目录中的 Cargo.toml 文件。
• CARGO_MAKE_WORKSPACE_PACKAGE_REPOSITORY - 存储工作区根包仓库链接，来源于当前工作目录中的 Cargo.toml 文件。
• CARGO_MAKE_CI - 如果任务在持续集成系统（如Travis CI）中运行，则存储 true/false。
• CARGO_MAKE_PR - 如果任务在持续集成系统（如Travis CI）中作为拉取请求构建的一部分运行，则存储 true/false（未知情况默认为false）。
• CARGO_MAKE_CI_BRANCH_NAME - 存储持续集成分支名称（如果可用）。
• CARGO_MAKE_CI_VENDOR - 存储持续集成供应商名称（如果可用）。
• CARGO_MAKE_DUCKSCRIPT_VERSION - 嵌入的 duckscript 运行时版本。
• CARGO_MAKE_DUCKSCRIPT_SDK_VERSION - 嵌入的 duckscript SDK 版本。

以下环境变量将在 Cargo.toml 文件存在且定义了相关值时由 cargo-make 设置

• CARGO_MAKE_CRATE_NAME - 存储当前工作目录中 Cargo.toml 文件中的 crate 名称。
• CARGO_MAKE_CRATE_FS_NAME - 与 CARGO_MAKE_CRATE_NAME 相同，但某些字符被替换（例如 '-' 到 '_'）。
• CARGO_MAKE_CRATE_VERSION - 存储当前工作目录中找到的 crate 版本。
• CARGO_MAKE_CRATE_DESCRIPTION - 存储当前工作目录中 Cargo.toml 文件中的 crate 描述。
• CARGO_MAKE_CRATE_LICENSE - 存储当前工作目录中 Cargo.toml 文件中的 crate 许可证。
• CARGO_MAKE_CRATE_DOCUMENTATION - 存储当前工作目录中 Cargo.toml 文件中的 crate 文档链接。
• CARGO_MAKE_CRATE_HOMEPAGE - 存储当前工作目录中 Cargo.toml 文件中的 crate 主页链接。
• CARGO_MAKE_CRATE_REPOSITORY - 存储当前工作目录中 Cargo.toml 文件中的 crate 仓库链接。

以下环境变量将在项目是 git 仓库的一部分时由 cargo-make 设置

• CARGO_MAKE_GIT_BRANCH - 当前分支名称。
• CARGO_MAKE_GIT_USER_NAME - 从 git 配置的 user.name 键获取的用户名。
• CARGO_MAKE_GIT_USER_EMAIL - 从 git 配置的 user.email 键获取的用户电子邮件。
• CARGO_MAKE_GIT_HEAD_LAST_COMMIT_HASH - 最后的 HEAD 提交哈希值。
• CARGO_MAKE_GIT_HEAD_LAST_COMMIT_HASH_PREFIX - 最后的 HEAD 提交哈希值前缀。

设置工作目录

为了修改特定任务（非整个运行）的当前工作目录，请使用cwd属性。
例如

[tasks.move-dir]
cwd = "./mysubdir/"

忽略错误

在某些情况下，您可能希望将可选任务作为更大流程的一部分运行，但在这些可选任务中发生任何错误时，您不希望破坏整个构建。
对于这些任务，您可以使用具有ignore_errors=true属性的属性。

[tasks.unstable_task]
ignore_errors = true

条件

条件允许您在运行时评估是否运行特定任务。
在任务运行其安装和/或命令之前，会评估这些条件。如果条件不满足，则不会调用任务。
然而，任务依赖不受父任务条件结果的影响。

有两种类型的条件

• 标准
• 脚本

任务运行器将评估任何定义的条件，并且一个任务定义可能同时包含这两种类型。

标准

条件属性可以定义多个参数进行验证。
所有定义的参数都必须有效，条件作为整体才是真实的，才能启用任务运行。

以下是一个条件定义的示例，该定义检查我们是否在Windows或Linux上运行（但不是macOS），并且是否在beta或nightly上运行（但不是稳定版）

[tasks.test-condition]
condition = { platforms = ["windows", "linux"], channels = ["beta", "nightly"] }
script = '''
echo "condition was met"
'''

以下条件类型可用

• profile - 有关更多信息，请参阅配置文件
• os - 操作系统名称列表（Windows、macOS、iOS、Linux、Android等...，如由cfg!(target_os)定义）
• platforms - 平台名称列表（windows、linux、mac）
• channels - Rust通道列表（稳定版、beta版、nightly版）
• env_set - 必须定义的环境变量列表
• env_not_set - 必须未定义的环境变量列表
• env_true - 必须定义并设置以下之一（不区分大小写）：false、no、0或空字符串的环境变量列表
• env_false - 必须定义并设置为以下之一（不区分大小写）：false、no、0或空字符串的环境变量列表
• env - 必须定义并等于提供的值的环境变量映射
• env_contains - 必须定义并包含提供的值的环境变量映射（不区分大小写）
• rust_version - 可选的min、max和/或特定rust版本定义
• files_exist - 要检查它们是否存在的绝对路径文件列表。支持环境替换，因此您可以定义相对路径，例如${CARGO_MAKE_WORKING_DIRECTORY}/Cargo.toml
• files_not_exist - 要检查它们是否不存在的绝对路径文件列表。支持环境替换，因此您可以定义相对路径，例如${CARGO_MAKE_WORKING_DIRECTORY}/Cargo.toml
• files_modified - 输入和输出glob列表。如果任何输入文件比所有输出文件新，则条件满足。支持环境替换，因此您可以定义相对路径，例如${CARGO_MAKE_WORKING_DIRECTORY}/Cargo.toml

一些示例

[tasks.test-condition]
condition = {
    profiles = ["development", "production"],
    platforms = ["windows", "linux"],
    channels = ["beta", "nightly"],
    env_set = [ "CARGO_MAKE_KCOV_VERSION" ],
    env_not_set = [ "CARGO_MAKE_SKIP_CODECOV" ],
    env = { "CARGO_MAKE_CI" = true, "CARGO_MAKE_RUN_CODECOV" = true },
    rust_version = { min = "1.20.0", max = "1.30.0" },
    files_exist = ["${CARGO_MAKE_WORKING_DIRECTORY}/Cargo.toml"],
    files_not_exist = ["${CARGO_MAKE_WORKING_DIRECTORY}/Cargo2.toml"],
    files_modified = { input = ["${CARGO_MAKE_WORKING_DIRECTORY}/Cargo.toml", "./src/**/*.rs"], output = ["./target/**/myapp*"] }
}

要设置自定义失败消息，请在条件对象内部使用fail_message，例如

[tasks.test-condition-with-message]
condition = { platforms = ["windows"], fail_message = "Condition Failed." }
command = "echo"
args = ["condition was met"]

如果日志级别为详细或配置中的减少输出标志设置为false，则仅打印失败消息

[config]
reduce_output = false

脚本

以下脚本在任务运行其安装和/或命令之前调用，并且如果条件脚本的退出码非零，则不会调用任务。

以下是一个始终返回非零值的条件脚本示例，在这种情况下，该命令永远不会执行

[tasks.never]
condition_script = """
exit 1
"""
command = "cargo"
args = ["build"]

条件脚本可用于确保仅在满足特定条件时调用任务，例如特定第三方已安装。

要设置自定义失败消息，请在条件对象内部使用fail_message，例如

[tasks.test-condition-script-with-message]
condition = { fail_message = "Condition Script Failed." }
condition_script = [
    "exit 1"
]
command = "echo"
args = ["condition was met"]

和/或/分组或

默认情况下，所有条件组和每个组内部的所有条件都将进行评估，并且使用'AND'来验证一切是否按请求进行。
但是，还有其他类型的条件可用

• 或 - 在每个组内搜索满足单个条件的所有组和所有条件
• GroupOr - 在每个组中搜索满足单个条件的所有条件，但所有条件组都必须通过。

只需在条件对象中添加任何这些值之一的 condition_type。
例如

[tasks.test-or-condition]
condition = { condition_type = "Or", env_true = [
  "TRUE_ENV",
  "FALSE_ENV",
], env_false = [
  "TRUE_ENV",
  "FALSE_ENV",
] }
script = '''
echo "condition was met"
'''

组合条件和子任务

条件和运行任务结合可以让你定义一个条件子流程。
例如，如果你有一个覆盖流程，它应该只在CI构建的Linux上调用，并且只有当 CARGO_MAKE_RUN_CODECOV 环境变量定义为 "true" 时

[tasks.ci-coverage-flow]
description = "Runs the coverage flow and uploads the results to codecov."
condition = { platforms = ["linux"], env = { "CARGO_MAKE_CI" = true, "CARGO_MAKE_RUN_CODECOV" = true } }
run_task = "codecov-flow"

[tasks.codecov-flow]
description = "Runs the full coverage flow and uploads the results to codecov."
windows_alias = "empty"
dependencies = [
    "coverage-flow",
    "codecov"
]

第一个任务 ci-coverage-flow 定义了检查我们是否在Linux上运行，作为CI构建的一部分，并且 CARGO_MAKE_RUN_CODECOV 环境变量设置为 "true" 的条件。
只有当所有条件都满足时，它才会运行 codecov-flow 任务。
我们无法在 codecov-flow 任务上直接定义条件，因为它将在检查条件之前调用任务依赖项。

仅在源文件更改时运行任务

files_modified 条件允许任务根据文件修改时间戳跳过。
如果未找到任何比输出中的任何文件更新的输入文件，则条件会导致任务跳过。
输入和输出被定义为要检查的文件的 glob 数组（不是正则表达式）。
在下面的例子中，如果目标二进制文件比 Cargo.toml 或 src 目录中的任何 rust 源文件新，它将不会运行 cargo build 命令。

[tasks.compile-if-modified]
condition = { files_modified = { input = ["${CARGO_MAKE_WORKING_DIRECTORY}/Cargo.toml", "./src/**/*.rs"], output = ["./target/**/myapp*"] } }
command = "cargo"
args = ["build"]

安装依赖项

某些任务可能需要第三方 crate、rustup 组件或其他本地工具。
cargo-make 提供了多种方式在运行任务之前设置这些依赖项。

• Cargo 插件
• crates
• Rustup 组件
• 本地依赖
• 定义版本
• 全局版本锁定
• 安装优先级
• 多重安装

Cargo 插件

当任务使用 command 属性调用 cargo 插件时，例如

[tasks.audit]
command = "cargo"
args = ["audit"]

cargo-make 将首先检查命令是否可用。
只有在命令不可用的情况下，它才会尝试通过运行 cargo install cargo- 来安装它
如果 cargo 插件有不同的名称，您可以通过 install_crate 属性手动指定它。
您可以使用 install_crate_args 属性（例如：版本）指定额外的安装参数。

要禁用自动 crate 安装，可以将 install_crate 属性设置为 false，例如

[tasks.test]
command = "cargo"
args = ["test"]
install_crate = false

crates

cargo-make 可以验证第三方 crate 是否已安装，如果提供了相关的安装信息。
首先它会检查 crate 是否已安装，并且只有在不可用的情况下才会尝试安装。
如果提供了组件名称，第三方 crate 的安装首先通过 rustup 完成。
如果 rustup 失败或未提供组件名称，它将转而使用 cargo install 命令。
例如

[tasks.rustfmt]
install_crate = { crate_name = "rustfmt-nightly", rustup_component_name = "rustfmt-preview", binary = "rustfmt", test_arg = "--help" }
command = "rustfmt"

在这个例子中，cargo 将首先测试 rustfmt --help 命令是否正常工作，并且只有在失败的情况下，它才会首先尝试通过 rustup 安装组件 rustfmt-preview，如果失败，它会尝试运行 cargo install 对 crate 名称 rustfmt-nightly。

如果需要传递多个参数，test_arg 可以包含一个参数数组。例如

[tasks.doc-upload]
install_crate = { crate_name = "cargo-travis", binary = "cargo", test_arg = ["doc-upload", "--help"] }
command = "cargo"
args = ["doc-upload"]

在这个例子中，cargo-make 将通过运行命令 cargo doc-upload --help 来测试 cargo-travis 的存在，并且只有当此命令失败时才会安装 crate。

Rustup 组件

未作为 crate 或组件部署的 Rustup 组件（纯源代码，没有可执行二进制文件）也可以通过 cargo-make 安装。
以下示例展示了如何安装带有二进制的 rustup 组件

[tasks.install-rls]
install_crate = { rustup_component_name = "rls-preview", binary = "rls", test_arg = "--help" }

在这个例子中，cargo-make 将首先检查 rls 二进制文件是否可用，并且只有在无法执行它的情况下，它才会使用 rustup 安装 rls 组件。

一些rustup组件是纯源码，因此在这种情况下，cargo-make无法验证它们是否已经安装，并且会尝试每次都安装它们。
示例

[tasks.install-rust-src]
install_crate = { rustup_component_name = "rust-src" }

本地依赖

还可以安装原生依赖，但是需要Makefile的作者编写脚本，检查依赖是否存在，如果不存在，则正确安装。
这是通过在任务的install_script属性中设置安装脚本来实现的。
可以使用平台覆盖来为Linux/macOS/Windows平台指定不同的安装脚本。
例如

[tasks.coverage-kcov]
windows_alias = "empty"
install_script = '''
KCOV_INSTALLATION_DIRECTORY=""
KCOV_BINARY_DIRECTORY=""
if [ -n "CARGO_MAKE_KCOV_INSTALLATION_DIRECTORY" ]; then
    mkdir -p ${CARGO_MAKE_KCOV_INSTALLATION_DIRECTORY}
    cd ${CARGO_MAKE_KCOV_INSTALLATION_DIRECTORY}
    KCOV_INSTALLATION_DIRECTORY="$(pwd)/"
    cd -
    echo "Kcov Installation Directory: ${KCOV_INSTALLATION_DIRECTORY}"
    KCOV_BINARY_DIRECTORY="${KCOV_INSTALLATION_DIRECTORY}/build/src/"
    echo "Kcov Binary Directory: ${KCOV_BINARY_DIRECTORY}"
fi

# get help info to fetch all supported command line arguments
KCOV_HELP_INFO=`${KCOV_BINARY_DIRECTORY}kcov --help` || true

# check needed arguments are supported, else install
if [[ $KCOV_HELP_INFO != *"--include-pattern"* ]] || [[ $KCOV_HELP_INFO != *"--exclude-line"* ]] || [[ $KCOV_HELP_INFO != *"--exclude-region"* ]]; then
    # check we are on a supported platform
    if [ "$(grep -Ei 'debian|buntu|mint' /etc/*release)" ]; then
        echo "Installing/Upgrading kcov..."
        sudo apt-get update || true
        sudo apt-get install -y libcurl4-openssl-dev libelf-dev libdw-dev cmake gcc binutils-dev

        mkdir -p ${CARGO_MAKE_KCOV_DOWNLOAD_DIRECTORY}
        cd ${CARGO_MAKE_KCOV_DOWNLOAD_DIRECTORY}
        KCOV_DOWNLOAD_DIRECTORY=$(pwd)

        wget https://github.com/SimonKagstrom/kcov/archive/v${CARGO_MAKE_KCOV_VERSION}.zip
        unzip v${CARGO_MAKE_KCOV_VERSION}.zip
        cd kcov-${CARGO_MAKE_KCOV_VERSION}
        mkdir -p build
        cd ./build
        cmake ..
        make

        # if custom installation directory, leave kcov as local
        if [ -n "CARGO_MAKE_KCOV_INSTALLATION_DIRECTORY" ]; then
            cd ${KCOV_DOWNLOAD_DIRECTORY}/kcov-${CARGO_MAKE_KCOV_VERSION}
            mv ./* ${KCOV_INSTALLATION_DIRECTORY}
        else
            sudo make install
            cd ../..
            rm -rf kcov-${CARGO_MAKE_KCOV_VERSION}
        fi
    fi
fi
'''

该任务检查kcov是否已安装；如果没有，则会安装它及其所需的任何其他依赖项。

定义版本

可以定义所依赖crate的最小版本，例如

[tasks.simple-example]
install_crate = { min_version = "0.0.1" }
command = "cargo"
args = ["make", "--version"]

[tasks.complex-example]
install_crate = { crate_name = "cargo-make", binary = "cargo", test_arg = ["make", "--version"], min_version = "0.0.1" }
command = "cargo"
args = ["make", "--version"]

这确保我们使用的是支持所需构建功能的crate版本。
目前定义min_version时存在一些限制

• 在任务中指定toolchain或在install_crate结构中指定rustup_component_name，将使cargo-make忽略最小版本值。
• 如果由于任何错误cargo-make无法检测当前安装的版本，cargo-make将假定版本有效并打印警告。

如果您想确保使用特定版本，可以定义version属性，例如

[tasks.complex-example]
install_crate = { crate_name = "cargo-make", binary = "cargo", test_arg = ["make", "--version"], version = "0.0.1" }
command = "cargo"
args = ["make", "--version"]

全局版本锁定

如果定义了min_version，您可以通过定义CARGO_MAKE_CRATE_INSTALLATION_LOCKED=true环境变量，自动将--locked标志添加到crate安装命令中。如果定义了version而不是min_version，则自动设置为true。

替代 Cargo 安装命令

您可以指定不同的cargo install命令，以便使crate安装使用某些自定义cargo安装器插件。例如，如果您想使用install而不是local-install插件，只需添加包含相关值的install_command属性。
例如

[tasks.alt-command-example1]
install_crate = { install_command = "custom-install" }
command = "cargo"
args = ["somecrate"]

[tasks.alt-command-example2]
install_crate = { crate_name = "somecrate", install_command = "custom-install" }

默认情况下，添加了--force标志。为了删除它，将force=false添加到install_crate定义中，如下所示

[tasks.alt-command-example2]
install_crate = { crate_name = "somecrate", install_command = "custom-install", force = false }

安装优先级

每个任务只会调用一种安装类型。
以下定义了cargo-make使用的安装类型，按优先级排序，以决定调用哪种安装流程

• install_crate - 允许安装crate和rustup组件。
• install_script - 可用于安装或运行任务命令所需的任何内容的自定义脚本。
• 自动cargo插件 - 如果命令是cargo，cargo-make将检查需要自动安装的cargo插件（如果需要）。

如果定义了多个安装类型（例如，install_crate和install_script），则将根据上述优先级列表调用一种安装类型。

多重安装

在某些情况下，任务需要安装多个项目才能正常运行。
例如，您可能需要在同一任务中安装rustup组件rls和rust-src以及cargo插件cargo-xbuild。
为了实现这一点，您可以拆分任务为调用任务和安装任务，并将安装任务设置为依赖项。
以下示例定义了两个具有相同依赖项的类似任务的流程：cargo-xbuild crate、rls rustup二进制组件和rust-src rustup源码组件。
您可以拥有两个rustup依赖项作为仅安装的任务，并将它们设置为xbuild任务的依赖项。
由于依赖项只调用一次，这还将确保不会安装两次这些rustup组件。

[tasks.install-rls]
# install rls-preview only if needed
install_crate = { rustup_component_name = "rls-preview", binary = "rls", test_arg = "--help" }

[tasks.install-rust-src]
# always install rust-src via rustup component add
install_crate = { rustup_component_name = "rust-src" }

[tasks.xbuild1]
# run cargo xbuild, if xbuild is not installed, it will be automatically installed for you
command = "cargo"
args = [ "xbuild", "some arg" ]
dependencies = [ "install-rls", "install-rust-src" ]

[tasks.xbuild2]
# run cargo xbuild, if xbuild is not installed, it will be automatically installed for you
command = "cargo"
args = [ "xbuild", "another arg" ]
dependencies = [ "install-rls", "install-rust-src" ]

[tasks.myflow]
dependencies = [ "xbuild1", "xbuild2" ]

工作区支持

如果cargo-make检测到当前工作目录是工作区根目录（一个包含Cargo.toml的目录，该文件定义了工作区及其成员），它将不会在该目录中调用请求的任务。
相反，它将在运行时生成一个任务定义，该定义将遍历每个成员目录并在该成员上调用请求的任务。
例如，如果我们有以下目录结构

workspace
├── Cargo.toml
├── member1
│   └── Cargo.toml
└── member2
    └── Cargo.toml

如果我们运行cargo make mytask，它将进入每个工作区成员目录并执行：在当前目录下执行cargo make mytask，其中mytask是在工作区级别请求的原始任务。
成员的顺序由工作区Cargo.toml中的成员属性定义。

这种流程被称为工作区流程，因为它识别工作区并处理对每个工作区成员的请求，而定义工作区结构的根目录被忽略。

我们可以使用这项功能在所有工作区成员crates上运行相同的功能，例如，如果我们想格式化所有crates，我们可以在工作区目录中运行：cargo make format。

成员crate的makefile也可以自动扩展工作区目录的makefile。
更多信息请参阅相关部分。

禁用工作区支持

如果您希望在工作区根目录上运行任务而不是在成员上运行（例如生成工作区级别的README文件），请在运行cargo make时使用--no-workspace CLI标志。
例如

cargo make --no-workspace mytask

这使cargo-make忽略该目录是工作区根目录的事实，并且就像这是一个带有makefile的简单目录一样运行简单的流程。

另一种在工作区级别调用任务的方法（而不是针对每个成员）是在工作区Makefile.toml中将该任务定义为具有workspace设置为false，如下所示

[tasks.ignore-members]
workspace = false

将cargo-make命令行请求的任务的workspace=false设置等同于使用--no-workspace标志调用它。
此标志仅针对cargo-make命令行上的任务进行检查，对于所有其他作为流程一部分执行的任务完全忽略。
默认情况下，所有任务的workspac标志都设置为true，但在配置部分可以配置为不同，如下所示

[config]
default_to_workspace = false

在这种情况下，工作区级别支持始终是禁用的，除非任务定义为workspace=true。

复合流程

您可以为工作区根目录和成员目录上的任务定义一个复合流程。
这是一个工作区级别Makefile.toml的示例，它启用了这样的流程

[tasks.composite]
dependencies = ["member_flow", "workspace_flow"]

[tasks.member_flow]
# by forking, cargo make starts and by default detects it is a workspace and runs the member_task for each member
run_task = { name = "member_task", fork = true }

[tasks.workspace_flow]
#run some workspace level command or flow

您可以通过以下方式启动此复合流程

cargo make --no-workspace composite

配置文件

您可以通过将CARGO_MAKE_USE_WORKSPACE_PROFILE设置为false来防止配置文件传递到工作区成员

[env]
CARGO_MAKE_USE_WORKSPACE_PROFILE = false

更多关于配置文件的信息请参阅配置文件部分。

跳过/包含特定成员

在大多数情况下，您可能希望在所有成员上运行特定的流程，但在极少数情况下，您可能希望跳过特定的成员。

通过将CARGO_MAKE_WORKSPACE_SKIP_MEMBERS环境变量设置为包含要跳过的成员名称的数组，您可以定义是否要那些成员不参与流程。

在下面的示例中，我们将跳过member3和member4（应在工作区级别的Makefile.toml中定义）

[env]
CARGO_MAKE_WORKSPACE_SKIP_MEMBERS = ["member3", "member4"]

您还可以定义glob路径，例如

[env]
CARGO_MAKE_WORKSPACE_SKIP_MEMBERS = "tools/*"

但是，有些情况下您可能只想在有特定条件满足时跳过特定的成员。
例如，如果您想在rust nightly编译器上运行时才构建成员模块。
这是对member3和member4的条件跳过简单示例（应在工作区级别的Makefile.toml中定义）

[tasks.workspace-task]
condition = { channels = ["beta", "stable"] }
env = { "CARGO_MAKE_WORKSPACE_SKIP_MEMBERS" = ["member3", "member4"] }
run_task = { name = "member-task", fork = true }

您必须将其作为复合流程调用

cargo make workspace-task --no-workspace

此外，您还可以声明相反的情况，即通过 CARGO_MAKE_WORKSPACE_INCLUDE_MEMBERS 环境变量来指定要包含的成员。
它与 CARGO_MAKE_WORKSPACE_SKIP_MEMBERS 环境变量遵循相同的规则。
如果同时定义了这两个变量，则包含的成员将是未被排除的成员的子集，意味着两个过滤器都将应用。

工作区模拟

工作区模拟允许您为项目创建类似于工作区结构，而无需实际定义 Rust 工作区。
这意味着您可以有一个没有 Cargo.toml 的项目目录，并且有很多子包。
这允许在根项目目录中运行 cargo make，对所有 成员 包进行操作，而无需实际的工作区，这会产生一些副作用（如共享目标文件夹和依赖项）。

为了设置工作区模拟，您需要在您的工作区级别的 Makefile.toml 中定义以下内容

[env]
# this tells cargo-make that this directory acts as a workspace root
CARGO_MAKE_WORKSPACE_EMULATION = true

# a list of crate members. since we do not have a Cargo.toml, we will need to specify this in here.
CARGO_MAKE_CRATE_WORKSPACE_MEMBERS = [
    "member1",
    "member2"
]

工具链

cargo-make 支持通过设置任务定义中的一部分 toolchain 属性来设置调用命令和安装 Rust 依赖项时要使用的工具链。
以下示例显示了如何打印当前安装的稳定和夜间 rustc 版本

[tasks.rustc-version-stable]
toolchain = "stable"
command = "rustc"
args = [ "--version" ]

[tasks.rustc-version-nightly]
toolchain = "nightly"
command = "rustc"
args = [ "--version" ]

[tasks.rustc-version-flow]
dependencies = [
    "rustc-version-stable",
    "rustc-version-nightly"
]

上述 rustc-version-flow 的示例输出为

[cargo-make] INFO - Task: rustc-version-flow
[cargo-make] INFO - Setting Up Env.
[cargo-make] INFO - Running Task: init
[cargo-make] INFO - Running Task: rustc-version-stable
[cargo-make] INFO - Execute Command: "rustup" "run" "stable" "rustc" "--version"
rustc 1.30.1 (1433507eb 2018-11-07)
[cargo-make] INFO - Running Task: rustc-version-nightly
[cargo-make] INFO - Execute Command: "rustup" "run" "nightly" "rustc" "--version"
rustc 1.32.0-nightly (451987d86 2018-11-01)
[cargo-make] INFO - Running Task: rustc-version-flow
[cargo-make] INFO - Running Task: end
[cargo-make] INFO - Build Done  in 2 seconds.

当与脚本（而不是命令）一起定义时，CARGO 环境变量将为请求的工具链定义。
以下示例显示了如何打印稳定和夜间 CARGO 二进制路径

[tasks.echo-cargo-stable]
toolchain = "stable"
script = '''
echo ${CARGO}
'''

[tasks.echo-cargo-nightly]
toolchain = "nightly"
script = '''
echo ${CARGO}
'''

[tasks.echo-cargo-all]
dependencies = ["echo-cargo-stable", "echo-cargo-nightly"]

上述 echo-cargo-all 的示例输出为

[cargo-make] INFO - Task: echo-cargo-all
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: legacy-migration
[cargo-make] INFO - Running Task: echo-cargo-stable
/home/someuser/.rustup/toolchains/stable-armv7-unknown-linux-gnueabihf/bin/cargo
[cargo-make] INFO - Running Task: echo-cargo-nightly
/home/someuser/.rustup/toolchains/nightly-armv7-unknown-linux-gnueabihf/bin/cargo
[cargo-make] INFO - Build Done in 4.44 seconds.

您还可以通过通道断言 rustc 的最小所需版本。这有助于记录所需的编译器功能和提醒开发人员升级其安装。

[tasks.requires-stable-edition-2021]
toolchain = { channel = "stable", min_version = "1.56" }
command = "rustc"
args = ["--version"]

如果工具链未安装或现有版本小于指定的 min_version，则任务将失败。

初始化和结束任务

由 cargo-make 执行的每个任务或流程都有额外的 2 个任务。
一个初始化任务，在所有流程的开始时调用，以及一个结束任务，在所有流程的结束时调用。
初始化和结束任务的名字定义在 toml 文件的配置部分中，以下显示默认设置

[config]
init_task = "init"
end_task = "end"

[tasks.init]

[tasks.end]

默认情况下，初始化和结束任务都是空的，可以通过外部 toml 文件进行修改，或者您可以简单地在外部 toml 文件中更改初始化和结束任务的名字，以便指向不同的任务。
这些任务允许在运行任何流程时调用常见操作。

重要的是要注意，初始化和结束任务的调用与其他任务不同。

• 别名和依赖项将被忽略
• 如果在执行的流程中定义了相同的任务，则这些任务将被多次调用

因此，不建议在流程中也使用初始化/结束任务。

捕获错误

默认情况下，任何未将 ignore_errors=true 设置为的 task 的错误都将导致整个流程失败。
然而，在某些情况下，您可能希望在流程失败之前进行某种清理。
cargo make 允许您定义一个 on error 任务，该任务仅在流程失败时调用。
为了定义此特殊任务，您必须在 Makefile 的 config 部分中添加 on_error_task 属性，并将其指向您的任务，例如

[config]
on_error_task = "catch"

[tasks.catch]
script = '''
echo "Doing cleanups in catch"
'''

Cargo 别名任务

Cargo 别名命令 可以自动加载为 cargo-make 任务。
为了自动加载它们，必须在 Makefile.toml 的配置部分中定义以下内容

[config]
load_cargo_aliases = true

在 config.toml 中定义的每个别名都将加载为具有与别名相同名称的任务。
如果存在同名的任务，它将被忽略。
任务定义将简单地调用cargo和别名值，因此不会自动安装cargo插件。

配置文件

配置文件是一个有用的工具，用于定义自定义行为。
为了设置执行配置文件，请使用 --profile 或 -p 命令行参数，并指定配置文件名称。
配置文件名称将自动转换为下划线并去除多余空格。
如果没有提供配置文件名称，配置文件将默认为 开发。

设置配置文件示例

cargo make --profile production mytask

配置文件提供多项功能

• 环境变量覆盖
• 基于配置文件的条件，例如

condition = { profiles = ["development", "production"] }

• 新环境变量 CARGO_MAKE_PROFILE，它包含配置文件名称，可以被条件、脚本和命令使用。

可以使用 additional_profiles 同时激活多个配置文件，但这些支持有限。
默认配置文件（如果没有通过命令行提供）是 "development"。
但是，可以通过设置环境变量 CARGO_MAKE_DEFAULT_PROFILE 来覆盖它。

[config]
additional_profiles = ["second_profile", "another_profile"]

额外的配置文件可以用来定义额外的环境块，并将它们定义在新的环境变量 CARGO_MAKE_ADDITIONAL_PROFILES 中。

环境变量

配置文件使您能够定义一个新子集的环境变量，这些变量仅在当前配置文件与env配置文件匹配时在运行时设置。

[env]
RUST_BACKTRACE = "1"
EVALUATED_VAR = { script = ["echo SOME VALUE"] }
TEST1 = "value1"
TEST2 = "value2"
COMPOSITE = "${TEST1} ${TEST2}"

# profile based environment override
[env.development]
DEV = true

[env.production]
PROD = true

例如，给定以下具有2个基于配置文件的环境映射的makefile

[env]
COMMON = "COMMON"
PROFILE_NAME = "${CARGO_MAKE_PROFILE}"

[env.development]
IS_DEV = true
IS_PROD = false

[env.production]
IS_DEV = false
IS_PROD = true

[tasks.echo]
script = [
'''
echo COMMON: ${COMMON}
echo PROFILE_NAME: ${PROFILE_NAME}
echo IS_DEV: ${IS_DEV}
echo IS_PROD: ${IS_PROD}
'''
]

我们使用 生产 配置文件运行 echo 任务如下

cargo make --cwd ./examples --makefile profile.toml --profile production echo

输出

[cargo-make] INFO - cargo make 0.37.15
[cargo-make] INFO - Build File: profile.toml
[cargo-make] INFO - Task: echo
[cargo-make] INFO - Profile: production
[cargo-make] INFO - Setting Up Env.
[cargo-make] INFO - Running Task: init
[cargo-make] INFO - Running Task: echo
+ cd /media/devhdd/projects/rust/cargo-make/examples
+ echo COMMON: COMMON
COMMON: COMMON
+ echo PROFILE_NAME: production
PROFILE_NAME: production
+ echo IS_DEV: FALSE
IS_DEV: FALSE
+ echo IS_PROD: TRUE
IS_PROD: TRUE
[cargo-make] INFO - Running Task: end
[cargo-make] INFO - Build Done  in 0 seconds.

环境文件也可以根据配置文件使用 profile 属性进行过滤，如下所示

env_files = [
    { path = "./development.env", profile = "development" },
    { path = "./production.env", profile = "production" },
    { path = "./env.env" }
]

在配置部分定义的额外配置文件也将导致额外的环境块/文件被加载，例如

env_files = [
    { path = "./second.env", profile = "second_profile" },
    { path = "./another.env", profile = "another_profile" }
]

[config]
additional_profiles = ["second_profile", "another_profile"]

[env.second_profile]
IS_SECOND_AVAILABLE = true

[env.another_profile]
IS_OTHER_AVAILABLE = true

这可以非常有用，因为它可以在环境变量块中启用/禁用特定的任务。

条件

条件允许您触发/跳过任务。
条件内置了对配置文件的支持，因此您可以根据配置文件名称触发/跳过任务。

示例

[tasks.echo-development]
condition = { profiles = [ "development" ] }
command = "echo"
args = [ "running in development profile" ]

[tasks.echo-production]
condition = { profiles = [ "production" ] }
command = "echo"
args = [ "running in production profile" ]

内置配置文件

cargo-make包含一些内置的配置文件，以快速启用额外的条件任务。

• ci-coverage-tasks - 将启用所有代码覆盖率任务，并设置rust编译以移除无效代码。
• none-thread-safe-tests - 将rust测试运行器设置为单线程
• multi-phase-tests - 允许将测试分成多个阶段（线程安全、多线程、自定义）
• ci-static-code-analysis-tasks - 将启用所有静态代码分析任务，例如格式检查和clippy，作为CI流程的一部分（关于向下兼容性的特殊说明见下文）。
• ci-all-build-tasks - 将启用所有额外的编译任务（即基准和示例代码），作为CI流程的一部分（关于向下兼容性的特殊说明见下文）。
• all-default-tasks - 将在运行默认任务时启用额外的任务（例如toml格式化）。

其中一些配置文件可能会在未来更改，以启用更多任务，这可能会破坏您的构建，并且按定义将永远不会向下兼容。
请谨慎使用。

私有任务

私有任务是仅应由其他任务调用而不是直接从CLI调用的任务。

为了将任务定义为私有，请添加具有值true的 private 属性，如下所示

[tasks.internal-task]
private = true

已弃用任务

可以标记任务为已弃用，以警告用户不应再使用此任务，而应切换到较新/不同的任务。
一旦调用，将显示带有弃用信息的警告消息。
您可以通过将 deprecated 设置为 true 或提供相关消息来定义一个已弃用的任务。
例如

[tasks.legacy]
deprecated = "Please use task OTHER instead"

[tasks.legacy-extended]
extend = "legacy"
deprecated = false

[tasks.legacy2]
deprecated = true

例如，调用 legacy 任务时，输出结果为

[cargo-make] INFO - cargo make 0.37.15
[cargo-make] INFO - Build File: deprecated.toml
[cargo-make] INFO - Task: legacy
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: empty
[cargo-make] INFO - Running Task: legacy
[cargo-make] WARN - Task: legacy is deprecated - Please use task OTHER instead
[cargo-make] INFO - Running Task: empty
[cargo-make] INFO - Build Done in 0 seconds.

当列出任务时，已弃用的任务将包含此信息

No Category
----------
default - Empty Task
empty - Empty Task
legacy - No Description. (deprecated - Please use task OTHER instead)
legacy-extended - No Description.
legacy2 - No Description. (deprecated)

监视

通过 cargo-make 触发任务以监视项目中的更改非常简单。
只需为任务添加 watch 属性并将其设置为 true，一旦触发任务，就会在项目中的文件更改时运行。
需要终止进程才能停止监视。

示例

[tasks.watch-example]
command = "echo"
args = [ "Triggered by watch" ]
watch = true

以下为调用任务的示例输出

[cargo-make] INFO - cargo make 0.37.15
[cargo-make] INFO - Build File: ./examples/watch.toml
[cargo-make] INFO - Task: watch-example
[cargo-make] INFO - Setting Up Env.
[cargo-make] INFO - Running Task: init
[cargo-make] INFO - Running Task: watch-example
[cargo-make] INFO - Running Task: watch-example-watch
[cargo-make] INFO - Execute Command: "cargo" "watch" "-q" "-x" "make --disable-check-for-updates --no-on-error --loglevel=info --makefile=/projects/rust/cargo-make/examples/watch.toml watch-example"
[cargo-make] INFO - cargo make 0.37.15
[cargo-make] INFO - Build File: /projects/rust/cargo-make/examples/watch.toml
[cargo-make] INFO - Task: watch-example
[cargo-make] INFO - Setting Up Env.
[cargo-make] INFO - Running Task: init
[cargo-make] INFO - Running Task: watch-example
[cargo-make] INFO - Execute Command: "echo" "Triggered by watch"
Triggered by watch
[cargo-make] INFO - Running Task: end
[cargo-make] INFO - Build Done  in 0 seconds.
^C

您还可以通过以下方式调整监视设置（基于 cargo-watch）：

[tasks.watch-args-example]
command = "echo"
args = [ "Triggered by watch" ]
watch = { postpone = true, no_git_ignore = true, ignore_pattern = "examples/files/*", watch = ["./docs/"] }

有关所有可用选项的描述，请参阅 文档。

运行多个阻塞监视

在需要运行多个阻塞监视的场景（例如运行编译 + HTTP 服务器）中，您需要将所有此类监视作为并行分叉子任务运行。
为了实现这一点，您需要使用 fork=true 和 parallel=true 属性。
例如

[tasks.multiple-watches]
run_task = { name = ["build", "http-server", "something-else"], fork = true, parallel = true }

函数

cargo-make 提供内置函数，有助于扩展环境变量所缺少的功能。
函数在 makefile 中并不支持，目前仅在命令参数数组结构中受支持。
为了定义函数调用，使用以下格式：@@FUNCTION_NAME(ARG1,ARG2,ARG3,...)
例如

[tasks.split-example]
command = "echo"
args = ["@@split(ENV_VAR,|)"]

当前支持的功能

• 拆分
• GetAt
• 移除空值
• 修剪
• 解码

拆分

split 函数接受两个参数

• 环境变量名称
• 按字符分割

然后返回一个子字符串数组。
这可以用来将环境变量分割成多个命令参数，例如

[env]
MULTIPLE_VALUES="1 2 3 4"

[tasks.split]
command = "echo"
args = ["@@split(MULTIPLE_VALUES, )"]

[tasks.no-split]
command = "echo"
args = ["${MULTIPLE_VALUES}"]

> cargo make --cwd ./examples --makefile functions.toml split
[cargo-make] INFO - cargo make 0.37.15
[cargo-make] INFO - Build File: functions.toml
[cargo-make] INFO - Task: split
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: init
[cargo-make] INFO - Running Task: split
[cargo-make] INFO - Execute Command: "echo" "1" "2" "3" "4"
1 2 3 4
[cargo-make] INFO - Running Task: end
[cargo-make] INFO - Build Done  in 0 seconds.

> cargo make --cwd ./examples --makefile functions.toml no-split
[cargo-make] INFO - cargo make 0.37.15
[cargo-make] INFO - Build File: functions.toml
[cargo-make] INFO - Task: no-split
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: init
[cargo-make] INFO - Running Task: no-split
[cargo-make] INFO - Execute Command: "echo" "1 2 3 4"
1 2 3 4
[cargo-make] INFO - Running Task: end
[cargo-make] INFO - Build Done  in 0 seconds.

split 函数还支持可选的第三个 mode 属性。
如果 mode: remove-empty，则输出将不包括空值。

GetAt

getat 函数接受三个参数

• 环境变量名称
• 按字符分割
• 要返回的项目索引

然后返回一个基于给定索引的单值数组。
这可以用来分割环境变量并提取所需参数，例如

[env]
MULTIPLE_VALUES="1 2 3 4"

[tasks.getat]
command = "echo"
args = ["@@getat(MULTIPLE_VALUES,|,3)"]

> cargo make --cwd ./examples --makefile functions.toml getat
[cargo-make] INFO - cargo make 0.37.15
[cargo-make] INFO - Build File: functions.toml
[cargo-make] INFO - Task: getat
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: getat
[cargo-make] INFO - Execute Command: "echo" "4"
4
[cargo-make] INFO - Build Done in 0 seconds.

移除空值

remove empty 函数接受单个参数

• 环境变量名称

如果环境变量未定义或为空，或者返回实际环境变量值，则将完全删除该命令行参数。

[tasks.remove-empty]
command = "echo"
args = ["1", "@@remove-empty(DOES_NOT_EXIST)", "2"]

> cargo make --cwd ./examples --makefile functions.toml remove-empty
[cargo-make] INFO - cargo make 0.37.15
[cargo-make] INFO - Build File: functions.toml
[cargo-make] INFO - Task: remove-empty
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: init
[cargo-make] INFO - Running Task: remove-empty
[cargo-make] INFO - Execute Command: "echo" "1" "2"
1 2
[cargo-make] INFO - Running Task: end
[cargo-make] INFO - Build Done  in 0 seconds.

修剪

trim 函数接受以下参数

• 环境变量名称
• 可选的 trim 类型：start/end（如果未提供，则同时修剪起始和结束部分）

如果环境变量未定义，或者修剪后为空，或者返回实际环境变量值，则将完全删除该命令行参数。

[env]
TRIM_VALUE="   123    "

[tasks.trim]
command = "echo"
args = ["@@trim(TRIM_VALUE)"]

> cargo make --cwd ./examples --makefile functions.toml remove-empty
[cargo-make] INFO - cargo make 0.37.15
[cargo-make] INFO - Build File: functions.toml
[cargo-make] INFO - Task: trim
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: init
[cargo-make] INFO - Running Task: trim
[cargo-make] INFO - Execute Command: "echo" "123"
123
[cargo-make] INFO - Running Task: end
[cargo-make] INFO - Build Done  in 0 seconds.

以下为使用 start/end 属性的示例

[env]
TRIM_VALUE="   123    "

[tasks.trim-start]
command = "echo"
args = ["@@trim(TRIM_VALUE,start)"]

[tasks.trim-end]
command = "echo"
args = ["@@trim(TRIM_VALUE,end)"]

> cargo make --cwd ./examples --makefile functions.toml trim-start
[cargo-make] INFO - cargo make 0.37.15
[cargo-make] INFO - Build File: functions.toml
[cargo-make] INFO - Task: trim-start
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: init
[cargo-make] INFO - Running Task: trim-start
[cargo-make] INFO - Execute Command: "echo" "123    "
123
[cargo-make] INFO - Running Task: end
[cargo-make] INFO - Build Done  in 0 seconds.

> cargo make --cwd ./examples --makefile functions.toml trim-end
[cargo-make] INFO - cargo make 0.37.15
[cargo-make] INFO - Build File: functions.toml
[cargo-make] INFO - Task: trim-end
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: init
[cargo-make] INFO - Running Task: trim-end
[cargo-make] INFO - Execute Command: "echo" "   123"
   123
[cargo-make] INFO - Running Task: end
[cargo-make] INFO - Build Done  in 0 seconds.

解码

decode 函数接受以下参数

• 环境变量名称
• 可选的映射值列表（源/目标）
• 可选的默认值

如果输出为空，则将删除该命令行参数。

例如

[tasks.decode]
command = "echo"
args = ["Env:", "${CARGO_MAKE_PROFILE}", "Decoded:", "@@decode(CARGO_MAKE_PROFILE,development,dev,ci,test)"]

我们检查 CARGO_MAKE_PROFILE 环境变量值，并在映射中查找。
如果值是 development，则映射为 dev，而 ci 映射为 test。
如果没有找到映射，则返回原始值。
找到映射的示例运行

cargo make --cwd ./examples --makefile functions.toml -e DECODE_ENV_VAR=development decode
[cargo-make] INFO - cargo make 0.37.15
[cargo-make] INFO - Build File: functions.toml
[cargo-make] INFO - Task: decode
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: empty
[cargo-make] INFO - Running Task: decode
[cargo-make] INFO - Execute Command: "echo" "Env:" "development" "Decoded:" "dev"
Env: development Decoded: dev
[cargo-make] INFO - Running Task: empty
[cargo-make] INFO - Build Done in 0 seconds.

未找到映射的示例运行

cargo make --cwd ./examples --makefile functions.toml -e DECODE_ENV_VAR=unmapped decode
[cargo-make] INFO - cargo make 0.37.15
[cargo-make] INFO - Build File: functions.toml
[cargo-make] INFO - Task: decode
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: empty
[cargo-make] INFO - Running Task: decode
[cargo-make] INFO - Execute Command: "echo" "Env:" "unmapped" "Decoded:" "unmapped"
Env: unmapped Decoded: unmapped
[cargo-make] INFO - Running Task: empty
[cargo-make] INFO - Build Done in 0 seconds.

另一个示例

[tasks.decode-with-default]
command = "echo"
args = ["Env:", "${DECODE_ENV_VAR}", "Decoded:", "@@decode(DECODE_ENV_VAR,development,dev,ci,test,unknown)"]

与上一个示例相同，但不同之处在于如果没有找到映射，则返回默认值（最后一个参数）。
示例运行

cargo make --cwd ./examples --makefile functions.toml -e DECODE_ENV_VAR=unmapped decode-with-default
[cargo-make] INFO - cargo make 0.37.15
[cargo-make] INFO - Build File: functions.toml
[cargo-make] INFO - Task: decode-with-default
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: empty
[cargo-make] INFO - Running Task: decode-with-default
[cargo-make] INFO - Execute Command: "echo" "Env:" "unmapped" "Decoded:" "unknown"
Env: unmapped Decoded: unknown
[cargo-make] INFO - Running Task: empty
[cargo-make] INFO - Build Done in 0 seconds.

映射值可以包含环境表达式，例如

[tasks.decode-with-eval]
command = "echo"
args = ["Env:", "${DECODE_ENV_VAR}", "Decoded:", "@@decode(DECODE_ENV_VAR,test,The current profile is: ${CARGO_MAKE_PROFILE})"]

示例运行

cargo make --cwd ./examples --makefile functions.toml -e DECODE_ENV_VAR=test decode-with-eval
[cargo-make] INFO - cargo make 0.37.15
[cargo-make] INFO - Build File: functions.toml
[cargo-make] INFO - Task: decode-with-eval
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: empty
[cargo-make] INFO - Running Task: decode-with-eval
[cargo-make] INFO - Execute Command: "echo" "Env:" "test" "Decoded:" "The current profile is: development"
Env: test Decoded: The current profile is: development
[cargo-make] INFO - Running Task: empty
[cargo-make] INFO - Build Done in 0 seconds.

持续集成

cargo-make 提供了一个由内部或在线服务（如 travis-ci 和 appveyor）执行的持续集成构建的预定义流程。
建议使用调试标志安装 cargo-make 以加快安装速度。

Github 动作

请将以下内容添加到您的 workflow.yml 文件中

- name: Install cargo-make
  uses: actions-rs/cargo@v1
  with:
    command: install
    args: --debug cargo-make
- name: Run CI
  uses: actions-rs/cargo@v1
  with:
    command: make
    args: ci-flow

这将使用最新的 cargo-make 并包含所有最新功能。

您可以在以下位置查看完整的 yaml 文件： ci.yml

如果您想运行代码覆盖率并将其上传到 codecov，也需要定义以下环境变量

CARGO_MAKE_RUN_CODECOV=true

在处理工作区时，为了对每个成员运行 ci-flow 并打包所有覆盖率数据，请使用以下命令

- name: Install cargo-make
  uses: actions-rs/cargo@v1
  with:
    command: install
    args: --debug cargo-make
- name: Run CI
  uses: actions-rs/cargo@v1
  with:
    command: make
    args: --no-workspace workspace-ci-flow

为了在构建过程中加快 cargo-make 的安装，您可以使用 rust-cargo-make GitHub 动作下载预构建的二进制文件。

Travis

请将以下内容添加到 .travis.yml 文件中

script:
  - cargo install --debug cargo-make
  - cargo make ci-flow

这将使用最新的 cargo-make 并包含所有最新功能。
当缓存 cargo 时

cache: cargo
script:
  - which cargo-make || cargo install cargo-make
  - cargo make ci-flow

注意：在使用缓存时，为了更新 cargo-make，您需要手动清除 travis 缓存

如果您想运行代码覆盖率并将其上传到 codecov，也需要定义以下环境变量

env:
  global:
    - CARGO_MAKE_RUN_CODECOV="true"

注意：如果您使用 kcov 覆盖率，可以通过将环境变量 CARGO_MAKE_KCOV_INSTALLATION_DIRECTORY 设置为 travis 缓存的目录来缓存 kcov 安装。

在处理工作区时，为了对每个成员运行 ci-flow 并打包所有覆盖率数据，请使用以下命令

script:
  - cargo install --debug cargo-make
  - cargo make --no-workspace workspace-ci-flow

AppVeyor

请将以下内容添加到 .appveyor.yml 文件中

build: false

test_script:
  - cargo install --debug cargo-make
  - cargo make ci-flow

在处理工作区时，为了对每个成员运行 ci-flow 并打包所有覆盖率数据，请使用以下命令

build: false

test_script:
  - cargo install --debug cargo-make
  - cargo make --no-workspace workspace-ci-flow

GitLab CI

请将以下内容添加到您的 .gitlab-ci.yml 文件中

test:cargo:
  script:
  - cargo install --debug cargo-make
  - cargo make ci-flow

在处理工作区时，为了对每个成员运行 ci-flow 并打包所有覆盖率数据，请使用以下命令

build: false

test:cargo:
  script:
  - cargo install --debug cargo-make
  - cargo make --no-workspace workspace-ci-flow

为了将您的覆盖率信息上传到 codecov，您需要访问 GitLab 仓库的设置，添加一个包含您的 codecov 令牌的密钥变量。

然后您可以在 .gitlab-ci.yml 中添加以下内容以启用覆盖率支持

variables:
  CARGO_MAKE_RUN_CODECOV: "true"

CircleCI

请将以下内容添加到您的 .circleci/config.yml 文件中

- run:
    name: install cargo-make
    command: cargo install --debug cargo-make
- run:
    name: ci flow
    command: cargo make ci-flow

这将使用最新的 cargo-make 并包含所有最新功能。
当缓存 cargo 时

  - restore_cache:
      key: project-cache
  # ....
  - run:
      name: install cargo-make
      command: which cargo-make || cargo install cargo-make
  - run:
      name: ci flow
      command: cargo make ci-flow
  # ....
  - save_cache:
      key: project-cache
      paths:
        - "~/.cargo"

注意：在使用缓存时，为了更新 cargo-make，您需要手动清除 CircleCI 缓存

注意：如果您使用 kcov 覆盖率，可以通过将环境变量 CARGO_MAKE_KCOV_INSTALLATION_DIRECTORY 设置为 CircleCI 缓存的目录来缓存 kcov 安装。

在处理工作区时，为了对每个成员运行 ci-flow 并打包所有覆盖率数据，请使用以下命令

- run:
    name: install cargo-make
    command: cargo install --debug cargo-make
- run:
    name: ci flow
    command: cargo make --no-workspace workspace-ci-flow

Azure Pipelines

请将以下内容添加到您的 .azure-pipelines.yml 文件中

- script: cargo install --debug cargo-make
  displayName: install cargo-make
- script: cargo make ci-flow
  displayName: ci flow