项目清单是一个文件,它描述组成库或可执行文件的源代码文件,以及如何通过语言工具(例如语言服务器和调试器)构建、分发这些文件以及与之交互。一些示例包括 Rust Cargo.toml
、Pythonsetup.py
或与语言无关的格式,例如 Bazel 及其BUILD
文件。
另一方面,构建工具是一个可以创建项目清单中描述的库或可执行文件的程序。例如,cargo build
编译并链接文件中描述的 Rust 可执行文件和库Cargo.toml
。在Python中,许多不同的工具可以处理setup.py
和pyproject.toml
文件,以便产生Python轮子或包。
该提案旨在:
- 宣布我们为 Mojo 定义项目清单格式的意图。
- 宣布我们打算为 Mojo 项目实现构建工具。
- 征求社区对项目清单和构建工具的反馈和功能请求。
动机
自 Mojo SDK v0.7.0 起,Mojo 不存在项目清单格式。在目前的情况下,Mojo项目可以通过在命令行上调用mojo package
(生成 .mojopkg
库)或mojo build
(生成可执行文件)来构建。
这种现状有几个缺点:
- 从源代码构建 Mojo 项目没有标准。如果我们检查当今 GitHub 上托管的流行 Mojo 项目,一些项目是通过
docker
Dockerfile 调用mojo run
来执行 Mojo 源文件的构建的。有些是通过 CMake 构建的,项目维护者曾经add_custom_command
在其中调用mojo build
和mojo package
.有些是通过 mojo package
仅在自述文件中记录的命令构建的。有些具有只有维护人员知道的构建说明。缺乏标准化使得下载和构建 Mojo 源存储库变得困难,从而抑制了 Mojo 开发人员社区之间的协作。
- 除了 Mojo 社区内的协作之外,项目清单的缺乏也阻碍了 Mojo 语言工具(例如语言服务器和调试器)的完美运行。例如,许多 Mojo 项目都使用编译时定义,例如
-D ENABLE_TILING
.如果不知道编译 Mojo 源代码时应使用哪些定义,语言服务器就无法提供用户在实际构建项目时看到的相同诊断。
因此,我们认为特定于 Mojo 的项目清单和构建工具将解决这些问题:
- 我们的目标是实现一个可用于从源代码构建任何 Mojo 项目的命令,解决上面列出的第一个问题。这类似于如何
cargo build
使用任何 Rust 项目的默认设置构建默认目标,或者如何zig build
为任何 Zig 项目构建默认目标。
- 由于项目的清单将指定要使用哪些 Mojo 编译器选项,因此语言工具将使用这些选项并按预期运行。这解决了上面列出的第二个问题。
指导原则
- 如上所述,我们的目标是使用单个命令能够从源代码构建任何 Mojo 项目。
- 我们相信可以在以后添加从互联网下载项目依赖项的功能(“包管理器”功能)。例如,
zig build
最初并未包含此功能,但在六年多后添加了实现。 Mojo 构建工具可能很快就会实现项目依赖项的下载和构建,但这将是一个单独提案的主题。
- 尽管我们设计的项目清单和构建工具是特定于 Mojo 的,但我们的目标是与其他构建系统(例如 Python setuptools、Bazel、Buck2 和 CMake)实现最佳集成。我们将尽可能提供调整以更好地支持这些工具。
- 我们的设计将受益于社区的意见和贡献,因此我们将其开发为开源工具,主要用 Mojo 编写。我们相信这样做也将有助于推动 Mojo 标准库的添加和改进。
请求反馈
如上所述,该提案主要是为了宣布我们为 Mojo 开发项目清单格式和构建工具的意图,并征求反馈。以下是我们希望听到社区成员意见的一些主题:
- 您是否同意本提案的动机和指导原则。
- 您喜欢哪些项目清单格式和构建工具,以及原因。我们从广泛的语言生态系统中汲取灵感,包括 Rust、Zig、Swift,尤其是 Python。
- 是否采用构建服务器协议。我们认为这样做可能有助于我们的指导原则更好地融入现有的工具生态系统。
- 是否将项目清单定义为可执行程序。类似于定义项目的程序如何
build.zig
以及是如何定义项目,我们是否应该定义一个或类似的构造?有很多论据支持这样做,但另一方面,我们也看到了权衡,并且可以使用纯粹的声明形式。Package.swift``project.mojo
- 您希望贡献的任何其他想法 - 我们是构建系统和语言工具的书呆子!将您对与此提案相关的 GitHub 讨论线程的想法发送给我们,让我们一起探索。