大型项目第三方依赖、公共库、源代码目录该如何管理？

2016/6/15镜像同步11 回复

去年开始，项目里一个模块尝试用go来做，没啥经验，目前项目的做法如下，拿出来讨论下 1. 第三方依赖不用go get，从github拿下来后，把.git目录删了，统一在源码目录建了个third目录来存放，避免多个人依赖的三方库版本不一致，感觉挺没节操的... 2. 源代码目录布局延续了C/C++的习惯，按大的模块来划分目录，举例来说基本上是这样的 src/ ├── apps │ └── imageserver ├── authmgr ├── common │ └── rpc ├── imagefunc ├── imageservice ├── stylemgr └── third ├── gomemcache ├── go-sql-driver ├── imagick ├── seelog └── toml 3. 每个目录下多个.go文件都是属于同一个package，目录下子目录中的文件属于独立的package，每个文件都配单独的_test.go 4. go test无法做到：一个package中有多个文件时只想测某一个文件的需求，所以搞了个比较复杂的脚本来干这个事，就是把这个文件中的case扫出来，用go test的过滤器去做，感觉也挺没节操的。。。 5. 多个repo之间如何维护公共库，目前还没想好怎么做 6. 编译时要通过ldflags来写入编译时间、版本号、owner啥的，也是搞了个脚本来做，不知道go有没有配套的类似cmake/automake的东西

订阅后，新回复会通过你的通知中心匿名送达。

9 条回复

nuanyangyang机器人#1 · 2016/6/15

我感觉go最败笔（或许从某些角度上来看是最成功）的地方就是没有虚拟机。如果和平台相关，链接的时候，二进制文件格式（Linux用ELF，但OSX用MachO，Windows用PE，都不一样）允许添加的元数据及其格式也是平台相关的。而且这些二进制文件格式都是为C语言设计的，如果是想通过C函数名查找函数入口，可以用符号表；换一个语言（比如允许多个函数叫同一个名字的C++）就不太好办了；换一个特殊环境就更麻烦了，比如C++的模块需要特殊的入口，以初始化所有的全局变量，ELF里有特殊的segment来储存这些入口的指针；而想要看一个模块里定义了哪些类型，就更不可能了，因为C语言从设计上从来没考虑过可以“反射”地查询这些元数据，比如一个二进制的程序里面有哪些Go的类型、函数。要想知道包里面有哪些“测试用例”，编译时还好说，编译器可以做很多”魔术“，但如果编译完了，看二进制包（如果是.so还行，如果是可执行文件，不知道行不行得通），就没有什么好办法了，比如用正则表达式匹配函数名。但Java和JVM容易得多。.jar包里可以放任意东西，而且也有著名的方式储存元数据。测试的话，通过annotation就更简便了，.class的格式是标准的，在什么平台上都行得通。

shmilyhx机器人#2 · 2016/6/15

不知道你用的什么版本，可能1.5以后的interval和vendor特性会对你有帮助。 test指定_test文件不就是测试单个文件么？最后一个是因为版本号和编译事件是变量的原因么？看看这个->http://www.atatus.com/blog/golang-auto-build-versioning/ 并没有什么配套的类似cmake的东西，不过大部分时间go guild就够用了吧，最多加个Makefile。可以参考下Docker的源码->https://github.com/docker/docker。【在 KajiRyouji 的大作中提到: 】 : 去年开始，项目里一个模块尝试用go来做，没啥经验，目前项目的做法如下，拿出来讨论下 : 1. 第三方依赖不用go get，从github拿下来后，把.git目录删了，统一在源码目录建了个third目录来存放，避免多个人依赖的三方库版本不一致，感觉挺没节操的... : 2. 源代码目录布局延续了C/C++的习惯，按大的模块来划分目录，举例来说基本上是这样的 : ...................

qyz0123321机器人#3 · 2016/6/18

Godeps也不错，可以把依赖打包到当前工作环境。但是这样的话项目目录就会很大。vendor 可能是一个比较好的方式。

bswgd机器人#4 · 2016/6/18

强烈推荐glide https://github.com/Masterminds/glide

qiuyesuifeng机器人#5 · 2016/6/19

同意 ls，这方面 golang 确实一直没有一个好的方案，除了自建私有 repo 之外，用的比较多的就是 godeps vendor glide，也有小部分使用 gopkg.in。我们是从 godeps 过度到 vendor，但是在使用过程中，也有蛮多问题，比如 init，package update等等，后续可能使用 glide。

qiukun机器人#6 · 2016/8/25

looks promising 【在 bswgd 的大作中提到: 】 : 强烈推荐glide https://github.com/Masterminds/glide

bswgd机器人#7 · 2016/8/25

【在 qiukun 的大作中提到: 】 : looks promising 目前来看最好的解决方案了

qiukun机器人#8 · 2016/8/26

那贵司怎么还在指导用 godep 呢（捂嘴笑【在 bswgd 的大作中提到: 】 : : 目前来看最好的解决方案了

inaadversity机器人#9 · 2016/8/26

src/ apps github.com 第三方依赖不是应该设置成submodule吗