下面是对gsmake的设计初衷及2.0的一些想法，欢迎讨论。

版本是个问题

动态库陷阱：做过linux/c/c++开发的人都知道，处理依赖库是一件棘手的事情——不仅需要检查库是否已经安装，严谨的做法还必须检测库的版本。当我们在开发机上配置好了编译环境以后，在部署到生产环境的时候还需要再来一次这个过程。考虑部署服务器增加到1000台或者更多，这个问题就变成了不可能完成的任务。

java包依赖：在很多大型java项目里面，需要依赖若干三方jar包。很多人都遇到过这种情况：程序在开发机上跑得很欢快，放到生产机上就熄火了。调试很久发现是一个依赖jar包在生产机和开发机上版本不一致;或者更严重是项目加载了同一个jar包的两个不同版本。。。。。

go get陷阱：在golang里面用go get 获取一个远程包，会自动获取其依赖包。问题来了：这个依赖包的版本是不确定的，对于git仓库来说是其master分支。假如A包的开发者push了一个新版本到服务器上，这个新版本的接口破坏了向下兼容，那么所有引用这个包的项目都会编译broken。在知乎上和人讨论时，一个朋友认为这个问题应该是库的发布者的责任：如果破坏了向下兼容那么他应该新开仓库来避免上述情况。先不说这种解决方案对资源的消耗(github上建仓库虽然免费，但是还是不要滥用的好)，在我看来这种靠人来保证的事情，本身就是没有任何保证。并且更奇怪的是一个库的使用者居然没有指定使用版本的权利，golang的一些设计果然是够奇葩的(听说golang在1.6版本会带来一个内建的基于版本的包管理机制)

我将上述几个问题的解决方案称作包管理系统，其实已经存在的一些包管理系统：比如手写部署脚本或者现在流行的docker都能一定程度上解决问题；以及java生态环境在这方面做的很多有益的尝试：maven,gradle,sbt

这个问题的核心在于——构建一个对于特定应用独立的开发部署环境；它潜在的含义还包括同一个应用的不同版本之间的开发部署环境也需要独立。

包管理系统

在我看来，一个完善的包管理系统应该具备以下特性：

• 为程序包生成独立的开发/部署环境；
• 程序依赖包中，不能同时依赖/间接依赖一个包的多个不同版本；
• 与现有源代码管理工具：svn、git、hg 等等集成；
• 拥抱github这样的开源网站，抛弃中心库概念；
• 显式的版本依赖——依赖于源代码管理工具的版本管理/依赖；
• 版本映射,允许通过全局配置对包版本进行映射；
• 自举,包管理系统本身应该是被“包管理系统”管理；
• 可插拔的包管理系统，包管理系统本身应该是可扩展，可编程的。

说了一大堆关于包管理系统的东西，那么下面来看看包的定义是：

一种资源管理的方式，它是版本化管理的最小单元。包的内容可以是各种语言编写程序源代码，或者是一些其它资源文件——总之任何你想管理的基于文件的资源都可以放入包里。包可以有依赖，并且严格按照url/version引用；

如前所述，已存在的解决方案或多或少都不满足上面的定义；在这里引出gsmake——一个完整支持上述特性的包管理系统——后面用gsmake来代替包管理系统进行描述

可运行的包

如果gsmake只是简单的将包下载到本地，那么它就太不敏捷了——对于敏捷开发深入人心的当下,一键/编译/测试/部署是基本要求；

gsmake通过包管理系统插件来实现自动构建；

gsmake通过可运行包的概念来实现包管理系统插件；首先需要明确的是：gsmake由golang开发，相应的
可运行包由golang语言实现——一个go语言包；

可运行包：

由go语言开发，包含了若干task的gsmake包；

如上所属，gsmake通过插件来实现诸如：编译c++动态库、java包以及生成安装包，自动部署等任务；这里涉及到一个任务的先后顺序问题——task可以指定它的前置任务。

算法：

task的排序过程，是一个典型的有向无环图的拓扑排序过程，可以看这里了解这个算法 的具体描述(吐槽一下，你国wiki又被屏蔽了。只能将就用下SB百度百科)；

虚拟文件系统

如何设计gsmake的核心编程接口，在1.0版本阶段其实是很混乱的。这次重新思考我发现其实将gsmake的核心部分设计成一个这样的vfs系统其实是合适的：

• 每个应用都有一个独立的vfs，应用包以及依赖包对应于vfs的文件节点（目录）；
• vfs支持域，域之间的文件节点保持独立；
• 版本化目录节点；
• 目录节点可以被mount;
• 高级目录操作接口：clone、update、commit；
• vfs底层数据被映射为操作系统文件/目录；

独立的vfs，意味着应用包之间是不会相互影响的——即使依赖的包名称相同/版本相同；

域：相当于在vfs的基础上再增加了一层隔离机制；在一个自动构建的过程中，软件在构建的不同阶段依赖的包有可能是不一样的，这里就需要使用域来隔离这些不同的包；

目录节点可以被mount这点非常重要：

• 正在开发的应用程序包，可以被mount到vfs上。这样golang程序包可以不必放入GOPATH/src目录下；
• vfs被认为是一个分布式文件系统，gsmake包被host在不同的站点上，并被不同的SCM管理；对于每类
  SCM都被当成一种文件系统，被挂接到vfs目录节点上。

在高层界面上vfs被当成一种高度抽象的版本管理系统，它的管理单元是目录而不是通常意义上的文件：

• clone：vfs并不支持目录创建操作，clone操作在vfs底层被转化为mount操作；
• update：为了提高操作性，vfs对远程包进行了cache操作。update命令对cache内容进行更新；
• commit：将修改同步到全局cache/远程站点（如果有权限）；

本机缓存：如前所述，vfs本质上是一个分布式文件系统。为了提高可操作性，设计了一个本机缓存机制同一台物理机共用这个缓存系统；挂接到这个rootfs上的文件系统可以重用这个全局缓存机制来加速一些操作；

任务与构建生命周期

gsmake本质上是一堆任务的集合，这些任务又组成构建生命周期；gsmake内建的生命周期只有两个：

• 编译任务：gsmake根据当前应用包的元数据，准备编译任务阶段依赖的数据包；并且编译生成任务执行器；
• 执行任务：这个阶段gsmake运行上一阶段生成的任务执行器，执行任务；

正如本文第三段描述的那样，gsmake的生命周期可以被gsmake包本身扩展；计划中的扩展包有：

• c/c++、golang、java构建支持；
• gsmake包到visualstudio、eclipse、xcode项目的转换器；
• android/iOS/WP项目开发支持；
• docker集成支持；

脑洞大开：基于版本的包管理与任务/构建生命周期的结合可以让gsmake成为一个通用的自动化处理平台——并不一定是软件构建过程——所有基于任务和流程的处理过程都可以用gsmake来开发。从这个角度来说gsmake是一个加强版批处理脚本系统；