Electron现在用GN来构建自己。下面我们来讨论一下原因。
GYP 与 GN
当Electron在2013年首次发布时,Chromium的构建配置是用GYP编写的,是“生成您的项目”的缩写。
2014年,Chromium项目引入了一种新的构建配置工具GN(“Generate Ninja”的缩写),chrome的构建文件被迁移到GN, GYP从源代码中删除。
Electron在历史上一直保持着主要Electron代码和libchromiumcontent之间的分离,libchromiumcontent是Electron包裹Chromium“内容”子模块的一部分。Electron公司继续使用GYP,而libchromiumcontent——作为Chromium的一个子集——在Chromium使用后又改用GN。
就像齿轮不太啮合一样,使用这两个构建系统之间也存在摩擦。维护兼容性很容易出错,因为编译器标记和#defime需要在Chromium、Node、V8和electronic之间小心翼翼地保持同步。
为了解决这个问题,Electron团队一直致力于将所有东西都转移到GN。今天,从Electron上删除GYP代码的最后一部分的承诺被提交到master上。
这对你意味着什么
如果你对Electron本身做出了贡献,从master或4.0.0中检出并构建Electron的过程与3.0.0或更早的时候非常不同。详见GN构建说明。
如果你运用Electron开发一个应用,在新的Electron4.0.0-nightly有一些小的变化你可能会注意到;但更有可能的是,Electron在构建系统中的变化对你来说是完全透明的。
这对Electron意味着什么
GN的速度比GYP快,其文件可读性和可维护性更强。此外,我们希望使用单个构建配置系统将减少将Electron升级到新版Chromium所需的工作。
它已经在Electron4.0.0上有了很大的帮助,因为Chromium 67去掉了对MSVC的支持,转而在Windows上使用Clang构建。使用GN构建,我们直接从Chromium继承所有编译器命令,所以我们在Windows上免费获得了Clang构建!
它还使Electron更容易在跨Electron、Chromium和Node的统一构建中使用BoringSSL——这在以前是有问题的。
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8