buildc在发布0.1.0版时并没有做好安装脚本，当时的建议是直接下载0.1.0的源码包或svn export/checkout源码包，并手工将buildc目录位置加入到用户的PATH环境变量中。近期buildc计划正式投入到项目中使用，为了方便大家安装以及以后的统一升级维护，我花了些时间给buildc加上了setup脚本。

Python有标准的程序分发方案，不过我对这些了解不多。buildc本身很简单，我觉得没有必要把安装做得很复杂，所以就自己动手编写了一个setup.py，不到100行，用于安装buildc。

Python的标准安装脚本也叫setup.py，我这里也借鉴了这个名字。有了setup.py，buildc的安装就简单多了：
* 下载buildc Release包(当前最新是buildc-0.1.1)
* 解压发布包，在发布包路径下，执行setup.py install [--prefix=YOUR_INSTALL_PATH]

setup.py默认将buildc安装到/usr/share/buildc下面，并在/usr/bin下建立一个到/usr/share/buildc/buildc脚本的符号链接(symbol link)，当然这种安装是需要root权限的，但一旦安装好，host上的所有用户就都可以使用buildc了，日后统一升级buildc也十分方便；如果你不想在默认路径下安装，可以通过–prefix=XXX指定你自己的安装路径，这种情景下，setup.py不会建立什么符号链接，需要你手动将你的安装路径加入到你的PATH环境变量中，以便后续使用。

卸载buildc也十分方便，执行一条"setup.py uninstall [--prefix=YOUR_INSTALL_PATH]即可。

setup.py的安装原理很简单，就是利用shutil包的copytree将buildc目录复制到指定目录下。shutil的copytree在Python 2.6以后版本中支持ignore参数，可以有选择的将buildc目录下的文件和目录复制到目标目录，比如.pyc文件或.svn目录本不应该出现在目标目录下，我们就可以通过ignore参数指定一个ignore_patterns来过滤掉这些文件或目录：

shutil.copytree(package_root, install_root, ignore = shutil.ignore_patterns('*.pyc', '.svn'))

但在Python 2.6版本之前，ignore参数是不被支持的，所以这里也留下缺憾，那就是如果你使用svn checkout方式下载源码包，安装的时候.svn等目录也会被安装到目标目录下，看起来别扭，但不影响您对buildc的使用。

虽然部门一直在做C应用，但这么多年来，在C应用的安装包制作以及部署方面做得还是很初级，可以说还没有达到规范的程度。各个产品线的C应用安装包种类多样，水平参差不齐：有些产品的源码包即是安装包，把源码包拿到生产环境下编译后使用；有的项目则将编译好的目标文件(.o)以及第三方库放在安装包中，在生产环境下重新链接生成可执行文件；有的组则稍微专业一些，安装包中放的是编译好的可执行文件，但在目标主机上安装和执行时也都遇到了一些问题，诸如运行环境中的第三方库版本号与程序所依赖的不一致等。

去年年底，我就将"C应用安装包制作和部署"的改进作为今年的一个工作重点。这两天我粗略地考量了一下这方面的内容，这里也简单地谈谈。

总的来说，摆在我们面前的有三个主要问题：
1、安装包的组织方式不规范，不统一；
2、安装包的制作方式不规范，不统一；
3、安装包的部署方法不规范，不统一；

好了，下面我们就来针对上述问题逐一说说改进思路（注意以下内容并非普适）。

一、安装包组织方式
在Linux平台上应用的标准安装包是rpm或deb，但这种安装包形式似乎不太适合我们这种C后台应用。我对rpm或deb安装包了解的不多，但印象中这类安装包的安装一般为完全安装，但我们的应用升级版本时多数为增量安装或局部替换，因此做成rpm或deb虽然看起来专业一些，但实际操作起来并不灵活，因此自定义的安装包组织方式似乎更符合我们的需求。

下面是一个安装包的组织结构样例：
INSTALL_PACKAGE/
      – install.sh
      – README
      – app/
           – foo-1.0.1*
      – env/
           – conf/
           – log/
           – bin/
           …
      – deps/
           – libs/
              – bar/
           – tools/
      – scripts/
           – deps_check.sh
           – …
      – others/

其中:
app目录下存放的是可执行文件;
env目录下存放的是可执行程序运行时所需要的目录结构，包括配置文件等;
deps目录下存放的是可执行程序运行时所依赖的第三方库以及一些工具;
scripts目录下存放的是安装包安装过程中所需要的辅助脚本;
others目录下可以存放无法在上述目录下存放的其他数据;
install.sh是总控安装脚本，可以用于在目标主机上安装app、完整安装运行时环境、安装依赖libs或工具，执行scripts下面的必要脚本。

这样的一种安装包格式比较灵活，我们可以根据需要通过install.sh安装可执行文件或某个配置文件或其他数据文件。将INSTALL_PACKAGE目录打包(.tag.gz or .zip)就得到了我们的安装包。

安装包命名是要符合一定规范的，也便于进行配置管理。一个典型的安装包命名规范：程序名-版本号-平台-操作系统-编译模式.tar.gz[.zip]，例如：
foo-1.8.3-x86-linux-64bit.tar.gz
bar-2.9.3-x86-solaris-32bit.tar.gz
zoo-1.3.2-sparc-solaris-64bit.zip

二、安装包的制作方式
以往的安装包都是直接基于项目源码库构建出来的，很多运行时目录、配置文件以及辅助脚本也都与源代码存放在一起，这样一来让源码库看起来很臃肿，二来一份源码控制无法对应部署到多个不同客户现场的安装包，也就是说不同客户生产环境下的配置、数据等都是不同的，但源码库只有一个，我只能保存一份配置，因此在生成不同安装包是似乎要临时修改，且无法将这些修改做版本管理。

我的一个想法就是将安装包涉及到的相关文件和目录从源码库中剥离出来，针对每个项目源码，我都会建立若干个安装包工程，安装包则是这些工程(project)的产物，且可以针对不同客户做有针对性的安装包修改和版本管理。记得Microsoft的Visual Studio就有单独的安装包制作工程模板，这里也算借鉴Visual Studio中安装包工程的思想了^_^。

下面是一个安装包工程的示例：
foo_INSTALL_Proj/
      – Makefile
      – distributions/
         – foo-2.9.3-x86-linux-64bit.tar.gz
      – src/
         – install.sh
         – README
         – app/
         – env/
           – conf/
           – log/
           – fifo/
           – bin/
           …
         – deps/
           – libs/
           – tools/
         – scripts/
           – deps_check.sh

         – others/
其中src下面的内容就是上面提到的安装包的组织，通过安装包工程我们就可以灵活控制安装包中的每一个元素，而对源码没有任何影响。

三、安装包的安装模式
有了前面两个问题解决作为铺垫，这个问题就很好办了。我们的应用大致有两种安装模式：本地安装和远程安装，实际上也是一回事。本地安装就是手工将安装包放在某个目标主机上，然后解压，并利用安装包中的install.sh来安装需要的文件；而远程安装多半是用远程控制工具将安装包上传到目标主机（可能是多台），并通过远程命令在远程主机上执行本地安装。

这里想到的一个改进就是在目标环境中部署应用前，首先执行一次部署约束检查，检查目标环境是否满足新应用部署和运行的约束条件。这在以前的部署步骤中是没有的，约束检测脚本可随安装包携带，比如放在scripts目录下。

总之，规范化的安装包组织形式、制作方式以及部署方式不仅是一种专业化的表现，它与一些自动化工具的结合还会促进团队或组织整体效率的提升
。