gb,gb 是一个 golang 的项目构建工具。gb 的目标是没有蛀牙……
gb 的人生四个目标:
- 基于项目的工作流程
- 自动探测项目
- 0 配置文件
- 在 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
?
网友评论