随着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的目标！