本页将介绍基于任务的构建系统、这些系统的工作原理以及一些 基于任务的系统可能会出现的复杂问题。在 Shell 脚本之后 基于任务的构建系统是构建领域的下一个逻辑发展。
了解基于任务的构建系统
在基于任务的构建系统中，基本的工作单元是任务。每个任务都是一个脚本，可以执行任何类型的逻辑，并且任务会将其他任务指定为必须在其之前运行的依赖项。目前使用的大多数主要构建系统（例如 Ant、Maven、Gradle、Grunt 和 Rake）都是基于任务的。而不是 Shell 脚本，大多数现代构建系统都需要工程师创建构建文件 说明如何进行构建。
请参考 Ant 手册中的以下示例：
<project name="MyProject" default="dist" basedir=".">
<description>
simple example build file
</description>
<!-- set global properties for this build -->
<property name="src" location="src"/>
<property name="build" location="build"/>
<property name="dist" location="dist"/>
<target name="init">
<!-- Create the time stamp -->
<tstamp/>
<!-- Create the build directory structure used by compile -->
<mkdir dir="${build}"/>
</target>
<target name="compile" depends="init"
description="compile the source">
<!-- Compile the Java code from ${src} into ${build} -->
<javac srcdir="${src}" destdir="${build}"/>
</target>
<target name="dist" depends="compile"
description="generate the distribution">
<!-- Create the distribution directory -->
<mkdir dir="${dist}/lib"/>
<!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file -->
<jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
</target>
<target name="clean"
description="clean up">
<!-- Delete the ${build} and ${dist} directory trees -->
<delete dir="${build}"/>
<delete dir="${dist}"/>
</target>
</project>
buildfile 采用 XML 编写，用于定义与 build 相关的一些简单元数据以及任务列表（XML 中的 <target> 标记）。（Ant 使用
target 表示任务，并使用任务一词来指代
命令。）每个任务都会执行由 Ant 定义的一系列可能的命令，
其中包括创建和删除目录、运行 javac 以及
创建 JAR 文件。这组命令可通过用户提供
涵盖各种逻辑的插件每个任务还可以定义
依赖项。这些依赖项会形成一个非循环图，如图 1 所示。
图 1. 显示依赖项的无环图
用户通过向 Ant 的命令行工具提供任务来执行构建。例如，当用户输入 ant dist 时，Ant 会执行以下步骤：
- 在当前目录中加载名为
build.xml的文件，并将其解析为 创建如图 1 所示的图表结构。 - 查找在命令行中提供的名为
dist的任务，然后 发现它依赖于名为compile的任务。 - 查找名为
compile的任务，并发现它依赖于名为init的任务。 - 查找名为
init的任务，并发现它没有依赖项。 - 执行
init任务中定义的命令。 - 执行
compile任务中定义的命令，前提是所有这些命令 任务依赖项已运行。 - 在
dist任务的所有依赖项都已运行的情况下，执行dist任务中定义的命令。
最后，运行 dist 任务时由 Ant 执行的代码是等效的
复制到以下 Shell 脚本：
./createTimestamp.shmkdir build/javac src/* -d build/mkdir -p dist/lib/jar cf dist/lib/MyProject-$(date --iso-8601).jar build/*
移除语法后，buildfile 和 build 脚本实际上没有太大差异。但我们通过这样做获益良多。我们可以
在其他目录中创建新的 buildfile 并将它们关联在一起。我们可以轻松以任意复杂的方式添加依赖于现有任务的新任务。我们只需将单个任务的名称传递给 ant 命令行工具，它就会确定需要运行的所有内容。
Ant 是一种最早于 2000 年发布的旧软件。在过去几年中，Maven 和 Gradle 等其他工具在 Ant 的基础上不断改进，并通过添加自动管理外部依赖项和无任何 XML 的更简洁语法等功能，从根本上取代了 Ant。但这些新系统的性质保持不变：它们允许工程师以任务的形式以原则化和模块化的方式编写构建脚本，并提供执行这些任务和管理它们之间的依赖项的工具。
基于任务的构建系统的缺点
由于这些工具本质上允许工程师将任何脚本定义为任务， 功能极其强大，能够让您做任何能想到的事情， 。但这种能力也存在缺点，基于任务的构建系统 使其构建脚本变得越来越复杂。通过 这类系统的问题在于，它们实际上最终会输送出太多电量， 而对系统而言，却不够强大。由于系统不知道脚本在执行什么操作，因此在调度和执行 build 步骤时必须非常保守，这会导致性能下降。而且，系统无法确认每个脚本是否在执行应有操作，因此脚本往往会变得越来越复杂，最终成为另一个需要调试的项目。
难以并行执行构建步骤
现代开发工作站功能非常强大， 能够并行执行多个构建步骤。但基于任务的系统 通常无法并行执行任务，即使看起来应该 。假设任务 A 依赖于任务 B 和 C。因为任务 B 和任务 C 不相互依赖，同时运行它们是否安全？ 系统是否能够更快地完成任务 A？如果它们不使用任何相同的资源，或许可以。但也许不是这样，也许这两个任务都使用相同的文件来跟踪状态，同时运行它们会导致冲突。通常，系统无法得知，因此它必须冒着发生这些冲突的风险（导致罕见但非常难以调试的构建问题），或者必须限制整个 build 在单个进程的单个线程中运行。这可能是强大的开发机器的巨大浪费， 排除将 build 分发到多台机器的可能性。
难以执行增量 build
良好的构建系统可让工程师执行可靠的增量构建，例如： 一项小小的更改并不需要从头构建整个代码库 。如果构建系统运行缓慢且无法 基于上述原因并行构建步骤。但遗憾的是，基于任务的构建系统在这里也遇到了问题。任务可以执行任何操作 通常无法检查这些活动是否已经完成。多项任务 只需获取一组源文件并运行编译器 即可创建一组 binaries;因此如果底层源文件存在 没有任何变化但如果没有额外信息，系统便无法显示 任务下载的文件可能已更改 写入一个时间戳，该时间戳在每次运行时可能都有所不同。为了保证正确性，系统通常必须在每次构建期间重新运行每个任务。部分 构建系统可通过让工程师指定 需要重新运行任务的条件。有时这样做是可行的 这往往比表面上看起来要复杂得多。例如，在语言中 就像允许其他文件直接包含文件的 C++ 一样， 无法确定必须监视更改的整组文件 而无需解析输入源。工程师最终往往会选择走捷径 这些快捷方式可能会导致罕见且令人沮丧的问题， 即便是不应被重复使用的情况。如果这种情况经常发生，工程师会养成在每次构建之前运行清理作业的习惯，以获取新状态，这完全违背了增量构建的初衷。确定何时需要重新运行任务非常微妙，这项工作由机器来处理比由人来处理更合适。
难以维护和调试脚本
最后，基于任务的构建系统施加的构建脚本通常只是 也很难处理虽然它们通常不会受到审查，但构建脚本 就像是正在构建的系统代码，很容易将 bug 隐藏起来。 下面列举了一些使用 基于任务的构建系统：
- 任务 A 依赖于任务 B 来生成特定文件作为输出。所有者 的任务 B 没有意识到其他任务依赖于该任务，因此将其更改为 在其他位置生成输出只有当有人尝试运行任务 A 并发现其失败时，才能检测到此问题。
- 任务 A 依赖于任务 B，任务 B 依赖于任务 C，任务 C 会生成作为任务 A 所需输出的特定文件。任务 B 的所有者 确定不再需要继续依赖任务 C， A 失败，即使任务 B 根本不关心任务 C！
- 新任务的开发者无意中对运行任务的机器做出了假设，例如工具的位置或特定环境变量的值。任务在其机器上可以正常运行，但每当其他开发者尝试运行时都会失败。
- 任务包含非确定性组件，例如从互联网下载文件或向 build 添加时间戳。现在，人们可以 每次运行构建时产生的结果可能都不同，这意味着 工程师并非总能重现并修复彼此的故障 自动编译系统上发生的故障或故障
- 具有多个依赖项的任务可能会导致竞争条件。如果任务 A 都依赖于任务 B 和任务 C，而任务 B 和 C 都修改同一个 任务 A 会得到不同的结果，具体取决于任务 B 和 C 中的哪一项 先完成。
没有通用的方法来解决这些性能、正确性或 基于任务的框架中的可维护性问题。只要工程师可以编写在 build 期间运行的任意代码，系统就无法获得足够的信息，无法始终能够快速且正确地运行 build。要解决这个问题，我们需要节省一些能源， 把它放回系统手里，重新概念 而不是运行中的任务，而是生成工件。
这种方法导致开发了基于工件的构建系统，如 Blaze 和 Bazel