“Make”变量是一种特殊的、可扩展的字符串变量，可用于标记为“受‘Make’变量替换影响”的属性。
例如，这些变量可用于将特定工具链路径注入到用户构建的 build 操作中。
Bazel 提供预定义变量（适用于所有目标）和自定义变量（在依赖项目标中定义，仅适用于依赖于这些变量的目标）。
之所以使用“Make”一词，是因为历史原因：这些变量的语法和语义最初旨在与 GNU Make 保持一致。
使用
标记为“可进行‘变量化’替换”的属性可以引用“Make”变量 FOO，如下所示：
my_attr = "prefix $(FOO) suffix"
换句话说，任何与 $(FOO) 匹配的子字符串都会扩展为 FOO 的值。如果该值为 "bar"，则最终字符串变为：
my_attr = "prefix bar suffix"
如果 FOO 与使用方目标已知的变量不对应，Bazel 会失败并显示错误。
名称为非字母符号（例如 @）的“Make”变量也可以仅使用美元符号（不带括号）进行引用。例如：
my_attr = "prefix $@ suffix"
如需将 $ 写入为字符串字面量（即防止变量扩展），请写入 $$。
预定义变量
任何标记为“可进行‘品牌变量’替换”的属性都可以引用预定义的“品牌”变量。
如需查看这些变量的列表及其针对给定的一组 build 选项的值，请运行以下命令：
bazel info --show_make_env [build options]
并查看以大写字母开头的顶部输出行。
工具链选项变量
COMPILATION_MODE：fastbuild、dbg或opt。（了解详情）
路径变量
-
BINDIR：目标架构的生成二进制树的基础。请注意，在 build 期间在主机架构上运行的程序可能会使用不同的树，以支持交叉编译。
如果您想从
genrule中运行某个工具，建议使用$(execpath toolname)获取其路径，其中 toolname 必须列在genrule的tools属性中。 GENDIR： 目标架构的生成代码树的基础。
机器架构变量
-
TARGET_CPU： 目标架构的 CPU，例如k8。
预定义的 genrule 变量
以下内容专门适用于 genrule 的 cmd 属性，对于使该属性正常运行通常非常重要。
OUTS：genrule的outs列表。如果您只有一个输出文件，也可以使用$@。-
SRCS：genrule的srcs列表（更准确地说：srcs列表中与标签对应的文件的路径名）。 如果您只有一个源文件，也可以使用$<。 -
<：SRCS（如果它是单个文件）。否则会触发构建错误。 -
@：OUTS（如果它是单个文件）。否则会触发构建错误。 -
RULEDIR：目标的输出目录，即genfiles或bin树下与包含目标的软件包名称对应的目录。对于//my/pkg:my_genrule，此值始终以my/pkg结尾，即使//my/pkg:my_genrule的输出位于子目录中也是如此。 -
@D：输出目录。如果 outs 只有一个条目，则此变量会扩展为包含该文件的目录。如果它有多个条目，则会扩展到genfiles树中的软件包根目录，即使所有输出文件都位于同一子目录中！注意：请使用
RULEDIR而不是@D，因为RULEDIR的语义更简单，并且无论输出文件数量是多少，其行为方式都相同。如果 genrule 需要生成临时中间文件（可能是使用编译器等其他工具的结果），则应尝试将这些文件写入
@D（尽管/tmp也是可写入的），并在完成之前将其移除。尤其要避免写入包含输入的目录。它们可能位于只读文件系统上。即使不是，这样做也会破坏源树。
预定义的来源/输出路径变量
预定义变量 execpath、execpaths、rootpath、rootpaths、location 和 locations 接受标签参数（例如 $(execpath
//foo:bar)），并替换由该标签表示的文件路径。
对于源文件，这是相对于工作区根目录的路径。 对于作为规则输出的文件，这是文件的输出路径（请参阅下文中有关输出文件的说明）。
-
execpath：表示 execroot 下 Bazel 运行 build 操作的路径。在上述示例中，Bazel 会在工作区根目录中由
bazel-myproject符号链接关联的目录中运行所有 build 操作。源文件empty.source链接到路径bazel-myproject/testapp/empty.source。因此，其执行路径（即根目录下的子路径）为testapp/empty.source。这是构建操作可用于查找文件的路径。输出文件的暂存方式类似，但还添加了子路径
bazel-out/cpu-compilation_mode/bin（或对于工具的输出，添加了bazel-out/cpu-opt-exec-hash/bin）作为前缀。在上面的示例中，//testapp:app是一个工具，因为它出现在show_app_output的tools属性中。因此，其输出文件app会写入bazel-myproject/bazel-out/cpu-opt-exec-hash/bin/testapp/app。 因此，执行路径为bazel-out/cpu-opt-exec-hash/bin/testapp/app。借助此额外前缀，可以在同一 build 中为两个不同的 CPU 构建同一目标，而不会导致结果相互覆盖。传递给此变量的标签必须仅表示一个文件。对于表示源文件的标签，此属性会自动设置为 true。对于表示规则的标签，规则必须生成一个输出。如果此属性为 false 或标签格式不正确，则 build 会因错误而失败。
-
rootpath：表示构建的二进制文件在运行时可用于查找依赖项的路径，该路径相对于其 runfiles 目录（对应于主代码库）的子目录。注意：只有在启用--enable_runfiles的情况下，此功能才能正常运行，但 Windows 默认情况下未启用此功能。请改用rlocationpath以实现跨平台支持。这与
execpath类似，但会剥离上述配置前缀。在上面的示例中，这意味着empty.source和app都使用纯工作区相对路径：testapp/empty.source和testapp/app。外部代码库
repo中文件的rootpath将以../repo/开头，后跟代码库相对路径。此参数与
execpath具有相同的“仅限一个输出”要求。 -
rlocationpath：构建的二进制文件可以传递给 runfiles 库的Rlocation函数的路径，以便在运行时在 runfiles 目录（如果可用）或使用 runfiles 清单中查找依赖项。这与
rootpath类似，不包含配置前缀，但不同之处在于它始终以代码库的名称开头。在上面的示例中，这意味着empty.source和app会生成以下路径：myproject/testapp/empty.source和myproject/testapp/app。外部代码库
repo中文件的rlocationpath将以repo/开头，后跟代码库相对路径。将此路径传递给二进制文件并使用 runfiles 库将其解析为文件系统路径，是运行时查找依赖项的首选方法。与
rootpath相比，它的优势在于可在所有平台上运行，即使 runfiles 目录不可用也是如此。此参数与
execpath具有相同的“仅限一个输出”要求。 -
location：execpath或rootpath的同义词，具体取决于要扩展的属性。这是旧版 Starlark 前的行为，除非您确实了解它对特定规则的作用，否则不建议使用。如需了解详情，请参阅 #2475。
execpaths、rootpaths、rlocationpaths 和 locations 分别是 execpath、rootpath、rlocationpaths 和 location 的复数变体。它们支持生成多个输出的标签，在这种情况下，每个输出都会列出，并以空格分隔。零输出规则和格式错误的标签会导致构建错误。
所有被引用的标签都必须出现在使用方目标的 srcs 输出文件或 deps 中。否则，构建会失败。C++ 目标还可以引用 data 中的标签。
标签不必采用规范形式：foo、:foo 和 //somepkg:foo 都可以。
自定义变量
任何标记为“受‘Make 变量’替换影响”的属性都可以引用自定义“Make”变量，但前提是目标依赖于定义这些变量的其他目标。
作为最佳实践，所有变量都应该是自定义的，除非有非常好的理由将它们纳入核心 Bazel。这样可以避免 Bazel 必须加载可能开销很大的依赖项来提供使用目标的变量可能并不关心。
C++ 工具链变量
以下内容在 C++ 工具链规则中定义，可供设置了 toolchains =
["@bazel_tools//tools/cpp:current_cc_toolchain"] 的任何规则使用
某些规则（例如 java_binary）会在其规则定义中隐式包含 C++ 工具链。它们会自动继承这些变量。
内置 C++ 规则比“对其运行编译器”复杂得多。为了支持各种各样的编译模式（例如 *SAN、ThinLTO、带/不带模块），并同时在多个平台上快速运行测试，内置规则会尽最大努力确保在每个可能在内部生成的动作中设置正确的输入、输出和命令行标志。
这些变量是一种后备机制，供语言专家在极少数情况下使用。如果您想使用它们，请先与 Bazel 开发者联系。
ABI：C++ ABI 版本。-
AR：来自 crosstool 的“ar”命令。 -
C_COMPILER： C/C++ 编译器标识符，例如llvm。 -
CC：C 和 C++ 编译器命令。我们强烈建议您始终将
CC_FLAGS与CC结合使用。否则，您需自行承担风险。 CC_FLAGS：一组最小的标志，供 C/C++ 编译器用于 genrule。特别是，如果CC支持多种架构，此变量包含用于选择正确架构的标志。-
NM：来自 crosstool 的“nm”命令。 -
OBJCOPY：与 C/C++ 编译器属于同一套件的 objcopy 命令。 -
STRIP：与 C/C++ 编译器属于同一套件的 strip 命令。
Java 工具链变量
以下内容在 Java 工具链规则中定义，并且可供任何设置了 toolchains =
["@bazel_tools//tools/jdk:current_java_runtime"]（或 "@bazel_tools//tools/jdk:current_host_java_runtime"，用于等效的主机工具链）的规则使用。
JDK 中的大多数工具都不应直接使用。与上游工具相比，内置 Java 规则在 Java 编译和打包方面采用了更加复杂的方法，例如接口 JAR、头接口 JAR，以及高度优化的 JAR 打包和合并实现。
这些变量是一种后备机制，供语言专家在极少数情况下使用。如果您想使用它们，请先与 Bazel 开发者联系。
-
JAVA：“java”命令（一个 Java 虚拟机）。请避免使用此规则，并尽可能改用java_binary规则。可以是相对路径。如果您必须在调用java之前更改目录，则需要在更改之前捕获工作目录。 JAVABASE：包含 Java 实用程序的根目录。可以是相对路径。它将包含一个“bin”子目录。
Starlark 定义的变量
规则和工具链编写者可以通过返回 TemplateVariableInfo 提供程序来定义完全自定义的变量。任何通过 toolchains 属性依赖于这些规则的规则都可以读取它们的值：