xmake后期发展随想

随着xmake v2.0.1 版本的发布，这大半年的辛苦总算告一段落，这个版本我基本上重构整个项目的90%的代码，几乎算是重写了，但结果还算挺满意的。。

由于上个版本的架构设计的不是很好，不能很好进行扩展，也不支持插件模式，语法设计上也不严谨，容易出现各类隐患，这对于后期维护和发展来讲，已经出现了不可逾越的瓶颈。。

每一个项目到了必定阶段，都是要不断重构，从新构思总体架构，才能使得项目不断的向好的方向演进。。

（固然若是是公司项目就另当别论了，坑太多，历史负担较重，不是说要重构就能让你重构的。=。=）

回归正题，目前xmake基本上全部模块都是可扩展的：

• 插件扩展
• 工程模板扩展
• 平台架构扩展
• action扩展
• option选项扩展
• 自定义task任务机制
• 宏脚本扩展

模块化和可扩展性，使得xmake总体是高度解耦的，整个core的内核算法实现很是轻量，其余模块若是咱们想要扩展它，只须要把本身实现的脚本放到对应目录，就能够实现自注册，自加载。。

而且每一个插件模块内部都有严格的做用域控制、沙盒化处理，很是安全，不会干扰到其余插件。。

下一个大版本，我打算开始研究下，怎么去实现完善的依赖包管理，目前的一些想法和构思：

• 自动检测依赖包，若是存在直接连接编译，若是不存在，从远程仓库中自动下载对应版本，进行本地编译安装，而后自动集成和连接

• 支持多架构、多平台以及交叉平台的包管理

• 参考homebrew的包管理思想，将仓库放在项目中，经过git维护

• 为了实现交叉平台的包管理，仓库的包描述，除了提供包原代码的url外，还提供移植描述脚本

可能我说的有点模糊，先说说现有的一些包管理工具，例如：homebrew、apt-get、pacman等等。。

大同小异，都是下载、自动编译、安装集成到系统中，不过都只能支持pc原有的主机平台，并不支持交叉平台

例如：在windows上我要自动加载安装一个ios armv7s的包，集成到个人项目中。。这就不行了。

而xmake的下个版本，打算作的就是这个，简单的说：

我要作一个移植仓库，实现一人移植，万人使用

之后，若是用xmake编译项目，这个项目中说须要连接 android 版本 armv7-a 的 libpng.a，那么xmake 就会先检测本地仓库是否存在，不存在的话，就会从移植仓库中，check处移植脚本，自动进行本地移植编译，而后连接到这个项目中去。。。

明白了吗，是否是颇有趣。。？

如今的开源项目愈来愈多，平台也愈来愈多，可是不少c/c++项目的移植工做至关麻烦，不一样项目编译方式区别很大，平台支持力度也各不同。。

而咱们日常移植后，基本上只能本身使用，无法分享给别人

而下个版本，xmake要作的就是让其余人不用从新再移植一边，只要有人移植过，把移植过程记录成移植脚本，push到xmake的移植仓库中，让全部人共享移植成果。。这是多美妙的一件事哈。。：）

我表达能力有限，貌似有点啰嗦了，最后我对xmake的指望就是：

它不只仅是个跨平台构建工具，也将会成为移植神器，一人移植，万人共享就是xmake的目标！

---

• XMake项目详情
• XMake项目源码
• XMake项目文档