make后期发展随想

2016-06-26 10:20:00

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

关键字：交叉编译, 跨平台构建, makefile, cmake

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击举报进行投诉反馈！