xmake 后期发展随想

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

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

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

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

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

模块化和可扩展性，使得 xmake 整体是高度解耦的，整个 core 的内核算法实现非常轻量，其他模块如果我们想要扩展它，只需要把自己实现的脚本放到对应目录，就可以实现自注册，自加载。。

并且每个插件模块内部都有严格的作用域控制、沙盒化处理，非常安全，不会干扰到其他插件。。

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

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

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

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

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

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

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

明白了吗，是不是很有趣。。？

现在的开源项目越来越多，平台也越来越多，但是很多 c/c++项目的移植工作相当麻烦，不同项目编译方式区别很大，平台支持力度也各不一样。。

而我们平常移植后，基本上只能自己使用，没法分享给别人

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

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

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