标签 GNU 下的文章

buildc 0.1.9版本发布

随着buildc使用的深入,越来越多的新需求暴露了出来。为了满足这些需求,我们组的小兄弟又对buildc进行了一些改造,这些变化如下:

1、支持将多个子工程打包到一个安装包中

最初buildc的设计思想是为每个子工程单独制作安装包,这样具有很强的灵活性。但在对现有N个工程进行构建脚本改造的过程中发现,有些工程间存在严重 依赖,比如工程A是一个业务级公共库工程,工程B和工程C都依赖工程A构建后生成的静态共享库。而工程A又无法被当成第三方库处理,这给我们的安装包构建 制造了难题。我们的解决方法就是改造安装包工程的setup.cfg文件,让其支持多source。从正规语义上来讲,我们这么做将使得buildc支持 将多个子工程打包到一个安装包中,而间接的作用则是解决了上述有依赖关系的工程安装包制作的问题,虽然看起来不那么美。

修改后,setup.cfg中配置就变成下面这种情况了:

source = [
  {
     "trunk"          : "svn://10.10.15.56:4444/cn/trunk/A",
     "binary_prefix"  : "fooA"
  },

  {
    "trunk"          : "svn://10.10.15.56:4444/cn/trunk/B",
    "binary_prefix"  : "fooB"
  }
]

不过问题并没有彻底解决。A工程的构建结果是一个.a文件,按照原buildc处理流程,该.a文件会被放入安装包中的app目录下,但这不是我们想要 的,.a文件是不应该放入安装包的。与此同时,一些子工程的输出是.so文件,按照最初的规划,这些.so文件应该被放入deps目录,而原buildc 默认都是放在app目录下。为了解决这个问题,我们给source做了"属性扩容" – 增加了一个可选的pack_path字段。

source = [
  {
     "trunk"          : "svn://10.10.15.56:4444/cn/trunk/A",
     "binary_prefix"  : "fooA"
     "pack_path" : ""
  },

  {
    "trunk"          : "svn://10.10.15.56:4444/cn/trunk/B",
    "binary_prefix"  : "fooB"
  },

  {
    "trunk"          : "svn://10.10.15.56:4444/cn/trunk/C",
    "binary_prefix"  : "fooC"
    "pack_path" : "deps"
  }
]

这个示例中,A工程pack_path的值为"",buildc将忽略A工程的输出文件,B工程没有配置pack_path,则buildc默认将B工程 的输出文件放入app目录;而C工程明确为pack_path赋了值,buildc会将C工程输出文件放入deps目录。

buildc原本支持在命令行输入工程源码库地址(–tag=YOUR_SOURCE_TAG),现在依旧支持。一旦命令行指定了工程地 址,buildc将不会理睬setup.cfg中source中配置的各个源码库路径,将从命令行指定的工程地址处取得最新源码,但暂无法指定 pack_path,默认会将构建结果放入app目录。

2、打包时自动生成VERSION文件

buildc在执行pack build后,自动在安装包中生成一个VERSION文件。该文件中包含与安装包匹配的平台信息(包括CPU体系、OS类型等)以及构建时的一些版本信 息。该文件除了便于安装包使用人员查看安装包相关版本信息之外,还可以用作安装包在目标平台进行约束检测的依据。如果你的安装包是for x86-64 linux的,那么宕操作人员误将该安装包部署到Solaris 10 for sparc平台时,安装包中的deps_check.py脚本会比对当前平台信息与VERSION文件中携带的信息,发现不匹配,则报错并停止程序的安 装。

3、其他

该版本buildc还提供了一些脚本的详细示例,如env_gen.py、deps_check.py。另外从Make.rules.in模板中去除了硬编码的-D_DEBUG定义。

buildc 0.1.8版本发布

buildc这个小工具逐渐在项目组内部扩大了使用范围,还有一名专门的同事负责为每个项目制作安装包工程,这样也可以在使用中发现buildc的问题。

本次buildc 0.1.8的相关修正以及新增的feature就是我的这位年轻同事一手操刀完成的,他也是一个python新手,同样也是边翻手册边进行编码的。这次改动主要集中在templates目录下的几个文件,这里的文件多为因工程的不同而异的。

这次buildc主要的功能点改动如下:

1、删除Make.rules模板中的FOPTIMIZE变量

原先在模板中将FOPTIMIZE变量的值写死为o2。但在实际应用中,不是所有项目都会使用o2优化级别,通过在buildc.cfg中自定义变量也可以达到同样的效果,因此这里删除了该变量。

2、为setup.py.in增加了backup功能、log facility等

setup.py.in这个文件改动较大,主要包括:

- 在setup.py.in这个安装包模板中增加了backup命令,用于将目标服务器上运行的老版本应用环境进行打包备份处理。该命令支持两个参数all和conf,分别用于备份打包全部环境和打包配置文件目录;

- 将setup.py中原install命令的参数full改为'all';

- 为setup.py的执行过程增加了log facility,可以在"install_时间戳.log"中看到所有详细的安装过程;

- 当目标路径存在与安装包要安装的文件同名的文件时,setup.py.in会自动生成这两个同名文件的diff,供安装人员后续手动进行冲突解决。

3、提供一个deps_check.py的更为详尽的参考实现

deps_check.py是用于在目标环境进行环境约束检测的,十分必要。

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看起来和用起来都更舒服些。




这里是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


文章

评论

  • 正在加载...

分类

标签

归档











更多