如果希望我的编译任务是增量的，我想知道使用具有传递依赖关系的文件管理自定义编译步骤的最佳方法。这是特定的用例：我有一个充满模板的目录（在这种情况下为车把模板）。可以说这些都在一个pages目录中。其中一些模板包括其他模板（Handlebars partials）。假设包含的模板位于includes. 编译所有模板相当容易。例如，我可以使用 handlebars 命令handlebars <input-file>来编译每个文件pages（例如for (File file : srcDir) { project.exec { commandLine 'handlebars', file.name }}.
当调用handlebars 命令时，会编译input-file并在必要时提取任何包含的模板input-file以及包含添加等的任何模板。无需赘述，我还可以在编译时了解模板的全部传递依赖项它。所以，例如，如果模板A包含B和C，而B在编译过程中包含E，AI会知道如果B，C或E发生变化，我需要重新编译A。注意，我几乎需要编译模板学习这些信息，因为我需要解析它并确定它包含的所有位置，这些包含如何解析等。
我想创建一个编译文件的自定义增量任务，但仅在必要时。我知道如何声明此任务的输入，并且我知道如何在内存中维护从包含目录中的文件到直接或传递依赖它的页面中的模板的映射。因此，如果 IncrementalTaskInputs.outOfDate 包括，例如，includes/EI 知道我需要重新编译 A。到目前为止一切都很好，但我不清楚让这个实际工作的最佳方法。
显然，仅将依赖项存储在内存中是行不通的，因为守护进程可能会重新启动，甚至可能不会运行（而且我并不完全清楚哪些对象在运行之间的守护进程中仍然存在于内存中）。据我了解，Gradle 维护某种缓存，因此它能够计算正确的 IncrementalTaskInputs 并知道，例如，自上次运行以来仅包含/E 更改。因此，我不知何故需要维护一个依赖项缓存，以便在必要时从磁盘中读取。我可以通过将它们写入文件来手动执行此操作，但这似乎很容易出错。例如，不合时宜的 Ctrl-C 可能会使我的缓存与 Gradle 的缓存过时。我猜有一个内置系统允许我简单地声明依赖项并让 Gradle 负责将其与它自己的缓存一起保存。或者更好的是，也许有一个现有的基类可以处理这种事情，而我所要做的就是声明依赖关系是什么？有这样的事吗？