氧化Make (omake)

这是一个 make 的 Rust 实现，力求简单、便携和快速。

为了避免与系统中的 make 冲突，该项目默认构建为 omake，但如果该项目在任何系统中被用作 make 的默认实现，那么它应该被命名为 make（遵循与 bmake 和 gmake 相同的约定）。

我决定尝试用 Rust 重新编写 make，这不仅是为了学习 Rust，也因为我认为现有的 make 实现的源代码非常复杂。

https://xkcd.com/2314/

安装

您可以使用 Cargo 进行安装：cargo install omake。将来，我可能考虑将该项目的打包版本提交给其他仓库，如 Homebrew 或 AUR。

项目目标

该项目处于起步阶段，所以我可能后来会发现一些或所有项目目标无法实现。无论如何，以下按重要性排序的项目目标：

1. 可移植的 makefile 和由 CMake 等工具生成的 makefile 应该能够正确运行。
2. 尽可能支持常用的 BSD 和 GNU make 扩展。
3. 能够构建 Linux 内核。
4. 真正快速。
5. 如果我们决定实现新的扩展，它们应该作为可选项实现以保持向后兼容。除非有重大的性能改进，否则应避免这样做。
6. 可能是最难的一个：不要变成一个向后不兼容的竞争标准（https://xkcd.com/927/）。虽然这听起来可能没有创意，但我的目标只是一个在 Linux、FreeBSD（以及 macOS）上工作的 make 实现；仅此而已。

1.0版本发布可能发生在该项目能够构建Linux内核的时候。

请注意，由于实现细节（尤其是在项目的初始开发阶段），某些功能可能会无意中被添加。用户可能不应该依赖于这些功能，它们甚至可能被认为是缺陷。我希望在1.0版本发布前解决所有问题，以避免（如目标#6所述）构建一个不兼容的竞争标准。已经有其他的构建系统，我实际上不想再创建一个新的。

我计划有意不包含在此实现中的工作清单

1. 从RCS/SCCS重新制作makefile。我认为没有必要支持这一点。

测试方法

在可行的地方，我们有单元测试。

在tests目录中还有一个系统测试套件。在这个上下文中，“系统”测试是指包含makefile、mod.rs文件以及makefile需要的其他文件的目录。这个mod.rs文件调用一个system_test_cases!宏，该宏执行此项目的结果二进制文件针对该目录的makefile，并使用提供的参数执行，然后检查STDOUT/STDERR是否与宏提供的预期STDOUT/STDERR相匹配，同时也检查目录是否与宏提供的预期文件和内容相匹配。

在某个时候，我也应该复制GNU make测试套件，并尝试使此项目通过整个测试套件。