标签 Subversion 下的文章

buildc 0.1.7版本发布

最近针对buildc又有了一些新想法,于是今天上午又对buildc进行了多处修改,并相继发布了0.1.6版本和0.1.7版本。

 
一、0.1.6版本的主要改动点
 
* 对buildc cache upgrade的实现进行了修改。
在执行全量更新本地cache前,先对本地cache的情况进行一些检查,并判断是否与当前.buildc.rc中的配置相符。如果两者是一致的,那么只进行update操作;否则则执行真正的upgrade(remove and re-init)。
 
* 调整了整个buildc源码目录的结构。
原先所有代码都放在build_utils目录下,这次我把代码分为两类:一类是核心逻辑(core);另外一类则是工具库类(utils),因此我删除了build_utils目录,同时增加了core和utils两个目录,分别存放不同类别的源文件。
 
在进行这项改造时遇到了一个小问题,那就是Python模块(比如core模块)中的源文件导入(import)另一个同级别模块(比如utils模块)中的符号的问题。以core模块的core.py为例,core.py中导入了env文件中的符号。原先core.py和env.py在同一个模块(build_utils)下,直接import env即可;但现在core.py和env.py分别放在了core和utils目录下,直接import env就会出现导入错误。这里涉及到了Python的模块搜索路径(sys.path)。默认的sys.path只是包括执行脚本的当前目录以及一些Python相关的安装目录(比如/usr/lib/python2.6、/usr/local/lib/python2.6/dist-packages等)。这样Python解释器无法找到core.py所在目录的上层目录utils下的env.py文件。为此我们需要在sys.path中增加一个路径,即'..',core.py文件的代码截取如下:
 
import sys
import os
import shutil
 
sys.path.append('..')
 
from utils import env
 
这样Python解释器就可以在core.py所在目录的上一层目录下寻找模块了。
 
* 将samples中的模板文件统一移到了templates中,删除samples目录
最初设计templates目录下只存放Make.rules相关模板文件,当时考虑的是支持多Make.rules模板。但目前只考虑支持一种,至少目前是这样(也许后续会有变化,但不能肯定),而samples目录下的文件其实也都是各种配置模板,因此将两个目录合二为一。
 
二、0.1.7版本的主要改动点
 
* 修改buildc init的执行语义
原先buildc init在初始情况下会在$(HOME)目录下创建.buildc.rc以及在当前目录下创建buildc.cfg;.buildc.rc是用户级别的配置;而buildc.cfg是项目级别的配置,放在一个init里显然有些不合适,因此0.1.7版本及以后版本在执行buildc init时只会创建$(HOME)/.buildc.rc。
 
* 增加buildc config init
对于项目级别的配置bulidc.cfg,我们使用新命令buildc config init来创建,即初始化一个项目级别的配置。
 
* 用buildc config make替代buildc config-make
顺水推舟,我们去掉了config-make这个command,进而改用buildc config make来生成或重新配置Make.rules文件。
 
做完以上修改后,感觉buildc看起来和用起来都更舒服些。

buildc 0.1.5版本发布

这两天对buildc的改动比较频繁,今天又修正了一些问题,也增加了一些小功能。主要包括这么几点:

 
1、在Make.rules.in中增加了STATIC_LIBS和DYNAMIC_LIBS
 
项目源代码和项目中单元测试代码使用同一个Make.rules,也此编译时也就共享同一个LIBS变量。对于静态共享库还好说,但对于动态共享库,诸如Oracle的instantclient库,单元测试代码中即使没有使用到动态共享库中的接口,也要对该动态共享库产生一个依赖。这样在执行单元测试用例时就会因无法寻得动态共享库而导致用例执行失败。
 
为此,我在Make.rules.in中增加了STATIC_LIBS和DYNAMIC_LIBS两个变量,即将原LIBS变量中的静态共享库和动态共享库分开,分别放入STATIC_LIBS和DYNAMIC_LIBS中。然后让项目中单元测试代码的编译只依赖STATIC_LIBS,上述问题就得到了解决(如果你的单元测试真实需要链接动态共享库,那就另当别论了)。
 
2、添加system_libs,并进一步明确了external_libs、custom_libs和新增的system_libs的含义
 
buildc设计之初,设计了三种lib:external_libs、custom_libs和default_libs,最初的设想是这样的:
 
  * external_libs – 一般配置第三方库或组织内部公共库;
  * custom_libs – 项目相关的C运行库和*nix系统库依赖库,或一些项目内部实现的库;
  * default_libs – C后台应用一般都需要链接的C运行库和*nix系统库,惯例优于配置,直接写死在代码中。
 
但实际运用时发现,custom_libs如果既配置C运行库或*nix系统库依赖库,又配置一些项目内部实现的库,会存在静态共享库依赖顺序问题,另外custom_libs与external_libs之间也会因此而存在库链接顺序之问题。而default_libs目前为空,因为很难找到各个项目的一般依赖。
 
于是这次我对这个设计进行了一些修正,增加了SYSTEM_LIBS,并进一步明确了这些lib配置的含义,依顺序如下:
 
  * custom_libs – 一般配置项目自实现、自用的库,可能包含在项目源码库内部,与项目源码库一并发布;
  * external_libs – 一般配置第三方库或组织内部的公共库;
  * system_libs – 用来替代default_libs,配置项目需要的C运行时库或*nix系统库,放在所有库的最后面。
 
default_libs似乎没有太大必要了,后续也许会从代码中remove出去。
 
3、增加cache upgrade
 
通过实践发现,目前buildc提供的对本地缓存的Library的管理手段还有欠缺,特别是当.buildc.rc发生变更时,需要执行buildc cache remove和buildc cache init才能正确完成更新,稍显繁琐,因此今天给buildc增加了一个cache upgrade命令,用于改善这个情况。而buildc cache update一般仅用于.buildc.rc的库配置没有改变,但subversion库中的库二进制文件被更新(比如重新制作了)的情况。这样看来还是.buildc.rc变更的情况常见些,比如某个库的版本升级了(例如,lcut从0.2.0升级为0.3.0),或某个库的位置发生了变化,或删减了某些库或新增了某些库等等。
 
以上就是buildc 0.1.5版本的所有改动了。
如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats