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的目标!




本文采用CC协议发布,原创文章,转载请注明:转自于IMCN

本文链接地址:xmake后期发展随想

相关文章

  • Linux运维工程师真实的工作状态到底是怎么样的? 0条评论       2017-01-19
  • 为什么2017年之后操作系统仍将扮演重要角色? 0条评论       2017-01-19
  • Let’s Encrypt 2016 这一年。 0条评论       2017-01-17
  • 15款顶级的开源人工智能工具推荐 0条评论       2017-01-16
  • 想要学习Linux技术,先好好的读一本Linux书籍吧。 0条评论       2017-01-15
  • 女生可不可以进入IT行业做Linux运维工程师? 0条评论       2017-01-12
  • [Ctrl + Enter]

    分享按钮

    无觅相关文章插件,快速提升流量