标签 Python 下的文章

buildc 0.2.2版本发布

随着buildc在项目中的深入使用,开发和测试人员都提出了不少良好意见,让我们有些应接不暇了,这次的版本更新也是为了满足这些意见和建议。 由于忙于应对这些眼前的需求,原本0.3.0的改进计划也被推迟了一些。

buildc 0.2.2版本包含了两个主要修正。

* 增加了–ignore-error命令行选项

自从buildc cache相关命令严格区分–cmode=32-bit还是64-bit后,用户在使用过程中出现了一些新情况。比如某开发人员A负责两个子系统 subsys1和subsys2的开发,这两个子系统分别用到了lib1和lib2。subsys1是一个64bit系统,依赖lib1;而 subsys2是一个32bit系统。依赖lib2。这样开发人员A在自己的开发环境下要管理和缓存lib1和lib2。管理lib1时,用到的 是buildc cache update –cmode=64-bit命令,而管理lib2时,用到的是buildc cache update –cmode=32-bit命令。这时如果内部的二进制库服务器上没有lib1的32bit版本或者没有lib2的64bit版本,buildc cache相关命令就会执行失败。为了临时解决这个问题,我们增加了–ignore-error命令行选项,这样即便lib1无32bit版本 或者lib2无64bit版本,buildc cache相关命令执行不会失败,开发人员A开发环境下的subsys1和subsys2的构建也会顺利完成。

关于这个问题,后续期待在buildc 0.3.0版本或后续版本得到更好的解决。

* 增加buildc pack source –component=[src|deps|all]命令

通常情况下,我们是不需要在生产环境下做任何编译操作的。但有些特殊情况下,我们不得不将源码拿到生产环境下进行编译。之前使用buildc进行 源码构建的工程拿到生产环境下进行编译极为不便,因为生产环境下没有buildc环境,也没有依赖库的cache,因此我们的运维人员提出这样的 需求:提供一份可在生产环境下进行编译的source包。为了满足这一需求,我们针对setup工程进行了完善,对buildc的pack命令做 了扩充,使得buildc pack支持source打包。

buildc pack source支持三个component参数:src、deps和all。src意为源码包,包中只包含工程源码;deps是打依赖包,及包中包含的都是 工程依赖的对应平台的第三方库的二进制版本;all则是src和deps的合体,是一个全量的,在目标环境可直接编译的包。

buildc pack source输出的目标包内结构大致如下:

target-package/
    – deps/
        – lib1/
            – 1.1.0/
                – x86_64_linux/
    – proj_name
        – configure
        – Make.rules
        – Makefile
        – ….

前面说过,这个包在目标环境是直接可编译的,你只需执行:
$>./configure
$> make

在制作目标包时,buildc pack source命令就已经将Make.rules中的各种库的依赖信息按照目标包的结构做了调整。执行configure是为了根据目标环境对 Make.rules做最后的调整。

另外源码包仅携带对应目标平台的第三方库的版本,不会将所有平台的版本都带上。当然这样有利有弊。优点在于源码包的size不会很大;缺点在于, 如果生产环境有许多种平台的话,我们需要为每个平台准备一份源码包。

BTW,现在的buildc基本上由我们组的小兄弟wtz1989227一个人维护,包括buildc的manual更新,这次的更新也都是他一 个人的工作成果。小声的说一句:wtz1989227接触Python也为时不多,因此代码方面还有较大的改进提高余地。 

buildc 0.2.1版本发布

buildc 0.2.1版本是一个bugfix版本,修正了两个重要问题。

* 修正执行buildc pack –cmode=32-bit时无法创建32位安装包的问题

之前的buildc pack命令在打包安装程序时忽略了–cmode这个选项,这样即便传入32-bit这个参数,打出的安装包中的应用程序依旧是64位编译的。这次修正了这个问题,让buildc真正支持打32位程序的安装包。

* 修正buildc cache相关命令与cmode选项结合的问题

其实这是一个因当初设计考虑不周而遗留下来的问题。最初考虑buildc在一个Workplace下面要么只管理64-bit的库,要么只管理 32-bit的库,没有考虑支持两者都cache以及两者可分别管理。而现实开发中,我们的开发人员在自己的workplace下既有64位程序,也有 32位程序,这样在用到buildc时反倒比较麻烦,因此这次将buildc cache的管理命令与–cmode选项结合,做了新的定义:

   – buildc cache init : 根据.buildc.rc初始cache本地库,既初始下载64-bit库,也下载32-bit库;
   – buildc cache init –cmode=64-bit : 根据.buildc.rc初始cache本地库,只初始下载64-bit库;
   – buildc cache init –cmode=32-bit : 根据.buildc.rc初始cache本地库,只初始下载32-bit库;

   – buildc cache update :根据.buildc.rc更新本地cache库,既更新64-bit库,也更新32-bit库;
   – buildc cache update –cmode=64-bit:根据.buildc.rc更新本地cache库,只更新64-bit库;
   – buildc cache update –cmode=32-bit:根据.buildc.rc更新本地cache库,只更新32-bit库;

   – buildc cache upgrade :根据最新变更的.buildc.rc升级本地cache库,既升级64-bit库,也升级32-bit库;
   – buildc cache upgrade –cmode=64-bit:根据最新变更的.buildc.rc升级本地cache库,只升级64-bit库;
   – buildc cache upgrade –cmode=32-bit:根据最新变更的.buildc.rc升级本地cache库,只升级32-bit库;

   – buildc cache remove :根据.buildc.rc配置,删除本地cache库,既删除64-bit库,也删除32-bit库;
   – buildc cache remove –cmode=64-bit:根据.buildc.rc配置,删除本地cache库,只删除64-bit库;
   – buildc cache remove –cmode=32-bit:根据.buildc.rc配置,删除本地cache库,只删除32-bit库。

buildc 0.2.0版本发布

buildc的演进先后经历了构建管理安装包工程管理两个阶段。其中buildc的构建管理功能在项目中应用较早,目前相对稳定可靠。但其支持的安装包工程是直到最近才被大家所正式使用的。不出意料,大家在使用过程发现了一些问题,于是我们也是边用边改。

目前一个setup工程一般具有类似如下源码组织结构:

distributions/
setup.cfg
src/
    – README
    – app/
    – conf/
    – deps/
    – layout.cfg
    – others/
    – scripts/
    – setup.py

按照最初的设计,deps目录下会存放一些目标程序运行时依赖的库、工具等。但就一些细节并未考虑清楚,比如如果一个程序需要在两个平台(linux和solaris)上运行,那deps下的依赖库应该如何存放?

就这个问题一线的人员在设计setup工程时采用的策略是将某个库的所有平台版本都手工放到deps下,以instantclient这个oracle的客户端库来说,就形成了如下结构:

deps/
    – instantclient/
        – 10.2.0.5.0/
            – x86_64_linux/
                – lib/
            – x86_64_solaris/
                – lib/

这样一来安装包制作完后size非常的大,不便于存储和传输。另外手工copy依赖库显然不够专业。打包过程是buildc来完成的,而buildc是拥 有全部依赖库的存储位置、版本等信息的。于是我们就这个问题做了改进,让buildc 0.2.0支持将依赖的第三方库根据目标程序运行平台类别自动打包到最终的安装包中。

也就是说,如果你是为x86-64 linux平台做的安装包,最终安装包中的目录结构会是:

deps/
    – instantclient/
        – 10.2.0.5.0/
            – x86_64_linux/
                – lib/

而这一切仅需通过配置完成。在setup工程顶层目录的setup.cfg文件中,我们增加了一个新配置项,用于描述目标程序运行时依赖哪些第三方库,这些库将被打包到安装包中,并部署到目标主机上去。

配置的格式如下:

dependences = [
    ("instantclient", "10.2.0.5.0", ["libclntsh.so", "libclntsh.so.10.1", "libnnz10.so"]), # 打包指定的库文件
    #("instantclient", "10.2.0.5.0", []), # 打包instantclient/10.2.0.5.0下所有的库文件
    #("instantclient", "10.2.0.5.0"),     # 打包instantclient/10.2.0.5.0下所有的库文件
]

通过例子可以看出dependences中的元素支持三种形式配置,可以指定打包的库文件,也可以将库目录整体打包。

BTW,buildc自从发布以来一直没有user guide,好消息是项目组的小兄弟wtz1989227已经在wiki上建立了buildc_user_guide页面,后续他会逐步完善这个guide的。




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

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

如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多