gb

作者: 彩色的铅笔盒 | 来源:发表于2015-10-07 23:54 被阅读0次

    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

    相关文章

      网友评论

          本文标题:gb

          本文链接:https://www.haomeiwen.com/subject/sfkncttx.html