[GN] 使用GN+Ninja替代MDK进行编译

最新推荐文章于 2024-08-22 15:20:50 发布

define_me_freedom

最新推荐文章于 2024-08-22 15:20:50 发布

阅读量3.9k

点赞数 3

分类专栏：构建系统嵌入式开发，

本文链接：https://blog.csdn.net/define_me_freedom/article/details/104194338

版权

嵌入式开发，同时被 2 个专栏收录

9 篇文章 2 订阅

订阅专栏

构建系统

7 篇文章 5 订阅

订阅专栏

背景

在单片机开发者中，使用MDK一直是一个较为普遍的选择，但是当工程变的越来越大之后，MDK开始力不从心，编译速度下降，配置复杂，编译过程中添加自定义行为困难等问题开始显露出来，因此选择一个更好的编译工具就变成了一个需要提上日程的需求。

工具选择

make
make属于第一代构建系统。经常在linux下开发的开发者对于makefile应该相当熟悉，使用makefile来做工程编译管理是很多人的选择，通过makefile可以将编译过程极大的简化，但是同样的，makefile的语法比较复杂，写一个可靠且运行速度良好的make构建系统出来也是一个相当蛋疼的工作，而且极容易出现问题。当工程越来越大，make进行依赖分析的时间也会越来越长，可以达到几十秒甚至几分钟的程度，这让人很难接受。
automake
第二代的构建系统，linux的构建基于该系统，该系统在make的基础上添加了对环境以来的检查等项目，但是执行效率并没有太大改善
cmake，scons
这两个典型的工具是第三代的构建系统，但是与前两代相比，这一代开始叫做元构建系统，以cmake为例，cmake本身并不会执行构建工作，cmake将更高层次的抽象（即cmakelists文件）描述构建依赖关系转换成make或其他的更底层的构建系统，该过程会屏蔽掉平台依赖，这样就可以在不同平台上进行构建。同样的使用该工具生成的makefile将会尽可能的照顾其并行性，因为这部分内容并不需要人去看，只需要按照make能看得懂的方式书写即可，这样既降低了make分析依赖关系需要的时间，又提高了并行性，从而极大的降低了构建时间而不需要写一些非常难以维护的makefile。但是同样cmake作为一个开源的项目，其易用性一直受人诟病。文档质量差，过于复杂的语法和部分难以理解的依赖关系处理，让编写描述文件非常痛苦，生成过多的中间文件和需要进行安装才能使用的特性让强迫症难以接受。
ninja
ninja是谷歌研发的新一代构建系统，其提供了无与伦比的构建速度和依赖性支持，本身为C++编写，执行效率极高。其实现极为紧凑和精练，抛弃了make中过于复杂的隐含规则等特性从而获得了极佳的依赖分析速度，其设计之初的目标就是极尽所能的提高构建速度。但是ninja的语法决定其并不适合手工编写，因此一般选择元构建系统来生成ninja文件，如cmake就支持ninja的生成，相对于makefile，其构建速度一般会有2倍以上的提升，依赖分析速度更是可以达到几十倍的量级。
gn
其详细名称猜测为generate ninja，看名称就知道了这个是专用于生成ninja文件的元构建系统。目前gn被用于管理chromium，一个超过500万行代码的超大型项目。且项目中使用了非常多的开源项目，有很多甚至有自己的分支或者patch，为了管理好这样一个项目并且提高构建效率，谷歌开发了gn这个工具。相对于cmake来说，gn拥有更友好的依赖描述规则，完善的内置文档，易用性max，对于其设计理念甚至可以称之为第四代构建系统。

看标题也知道最终的选择是GN+Ninja的组合了，原因我是强迫症接受不了cmake需要安装的蛋疼事实，也接受不了其生成巨多中间文件的特性。