用法

请确保您至少有 Rust 1.46-nightly（这是我测试过的唯一版本）。克隆此存储库，然后

cargo build --release -p ninjars --bin ninja

这将生成一个二进制文件 ./target/release/ninja，它是静态链接的，可以复制到您需要的任何位置。

贡献

欢迎贡献。请理解我查看拉取请求的时间有限，因此我可能不会立即回复。对于错误修复，请简单地提交一个 PR，最好包括对该错误的回归测试。

如果您正在考虑实现一个主要功能，请 提交一个问题 讨论该功能以及您打算如何实现它。可能会有多种解决方案和权衡。如果您不先讨论，那么一个包含主要功能的千行 PR 很可能被拒绝。

测试

在工作区目录中运行此命令将运行所有测试。提交 PR 时，请确保所有测试都通过。请为任何引入的新代码添加一个测试。带有测试的 PR 更容易审查和接受。

RUST_BACKTRACE=full cargo test

格式化

在提交之前，在代码上运行 cargo fmt。

设计

在思考各种事情的同时，我编写了 DESIGN.md 和 parse/DESIGN.md 文档，它们并不旨在对任何人有意义。本节总结了实际的设计。

此设计符合以下目标

尽量遵循《Build Systems a la Carte》论文中的原语

大多数生产构建系统在论文之前就已经存在，并且大多数系统在各个阶段之间没有严格的界限。我尽量在可能的情况下使原语发光。例如，重建器和调度器非常明确地使用图，用键和任务进行讨论，并尽可能避免直接 I/O（或思考现实世界中的事物，如 Unix 时间）。当然，由于 Rust 没有 Haskell 那样的完整泛型/高阶类型支持，因此在这方面存在限制。在 Rust 中过度编写通用代码会很快变得陈旧，因为您可能需要开始到处放置 trait 约束或泛型。这个第一阶段解析 ninja 文件，并将这些转换为构建描述。然后将其转换为论文中提到的键和任务。然后，有一个调度器（拓扑）和重建器（基于 mtime）的实现，实现了 ninja 语义。

在某种程度上，这几乎是一个 ninja 语言的编译器管道，但最终阶段是动作图的解释器，而不是代码生成器。

尽量提供可用的独立 crate

实现是一个 crate 的集合。解析器可以单独使用。词法分析器保留有关标记的相对完整信息（与 ninja 不同），这可能允许像 ninja-fmt 这样的功能。最初，我设想解析器会生成每个文件的 AST，但 ninja 处理 include 和 subninja 规则之间的作用域的方式，使得这变得难以处理。具体来说，包含文件中的变量会在当前环境中立即评估，因此这不能并行化，并且一旦发生包含，每个文件的 AST 就没有意义。

主要的 ninja 库只是将这些组件组合在一起。理论上，可以使用 tasks 和 build 库来创建另一个构建系统。目前存在一些不干净的 API 边界，但这些都可以被清理。

启用性能优化

我开始非常专注于尝试避免分配和复制，但随着 Rust 强大的所有权要求的加入，这很快变得难以处理。因此，我目前走向了另一个极端，大量使用 clone()。词法分析器仍然是“零拷贝”，提供单个 &[u8] 的引用。规范化字符串归一化可以处理路径，只要愿意传播更多的生命周期，就可以在词法分析器和任务描述之间进行，而不需要复制。当然，变量评估始终需要分配新的字节。