1.0.0 |
|
---|
#12 在 #gcc
62KB
1.5K SLoC
包含 (Mach-o 可执行文件, 1KB) examples/advanced/src/hola/hola.o
Hydrogen
一个易于使用的构建系统。
什么是 Hydrogen?
很高兴你问这个问题!Hydrogen 是一个构建系统... 为现代世界!Hydrogen 不使用像 Makefile(比如,呃,CMake)这样的明显中间阶段。相反,Hydrogen 使用内部结构!
我为什么觉得有必要再做一个构建系统呢?
我本想写一首诗,然后我意识到押韵很难。谁知道呢?无论如何,我写了 Hydrogen,因为.... CMake 就像使用一台价值10万美元的非传统林业树木砍伐机,用中文、阿拉伯语和芬兰语混合的说明书来清除你2英尺乘2英尺的花坛里的杂草(这里得到的类比)。Scons 就像告诉蜗牛执行一些有时可以理解的指令。
示例
如果你想要更深入的了解示例,请参阅示例目录。不过这里有一个简单的示例!
./Hydrogen.yml
name: greet
description: A collection of greeter programs
authors: [Milo Banks]
version: 1.0.0
type: Binary
./Build.yml
files: ['**/*.cpp']
# OR
files: ['main.cpp']
简单,对吧?它不使用像 CMake 那样的花哨 DSL
,或者像 CMake 那样的奇怪语法。
Hydrogen 的设计理念之一是使其易于猜测。这意味着如果你不知道字段的名称,你应该能够猜到,并且可能猜对。CMake 似乎不遵循这一点。
如果你觉得这个很复杂,只需看看相应的 CMake DSL
代码。
cmake_minimum_required(VERSION 2.8.9)
project(hello DESCRIPTION "A collection of greeter programs" VERSION 1.0.0)
add_executable(hello main.cpp)
尽管 CMake 更短,但你可能知道,它很容易犯错误。此外,它看起来也 很丑。
注意
在实施策略之前(可能在下一个 PR 中),你需要确保如果你想让项目构建,你必须提供一个类型。这是因为 Hydrogen 会优化掉构建没有类型的项目(因此被认为是父项目)。
词汇
以下是一些有助于你在 Hydrogen 之旅上的词汇!
实际
一个“实际”是提供如何实际构建项目数据的东西。Hydrogen 提供三种类型的实际。
第一种是静态实际。这只是一个 yaml 文件,几乎直接转换为实际的。
一个“动态”实际是一个 Python 脚本,运行以更改实际,或创建一个动态的实际。
一个“真实”的实际是 Hydrogen 使用来构建你的项目的内部结构。你甚至从未见过它(除非你想)。
Hydrogen.yml
一个包含关于您项目信息的“元数据”文件,一目了然!
Build.yml
一个静态实际。也就是说,这个实际无法更改,因此得名静态。
Build.py
一个动态实际。
顺序
Hydrogen按照一定的顺序解析和(可能)运行构建文件。具体如下
2. Meta.yml
3. Build.yml
4. Build.py
首先,您需要了解有关项目的信息。
之后,您需要创建一个静态实际,然后可能用动态实际来更改它。
请注意,如果这些文件中缺少任何一个,它们将直接跳过。唯一必需的文件是 Meta.yml
。
操作系统和编译器支持
Hydrogen是在Linux系统上开发的,同时也包括一些Mac。因此,Hydrogen支持 gcc
和 clang
(以及它们的C++对应版本)。Hydrogen不支持MSVC,但可以通过安装Linux子系统或类似 mingw-w64
的端口来轻松解决。至于操作系统支持,Hydrogen在Linux和Mac上应该运行良好,但在Windows上可能有些问题。由于Hydrogen在Windows上测试不多(甚至根本没测试),所以Hydrogen在Windows上是不稳定的。然而,一切应该都正常运行。如果您有一台Windows机器,并愿意贡献并解决一些问题,我真诚地请求您。实际上。 请!
理念
以下是我真正努力遵循的Hydrogen理念
1. 它应该是可预测的。这意味着您应该能够猜到字段的名称,并且猜对。
例如,如果您忘记了如何在构建文件中依赖列表中指定依赖项的位置,at
看起来是一个合理的猜测,所以就是at
。
2. 它不应该让您学习一门新语言(大多数人知道Python,yaml也非常简单)。
CMake不遵循此规则。它使用自己奇怪的DSL。很多人都知道Python(这使得它成为新手的理想构建系统语言)。
3. 它必须正确工作。
就这么简单。它应该工作。Hydrogen确实如此。除了少数情况外,但嘿,我是唯一一个在Hydrogen上工作的人,所以请给我一些机会。
它必须产生可重复构建。
现在,这一点并不那么简单。您可以在不同的机器上构建,当构建时,会产生完全相同的二进制/字节码。这有点极端,所以相反,我指的是相同的代码,以相同的方式构建,应该足够了。
它必须看起来很漂亮,但不能到侵犯其他规则的程度。
很简单。它必须看起来很漂亮。Hydrogen在这方面受到了yarn的启发。
它必须基于依赖项。这意味着轻松从开源领域拉入另一个项目。
这就是Hydrogen被制作出来的原因。获取依赖项,并优雅地构建它们。您不需要在花哨的HUR(Hydrogen用户仓库)中保留依赖项。您只需告诉它从GitHub、常规git仓库或只是一个tar包中获取即可。它应该能够获取不与自身构建的依赖项。
它必须非常快。
简单的事情。Hydrogen中每个并发运行的构建任务都有一个配置部分,该部分访问一个池。如果构建过程告诉配置过程它需要头文件y
,而配置池对头文件y
没有任何信息,那么Hydrogen应该查找它,而不会阻碍其他构建。这使得Hydrogen变得快速。
它必须有可维护的代码。
通过这一点,我不是指用Hydrogen构建的项目必须是可维护的。我的意思是Hydrogen本身必须是可维护的。我已经采取了措施,使Hydrogen成为可维护的。
它应该使项目构建尽可能独立。
隔离构建意味着一个构建不应该因为另一个构建而改变。Hydrogen 不会告诉你不要这么做,但它设置得很困难。
10. 它必须在构建之间缓存状态。
与使用整个目录和更多资源的 CMake 不同,Hydrogen 使用单个锁文件来做到这一点。
11. 它必须使构建迭代变得简单。
Hydrogen 这样做。你只需告诉它在哪里构建,然后等待回复。它就是这样做的。
12. 它不应妨碍开发。
CMake 绝对不遵循这条规则的最后部分。你不应该必须遵循某种结构才能使项目工作,构建文件也不应该难以编写。
13. 构建应该能够在代码大小增加的维度上进行并行化。
Hydrogen 会并行运行多个构建和配置步骤。
14. 项目必须能够从任何提交(即没有在源树之外的构建文件)构建。
这意味着构建系统不应该在存储库之外触及任何地方进行与构建相关的任何事情(显然日志是正常的)。
15. 构建文件的更改应被跟踪和版本化。
如果不能对构建配置进行版本控制,就难以追踪何时谁对构建进行了更改。由于构建系统的更改可能会极大地改变构建结果,因此这些信息对于可重复构建非常重要。Hydrogen 通过存储库内部的一切和内置的时间线使这变得简单。
16. 它应该容易设置。
这补充了#1。如果你对 Hydrogen 有一个大致的了解,并且以前使用过它,但忘记了大部分内容,那么你仍然可以设置一个项目,因为,又是#1。
17. 它必须容易扩展。
我的意思是,你应该能够支持更多的编译器、语言等,而无需更改前端。Hydrogen 通过将每个后端分割成自己的目录来实现这一点。
18. 开发者不应需要通过构建系统中的错误来实现某些功能。
CMake 以此而闻名。如果你想从它那里获取一些功能,但它根本不符合你的预期,那么你可以要么花几个小时编写自己的函数……或者简单地利用一个错误。Hydrogen 不喜欢这样做,这意味着我们必须使构建系统灵活。
19. 它不应该有一个明显的中间阶段。
与几乎所有的 C/C++ 构建系统不同,它生成构建文件(如 Make、Ninja、MSBuild 等)。这使构建系统对构建过程的控制减少,并且通常速度较慢,因为你在构建文件生成和解析上浪费了时间。
依赖项
~13–24MB
~354K SLoC