Ninja使用教程【含官方文档翻译】

本文主要是介绍Ninja使用教程【含官方文档翻译】，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前言

ninja官方文档是英文版，查阅起来不方便，所以自制一版中文版本，方便快速查找

附带自己练习使用的demo代码，适合初学者入门练习，有不懂的关键字直接在此页面搜索

使用搜索快捷键：ctrl+f

译自Ninja版本 v1.11.1, Aug 2022

官方文档链接：The Ninja build system (ninja-build.org)

生词解释：

构建边（build edge）：通常指每个build的执行语法。

NInja 介绍

Ninja是另外一个构建系统，它可以根据文件的依赖关系（文件通常指源代码和输出的可执行文件）快速的编排和构建代码。

笔者注：Ninja的特点就是可以把源代码文件和输出目标紧密联系起来，输入和输出很明确。后面会讲到。

Ninja 中加入了特别多其他构建系统。 而它本身的特点就是速度快。 它的首次使用是在开源的 Chromium 浏览器项目里，该项目拥有超过 30,000 个源文件，其他构建系统（包括自定义的非递归 Makefile）在更改一个文件后需要 10 秒才能开始构建。 Ninja只需要不到一秒。

Ninja 理念

其他构建系统都是高级语言，而 Ninja 的目标是成为汇编程序。

决策逻辑会使构建系统变慢，当你不断的编写代码、编译代码时，你会希望编译速度尽可能地快。换句话说，你希望构建系统在每次立即构建时做的工作最少。

Ninja包含描述任意依赖关系的必需的最基本功能，它没有表达复杂判断的语法。

与之对应，Ninja的用法是针对每一个输入文件单独进行生成输出。生成器程序（如 autotools 项目中的 ./configure）可以分析系统依赖项并预先做出尽可能多的决策，以便保持快速的增量构建。

除了自动工具，甚至构建时的决策例如“我应该使用哪个编译器标志？” 或“我应该构建调试（debug）或发布模式（release）的二进制文件吗？”这种问题都可以交给 .ninja 类型的文件生成器

Ninja的设计目标

以下是 Ninja 的设计目标：

• 非常快速（即时）的增量构建，即使对于非常大的项目也是如此。
• 代码的构建方案很少。不同的项目和高级构建系统关于如何构建代码有不同的配置方法。例如，构建的输出对象应该与源代码放在一起，还是所有构建输出都应该放入单独的目录中？是否有一个“包”规则来给项目构建一个可分发的包？通过允许尝试执行任何指令而不是选择参数的方法，来回避使用中的决策判断，即使这会导致语法更加冗长。
• 获取正确的依赖关系，尤其是当Makefiles无法获取正确依赖的情况下。例如，某些输出需要隐式依赖生成命令行，当你构建C语言源文件时你需要使用gcc的 -M 标志去标识头文件的依赖。
• 当方便和速度发生冲突时，优先选择速度。

一些明确不支持的目标：

• 可以手写构建文件的便捷语法。您应该使用另一个程序生成 .ninja 文件。这也是我们为什么可以回避很多的方法决策。
• 内置规则。 Ninja 没有开箱即用的规则，例如： 编译C代码。
• 在构建时自定义。配置参数应放在项目中生成的ninja文件。
• 在构建时做决策例如条件判断和查找路径。做决策是非常慢的。

重申一下，Ninja 比其他构建系统更快，因为它非常简单。 当您创建项目的 .ninja 文件时，您必须准确地告诉 Ninja 要做什么。

笔者注：ninja文件一般由CMAKE等工具生成，但也有很多项目直接使用ninja，直接使用ninja更灵活但是对开发者要求也更高

对比MAKE

Ninja 在精神和功能上与 Make 最接近，依靠简单的依赖关系中的文件时间戳运行。

笔者注：当一句语法中文件的时间戳变化了，ninja会将这个指令执行，以实现增量构建（不用每次都全部构建一遍）

但本质上来说，make 有很多功能：后缀规则、函数、内置规则，例如：构建源代码时搜索 RCS 文件。Make 的语言被设计为由人类编写。许多项目发现 make 足以解决他们的构建问题。

相比之下，Ninja几乎没有什么特色； 只要那些正确构建所必需的内容，同时将大部分复杂性都放在生成Ninja输入文件上。

Ninja 本身不太可能对大多数项目有用。

以下是Ninja对比Make增加的一些功能（这些功能通常可以使用更复杂的 Makefile 来实现，但它们不是 make 本身的一部分。）

Ninja 更加支持在构建时发现额外的依赖项，从而可以简单得到正确的 C/C++ 代码标头依赖项。

一个构建边缘可能有多个输出。

输出隐式依赖于用于生成它们的命令行，也可以意味着输入被修改。例如修改构建命令将导致重新构建。

输出目录通常在构建命令前隐士创建。

规则可以提供正在运行的命令的简短描述，因此您可以打印输出。例如在构建时取代长命令行。

构建始终并行运行，默认情况下基于系统拥有的 CPU 数量。未指定的构建依赖项将导致错误的构建。

命令输出始终被缓冲。 这意味着并行运行的命令不会交错其输出，并且当命令失败时，我们可以在产生失败的完整命令行旁边打印其失败输出。

为你的项目使用Ninja

Ninja 目前可以在类 Unix 系统和 Windows 上运行。 它在 Linux 上进行了最多的测试（并且具有最好的性能），但它在 Mac OS X 和 FreeBSD 上也能运行良好。

如果您的项目很小，Ninja 对速度的影响可能不明显。 （但是，即使对于小型项目，有时 Ninja 有限的语法也会强制采用更简单的构建规则，从而加快构建速度。）换句话说，如果您对项目的编辑-编译周期时间感到满意，那么Ninja就没有更多帮助。

还有许多其他构建系统比 Ninja 本身更加用户友好或功能更强大。 一些建议：Ninja作者发现tup构建系统对Ninja的设计有影响，并认为redo的设计相当聪明。

Ninja 的好处来自于将其与更智能的元构建系统结合使用。

gn

元构建系统用于为 Google Chrome 和相关项目（v8、node.js）以及 Google Fuchsia 生成构建文件。 gn 可以为 Chrome 支持的所有平台生成 Ninja 文件。

CMake

一种广泛使用的元构建系统，从 CMake 版本 2.8.8 开始，可以在 Linux 上生成 Ninja 文件。 较新版本的 CMake 也支持在 Windows 和 Mac OS X 上生成 Ninja 文件。

others

Ninja 应该完美地融入其他元构建软件，如 premake。 如果您从事这项工作，请告诉我们！（Ninja团队，不是笔者;）

运行Ninja

默认情况下，它会查找当前目录中指定的文件并构建所有过时的目标。 您可以指定要构建的目标（文件）作为命令行参数。

ninja build.ninja

还有一种特殊的语法，用于将目标指定为某些规则的第一个输出，该规则包含您在命令行中放入的源（如果存在）。例如，如果您指定目标文件，那么它将被构建（假设您的构建文件中有这些目标）。

target^foo.c^foo.o

ninja -h 打印帮助输出。 Ninja 的许多标志故意与 Make 的标志相匹配。例如：更改到目录并并行运行 20 个构建命令。（请注意，Ninja 默认情况下会并行运行命令，因此通常不需要传递 .）

ninja -C build -j 20build-j

环境变量

Ninja 支持使用环境变量来控制其行为，在运行规则之前打印进程状态。

.NINJA_STATUS

可用的占位符：

%s
开始构建边的数量。
%t
完成构建必须运行的边总数。
%p
开始边缘的百分比。
%r
当前运行的边的数量。
%u
要启动的剩余边数。
％F
完成的边数。
%o
每秒完成边缘的总体速率
％C
当前每秒完成边缘的速率（由指定或其默认值指定的构建的平均值）-j
%e
已用时间（以秒为单位）。 （自 Ninja 1.2 起可用。）
%%
一个普通的百分号%

默认进度状态是（注意尾随空格以与构建规则分开）。"[%f/%t] "

另一个示例："[%u/%r/%f] "

Ninja工具（命令行指令）

可以使用Ninja的命令行运行一些我们开发过程中发现的其他工具，例如：

query

转储给定目标的输入和输出。（生成dump）

browse

在 Web 浏览器中浏览依赖关系图。 单击文件会将视图集中在该文件上，显示输入和输出。 此功能需要安装 Python。 默认情况下使用端口 8000，并且将打开 Web 浏览器。 可以按如下方式更改：

ninja -t browse --port=8000 --no-browser mytarget

graph

使用自动图形布局工具所使用的语法输出文件。例如Graphviz

ninja -t graph mytarget | dot -Tpng -ograph.png

在 Ninja 源代码树中，为 Ninja 本身生成图像。 如果没有给出目标，则为所有根目标生成一个图表。ninja graph.png

targets

按规则或按深度输出目标列表。如果像这样使用，它会使用要构建的给定规则打印目标列表。 如果没有给出规则，它将打印源文件（图形的叶子）。 如果像这样使用，它会从根目标（没有输出的目标）开始以深度优先的方式打印目标列表。 缩进用于标记依赖关系。 如果深度为零，则打印所有目标。 如果没有提供参数则假定。 在此模式下，目标可能会被列出多次。 如果像这样使用，它将打印所有可用的目标而无需缩进，并且比深度模式更快。

ninja -t targets rule name
ninja -t targets depth digit
ninja -t targets depth 1
ninja -t targets all

commands

给定一个目标列表，打印一个命令列表，如果按顺序执行，这些命令可以用于重建这些目标，假设所有输出文件都已过期。

inputs

给定目标列表，打印用于重建这些目标的所有输入的列表。 自 Ninja 1.11 起可用。

clean

删除构建的文件。 默认情况下，它会删除除生成器创建的文件之外的所有构建文件。 添加该标志还会删除生成器创建的构建文件（请参阅生成器属性的规则参考）。 -g

其他参数是目标，它删除给定的目标并递归地删除为其构建的所有文件。

如果像这样使用，它将删除使用给定规则构建的所有文件。

ninja -t clean -r rules

创建但未在图表中引用的文件不会被删除。This tool takes in account the and the options (note that implies ).-v-n-n-v （这句看不懂，有看懂的朋友请留言）

cleandead

删除以前构建生成的、不再包含在构建文件中的文件。 自 Ninja 1.10 起可用。

compdb

给定一个规则列表，其中每个规则都应该是 C 系列语言编译器规则，其第一个输入是源文件的名称，在标准输出上以 Clang 工具接口期望的 JSON 格式打印编译数据库。 自 Ninja 1.2 起可用。

deps

显示文件中存储的所有依赖项。 当给定目标时，仅显示目标的依赖关系。 自 Ninja 1.4. 起可用.ninja_deps

missingdeps

给定目标列表，查找依赖于生成的文件，但对生成器没有正确（可能是传递的）依赖关系的目标。 这些目标可能会导致干净构建的构建不稳定。

假设 deps log / depfile 依赖信息正确，就可以找到损坏的目标。 任何隐式依赖于生成文件（生成器目标的输出）但没有到生成器目标的显式或仅顺序依赖路径的目标都被视为损坏。

The tool’s findings can be verified by trying to build the listed targets in a clean outdir without building any other targets. The build should fail for each of them with a missing include error or equivalent pointing to the generated file. Available since Ninja 1.11.

recompact

重新压缩文件。 从 Ninja 1.4 开始可用。.ninja_deps

restat

更新文件中所有记录的文件修改时间戳。 自 Ninja 1.10.起可用 .ninja_log

rules

输出所有规则的列表。 它可用于了解要传递给哪个规则名称，添加标志还会打印规则的描述。

msvc

仅适用于 Windows 主机。 使用一组预定义的环境变量调用编译器的辅助工具，例如cl.exe

ninja -t msvc -e ENVFILE -- cl.exe <arguments>

这个二进制文件，其中包含适合 Windows 上的 CreateProcessA() 的环境块（即一系列看起来像 NAME=VALUE 的以零结尾的字符串，后跟一个额外的零终止符）。 请注意，这使用本地代码页编码。.ENVFILE

该工具还支持一种已弃用的方法，即在使用该标志时解析编译器的输出，并从中生成 GCC 兼容的 depfile。 /showIncludes

使用此选项时，可用于传递用于输出依赖关系信息的本地化行前缀。 对于英语区域，这不带双引号，但对于其他区域会有所不同。-p STRING cl.exe "Note: including file: "

请注意，Ninja 现在原生支持此功能，并在 Ninja 文件中使用。原生支持还避免了每次必须调用编译器时启动额外的工具进程，这可以显着加快 Windows 上的构建速度。

deps = msvcmsvc_deps_prefix

wincodepage

可在 Windows 主机上使用（自 Ninja 1.11 起）。 打印构建文件中预期其编码的 Windows 代码页。 输出的形式为：

Build file encoding: <codepage>

Ninja 的未来版本中可能会添加其他行。

The is one of:<codepage>

cflags = -Wallrule cccommand = gcc $cflags -c $in -o $outbuild foo.o: cc foo.c

cflags = -g

rule cccommand = gcc $cflags -c $in -o $out

cflags = -Wall -Werror
rule cccommand = gcc $cflags -c $in -o $out# If left unspecified, builds get the outer $cflags.
build foo.o: cc foo.c# But you can shadow variables like cflags for a particular build.
build special.o: cc special.ccflags = -Wall# The variable was only shadowed for the scope of special.o;
# Subsequent build lines get the outer (original) cflags.
build bar.o: cc bar.c

ninja.rule(name='foo', command='bar', depfile='$out.d')

build foo: phony some/file/in/a/faraway/subdir/foo

rule touchcommand = touch $out
build file_that_always_exists.dummy: touch
build dummy_target_to_follow_a_pattern: phony file_that_always_exists.dummy

default foo bar
default baz

ninja_required_version = 1.1

rule ccdepfile = $out.dcommand = gcc -MD -MF $out.d [other gcc flags here]

# No more than 4 links at a time.
pool link_pooldepth = 4# No more than 1 heavy object at a time.
pool heavy_object_pooldepth = 1rule link...pool = link_poolrule cc...# The link_pool is used here. Only 4 links will run concurrently.
build foo.exe: link input.obj# A build statement can be exempted from its rule's pool by setting an
# empty pool. This effectively puts the build statement back into the default
# pool, which has infinite depth.
build other.exe: link input.objpool =# A build statement can specify a pool directly.
# Only one of these builds will run at a time.
build heavy_object1.obj: cc heavy_obj1.ccpool = heavy_object_pool
build heavy_object2.obj: cc heavy_obj2.ccpool = heavy_object_pool

• 默认目标语句，例如

  default target1 target2.

• 提交更多文件，例如

  subninja path
  include path

  两种方法的区别参考下文或Ninja构建系统 (ninja-build.org)

• 池声明，例如

  pool poolname

  参考池语法部分介绍

词汇语法

Ninja 基本上与编码格式无关，只需要 Ninja 关心的字节（如路径中的斜杠）是 ASCII。 这意味着例如 UTF-8 或 ISO-8859-1 编码类型的输入文件都应该可以工作。

注释以 # 开头，注释当前行。

换行符很重要。 像 build foo bar 这样的语句是一组以空格分隔的标记，以换行符结尾。 token内的换行符和空格必须进行转义。

语法中只有一个转义字符$，它可以有以下行为：

$ 后面接新的指令行：

转义换行符（跳过换行符继续当前行）。

$ 后面接名字

表示变量。

${varname}

$varname 的替代语法。

$ 后面接空格

表示空格。 （这只在路径列表中有用，否则路径中的空格会分隔文件名。请参见下文。）

$:

表示冒号（：）（旨在build指令中有用，否则冒号会终止输出列表）

$$

字面意义的$。表示美元符。

build或default语句首先被解析为以空格分隔的文件名列表，然后扩展成每个名称。 这意味着变量中的空格将导致扩展文件名时出现空格。

spaced = foo bar
build $spaced/baz other$ file: ...
# The above build line has two outputs: "foo bar/baz" and "other file".

在name = value类型的语句里，name开头的空格始终会被删除。 用转义字符换行之后行首的空白也会被删除。

two_words_with_one_space = foo $bar
one_word_with_no_space = foo$bar

其他空格只有在一行的开头时才有意义（用来表示缩进）。如果一行缩进比前一行多，则它被视为其父行范围的一部分；如果缩进量小于前一个，则关闭前一个作用域。

顶层变量

在最外层文件作用域中声明时，有两个变量很重要。

builddir

Ninja的输出文件的目录（也可以存其他的构建的输出）。参阅上文更多细节中的 Ninja的log 或The Ninja build system (ninja-build.org)。

ninja_required_version

当前构建脚本所需的 Ninja 最低版本。参阅上文 版本兼容性 The Ninja build system (ninja-build.org)

规则变量

一个规则块包含影响规则处理的key = value声明列表。这里是特殊key 的完整列表：

command （必有的）

要运行的命令行。 每条规则只能有一个command声明。有关引用和执行多个command的更多详细信息，请参阅下一节。Ninja构建系统 (ninja-build.org)

depfile

包含额外隐式依赖项的可配置 Makefile 的路径。（参考下文或The Ninja build system (ninja-build.org)）此功能明确支持C/C++头文件依赖，参考上文 C/C++ 头文件依赖 或 The Ninja build system (ninja-build.org)

deps

（自 Ninja 1.3 起可用。）如果存在，则一定是 gcc 或 msvc 之一，用来指定特殊依赖项的处理。（参考The Ninja build system (ninja-build.org)上文 C/C++ 头文件依赖 或The Ninja build system (ninja-build.org)）生成的数据库作为 .ninja_deps 存储在 builddir 中（参考 builddir的描述）

msvc_deps_prefix

（自 Ninja 1.5 起可用。）定义应从 msvc 的 /showIncludes 输出中删除的字符串。 仅当 deps = msvc 并且未使用英文版 Visual Studio 时才需要。

description

命令的简短描述，用于在command运行时漂亮地打印command。 -v 标志控制是否打印完整command命令和其描述； 如果command失败，则一定会在command输出之前打印出完整的命令行。

dyndep

（自 Ninja 1.10 起可用。）仅在build语句中使用。 如果存在，必须命名指定一个build语句的输入。 将从文件中动态加载发现的依赖关系信息。 有关详细信息，请参阅下文动态依赖项部分。The Ninja build system (ninja-build.org)

generator

如果存在，则指定此规则用于重新调用生成器程序。 使用generator的rule构建的文件有两种特殊处理方式：首先，如果command发生变化，它们将不会被重新构建； 其次，默认情况下它们不会被清理。

in

以空格分隔的输入文件列表，作为引用此规则的build指令提供输入。在command里时将被shell引用。 （提供 $in 只是为了方便；如果您需要此输入文件列表的某些子集或变体，只需使用该输入列表构造一个新变量并使用它即可。）

in_newline

与 $in 相同，只是多个输入由换行符而不是空格分隔。 （与 $rspfile_content 一起使用；这解决了 MSVC 链接器中的一个错误，该错误是因为MSVC 链接器使用固定大小的缓冲区来处理输入。）

out

以空格分隔的输出文件列表，作为引用此规则的build指令提供输出，在command里时将被shell引用。

restat

如果存在，会让 Ninja 在执行command后重新统计command的输出。不会修改输出时间戳的command的每个输出文件都将被视为永远不需要构建。这可能会导致输出文件的反向依赖关系从挂起的构建操作列表中删除。

rspfile，rspfile_content

如果（两个都）存在，Ninja 将使用给定命令的响应文件，即在调用命令之前将所选字符串 (rspfile_content) 写入给定文件 (rspfile)，并在成功执行命令后删除该文件.

这在 Windows 操作系统上特别有用，因为命令行的最大长度受到限制，有时候必须使用响应文件来代替。例如：

rule linkcommand = link.exe /OUT$out [usual link flags here] @$out.rsprspfile = $out.rsprspfile_content = $inbuild myapp.exe: link a.obj b.obj [possibly many other .obj files]

command变量的解释

从根本上来说，command行在 Unix 和 Windows 上的行为有所不同。

在 Unix 上，命令是参数数组。 Ninja 命令变量直接传递给 sh -c，然后由 sh -c 负责将该字符串解释为 argv 数组。 因此，引用规则是 shell 的引用规则，您可以使用所有正常的 shell 运算符，例如 && 来链接多个命令，或 VAR=value 命令来设置环境变量。

在 Windows 上，命令是字符串，因此 Ninja 将命令字符串直接传递给 CreateProcess。 （在简单执行编译器的常见情况下，这意味着开销更少。）因此，引用规则由被调用的程序确定，在 Windows 上通常由 C 库提供。 如果需要对命令进行 shell 解析（例如使用 && 链接多个命令），请通过在命令前添加命令标识  /c 来使命令执行 Windows shell。 Ninja 可能会出现“无效参数”错误，这通常表示已超出命令行长度。

构建的输出

有两种类型的构建输出，它们略有不同：

显式输出，和command中列出的一样。 这些输出是rule中的 $out 变量。这是要使用的标准输出形式，例如 编译command的object文件。

隐式输出，如加在build行中冒号（ : ）之前列出的语法 | out1 out2 （自 Ninja 1.7 起可用）。 语义与显式输出相同，唯一的区别是隐式输出不会显示在 $out 变量中。这是为了在当前command执行时不显示输出。

构建的依赖

构建依赖关系分为三种类型，它们略有不同。

显式依赖项，如comman行中列出的。 是 rule 中的 $in 变量。修改这些文件将导致重新构建输出，如果找不到这些文件并且ninja不知道如何构建这些文件，构建就会中止。这是要使用的标准依赖形式，例如 为源文件提供编译命令。

隐式依赖项，可以从规则上的 depfile 属性中获取，或在位于build行的末尾获取 | dep1 dep2 。 语义与显式依赖项相同，唯一的区别是隐式依赖项不会出现在 $in 变量中。这是为了不在命令的命令行上显示依赖关系。例如，对于一个用来 运行读取硬编码脚本 的规则，硬编码文件应该是隐式依赖项，因为该文件修改后也应该重新构建，即使它没显示在输入列表里。

请注意，通过 depfile 加载的依赖项具有稍微不同的语义，如上文 规则 中所述。

独立依赖项，在build行的末尾用 || dep1 dep2 表示。当他们过期时，在他们重新构建之前不会重新构建输出，但修改独立依赖项不会导致输出重新构建。独立依赖项对于引导尽在构建期间发现的依赖项十分有用。例如：在开始后续的编译步骤之前先生成头文件（一旦在编译过程中使用了这些头文件，生成的依赖文件将表示隐式依赖关系）

文件路径将按照相对路径和绝对路径进行比较，对于同一个文件，ninja认为这两个路径是不同的。

校验（Validations）

自 Ninja 1.11 起可用。

当build行是command行或default语法传递的依赖项之一时，build行上列出的校验项会使指定的文件被添加到构件图的顶层（就像在 Ninja 命令行上指定的一样）。

无论build语句的输出文件是否脏，验证都会添加到生成图中，并且输出用作验证的文件的生成语句的脏状态对请求它的生成语句中的脏状态没有影响。

原文：Validations are added to the build graph regardless of whether the output files of the build statement are dirty are not, and the dirty state of the build statement that outputs the file being used as a validation has no effect on the dirty state of the build statement that requested it.

笔者注：这句话翻译起来真恶心，翻译完了也不好理解。

build语句可以列出另一个build作为校验项，即使第二个build依赖于第一个build。

校验项旨在处理想执行错误检查但不想通过build生成任何生成物的规则，例如静态分析工具。将静态分析规则标记为源文件的主生成规则或依赖于主生成规则的规则的隐式输入将减慢生成的关键路径，但使用验证将允许生成在主生成规则完成后与静态分析规则并行进行。

变量的展开

变量将在路径中和 = 的右侧展开（build语法、default语法或name = value形式的语法）

当计算 name = value 语句时，变量在其右侧立即展开（根据规则的作用域），并且从那时起 $name 展开为静态字符串作为展开的结果。你永远不用“双重转义”来防止变量被展开两次。

所有变量在解析中遇到时都会立即展开，但有一个重要的例外：规则块中的变量在使用规则时展开，而不是在声明规则时展开。 在以下示例中，演示规则打印“this is a demo of bar”。

rule democommand = echo "this is a demo of $foo"build out: demofoo = bar

分析和范围界定

顶层变量声明的范围仅限于它们所在的文件。

规则声明的范围也限于它们出现的文件。（自 Ninja 1.6 起可用）

subninja 关键字用于包含另一个 .ninja 文件，引入了新的范围。 包含的 subninja 文件可以使用父文件中的变量和规则，并在文件范围内隐藏它们的值，但它不会影响父文件中变量的值。

要在当前作用域中包含另一个 .ninja 文件，就像 C #include 语句一样，请使用 include 而不是 subninja。

build块中缩进的变量声明的范围，仅限于该build块。 在build块中展开变量的完整查找顺序（规则也适用）是：

1. 特殊的内置变量（$in、$out）。
2. build块中的构建层变量。
3. rule块中的规则层变量（即 $command）。（注意根据上面的描述这里的展开会更晚，并且可以使用范围类的绑定如 $in）
4. build指令所在的文件的文件层变量。
5. 使用subninja关键字包含的文件中的文件层变量。

动态依赖关系

自 Ninja 1.10 起可用。

//TODO：剩最后一点下周在更

示例代码

这篇关于Ninja使用教程【含官方文档翻译】的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！