gb

gb，gb 是一个 golang 的项目构建工具。gb 的目标是没有蛀牙……

gb 的人生四个目标：

1. 基于项目的工作流程
2. 自动探测项目
3. 0 配置文件
4. 在 Windows 上工作

3、4 都比较好理解，借助 golang 的特性，大部分 golang 程序都可以在 windows 上中跑得不错，当然需要小心处理一些跨平台带来的问题。1，还好吧；2 估计就是自动识别项目中的包包了。

golang 原来的工作流程是搞个地儿，然后再占个坑（$GOPATH），再接着事情就在这个坑里办完了；吃喝……都这里面，够乱了吧。

golang 1.5 开始又搞了一个实验性质的 vendor 机制，不过基本上也是围绕 $GOPATH 搞的。

之前用着无闻先生？造的 gopm。gopm 的优点是可以直到 github 世界，没有红杏、没有梯子，真正的直到 github 世界。另一个优点是保持 $GOPATH 干净，因为默认情况下 gopm 下载回来的包包是在 ~/.gopm 目录下的。使用方法也相当简单：

go build => gopm build
go get => gopm get

就是这么轻松这么愉快。不过有时 gopm build 会不好使；这是怎么办呢？首先是 gopm get -g 然后再 go build 就可以了。-g 的作用是将第三方包下载到 $GOPATH 中。

所以 gopm 多少还是有一些问题。

回到 gb。

gb 的项目基本上还是 golang 风格：

% gb build all
hello
% bin/hello
Hello gb
% tree $PROJECT
/home/dfc/code/demo-project
├── bin
│   └── hello
└── src
      └── hello
           └── hello.go

自己的包这里：

$PROJECT/src/

别人的包在这里：

$PROJECT/vendor/src/

gb 文档也特别提到版本管理的问题，最好是将 $PROJECT 加入的文件仓库中，注意需要忽略 $PROJECT/bin 和 $PROJECT/pkg 中的文件，这两个文件夹实际是编译好的二进制文件，和 golang 中的项目规范是同样意义的。

gb 提供了一个不错的插件：gb vendor，一个用于管理项目 vendor 的工具。

如果单纯从第三包管理这个问题上来讲，gb 还不如 gopm 好使。与 1.5 机制比起来，gb 的 vendor 是在项目 $PROJECT 目录下，起码看起来还是正常的；1.5 的 vendor 机制还是比较奇怪。

不过最大的悬念是为什么 golang 需要 $GOPATH？