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的。

Go语言目前(截至1.0.2版本)尚不支持直接链接.a文件(这里的.a文件指的不是传统静态共享库，而是对golang的非main包build后的产物)。这样一来Go的第三方库包或组织内部的公共代码库包只能以源码的形式分发了。

Go提供了get命令用于获取他人分发的代码包。我们通过get命令既可以获取一些知名代码托管站点上的代码，也可以获取组织内部版本控制服务器上的公共代码。

Go get支持的托管站点包括github、google code、BitBucket以及Launchpad，针对这类情况，我们可以得到“特殊”语法的照顾：

go get github.com/bmizerany/assert
go get bitbucket.org/bmizerany/assert
go get code.google.com/p/assert
go get launchpad.net/assert

由于Go已经“内置”了github、google code等的版本控制工具类型，因此我们无需再做任何额外指定，只需用代码的url（去掉http://）即可。

执行get后，代码会被下载到GOPATH环境变量配置中的第一个路径下的src目录下面。例如：我们的GOPATH=/home/tonybai /goworkspace1:/home/tonybai/goworkspace2，执行go get github.com/bmizerany/assert后，我们将在/home/tonybai/goworkspace1下看到github.com 目录，而assert包在本地的完整路径就是/home/tonybai/goworkspace1/github.com/bmizerany /assert。这样我们在代码中直接import "github.com/bmizerany/assert"即可使用assert这个第三方包了。

在组织内部我们也会有自己的私有公共代码库，一份代码库可能被多个项目所使用。在每个项目中都保存一份公共库代码显然是不利于后续版本升级维护的，这样就需要各个项目统一从同一个地方获取或更新公共库代码。这种情况我们同样可以用go get命令来做。

假设内部使用subversion作为版本控制工具，公共库架设在10.10.12.13/svn0/share/golib。这时我们不能简单地的通 过"go get 10.10.12.13/svn0/share/golib"来获取到代码，我们需要告诉get我们采用哪种版本控制工具，而这种信息的传递是通过在库名称后面加上后缀的方式进行的。比如：

go get "10.10.12.13/svn0/share/golib.svn"

这样在/home/tonybai/goworkspace1下就会出现10.10.12.13/svn0/share/golib.svn目录结构。我 们在代码中可以直接import对应的包，比如import "10.10.12.13/svn0/share/golib.svn/assert"。

通过对get命令特性的了解，我们也可以确定分发的代码包到底应该如何组织。从上面的例子我们可以看出我们分发的代码包结构不需很复杂，直接在库的 repository下建立包目录即可，比如上面例子中库repository为golib，assert就是直接建立在下面的目录，同时也是包名。

go get可自动识别http_proxy环境变量，这样Go也可以通过代理获取外部代码包。

使用外部代码包的项目可以通过go get -u url来更新代码包版本为最新版本。