看到一篇文章不错：
http://harttle.com/2015/05/29/pkg-manager.html
包管理和构建系统是现代的软件开发团队中必不可少的工具，也是Linux软件系统的常见组织方式。 现代编程语言大多给出了自己专用的包管理和构建系统，那么本文便来总结一下小编用过的那些包管理和构建系统。
JavaScript
服务器端 Javascript 通常使用NPM作为依赖管理工具。
- 通过NPM提供的
npm命令来进行依赖的下载、升级和移除。 - 通过
package.json来定义软件包的元信息、开发依赖（开发或测试需要）、部署依赖（运行时需要）。 - 依赖递归地存储在
node_modules中。 - 依赖在项目之间是隔离的，全局安装（
-g）会使它成为命令行工具而不是全局依赖。 > 递归的依赖下载风格使得NPM的缓存及其重要。缓存位于~/.npm下，这里保存这.tgz格式的包文件。
JavaScript 通常使用 Grunt 进行构建。
- Grunt通过插件来完成任务，每个插件相当于Makefile的一个命令。
- Grunt任务定义在
Gruntfile.js中。 - NPM提供了众多的Grunt插件，当然你也可以手写。
- Grunt任务继承了JavaScript的异步特性。
前端 lib
前端 lib 可以通过 Bower 来下载。Bower 不仅可以下载已注册的软件包，还可以下载Github Repo，甚至是一个文件的URL。
- 通过
bower命令进行依赖管理。 -
bower.json定义了软件包的元信息与依赖。 - 依赖所在路径可以在
bower.json中进行设置。 - Bower只是一个命令行工具，你需要在正确的路径执行Bower命令。
Bower可以灵活地下载各种依赖，但它的缺点也是明显的：未注册的软件包往往包含冗余的非生产环境的代码，有时甚至需要手动构建。
Java
Maven是基于项目对象模型(POM)的项目管理工具，通过文本文件来描述项目的版本、URL、License、依赖等信息。
- 通过
pom.xml来描述Maven项目。 - Maven是项目管理工具，其功能包括依赖管理、软件构建。
- Maven通过
.properties文件和命令行参数读取系统特性。
Ant是由Java写成的编译、测试和部署Java应用的命令行工具。
- 通过
build.xml来描述构建过程。 -
build.xml的逻辑类似Makefile，每个target由命令和参数构成。 - 通过命令行参数来读取系统特性。
Gradle是一个基于Apache Ant和Apache Maven概念的项目自动化建构工具。它使用一种基于Groovy的特定领域语言来声明项目设置，而不是传统的XML。
Python
Python的包管理工具能讲一整天的故事：distribute、setuptools、distutils、easy_install、pip、distutils2、packaging、eggs、wheels、pyvenv、virtualenv……
这也是我为什么讨厌安装python软件的原因，与此同时，旧版本的python2比新的python3更加流行以及两者不兼容也常常给Linux包管理造成麻烦。
现在开始讲故事：
- distutils是python的标准库；
- setuptools试图完成distutils缺少的特性而开始开发；
- easy_install是setuptools的命令行接口，有更多的特性;
- 在setuptools的开发过程中产生了分歧，于是出现了distribute，它fork自setuptools，并在2013年取得和解并重新merge到setuptools 0.7版本；
- 相比于上述工具，pip是一个更加高阶的接口，pip成为事实上的python软件的安装工具；
- eggs和wheels成为事实上的二进制python软件的安装工具。
venv和virtualenv则是用来创建python虚拟环境来实现应用隔离的。
- venv在python3.3中引入，用于在自己的目录下创建轻量级的虚拟环境，也可以孤立于系统环境。
- virtualenv则是一个python软件包，用于创建孤立的python环境。
Ruby
Ruby的软件包单元为RubyGem。
- Gem由
.gemspec文件描述。 - Gem的构建过程由
Rakefile描述。 - Rake是Gem的构建工具，它与Make类似，用以完成自动化测试和代码生成。
- Bundle则是Ruby的包管理工具，用来跟踪和下载正确版本的Gem。
Miller Nether 新版知乎客户端不错
44 人赞同
此问题相当有价值，我认为我会持续更新。已经将不严谨的“二进制”和“源代码”更换为更为严谨的描述"as is"和"source"。 我欢迎各类程序员和我一起探讨这个问题。 先说结论：c/c++和其他语言不同，要管理c/c++的包，你需要管理的不是"as is"，而是"source"。写程序的人需要的包管理器，和管理系统的人需要的包管理器是不一样的。 npm/apt/yum之类的包管理器的特点主要是"as is"，也就是下载下来就可以用。这样子对于C++来说是非常非常难以做到的，比如： 1. Windows下的MT/MTd/MD/MDd我无法解决。换言之，如果要通用，Windows 32bit就要至少提供四套binary。更加烦的是从Visual Studio 2012开始还需要指定XP兼容性。此外Debug Info指向的cpp文件是绝对路径，也就是换个电脑你只能手动指定源文件的位置。 2. Linux下的binary也有区别，举个例子，有RTTI和没有RTTI的代码是没法链接在一起的。 如果我需要要做到"as is"，我不单单需要为不同的系统、配置提供不同的binary，还需要为一些编译选项提供不同的binary。于是一个版本，我将提供几乎数不清的binary，因为不同的配置、系统、编译选项之间还可以做笛卡尔积。更何况，只有binary并不能调试，Debug Info通常占用的空间会比binary更加巨大，常常可以做到几个G，单单是压缩这些Debug Info就会耗费几十分钟的时间，对于包发布者来说，是个巨大的压力。 此外，C++由于其复杂的历史原因，造成了复杂的依赖项，有的依赖perl，有的依赖于python，。这些项目的历史悠久，有无数数不清的坑。想要做到"Modern"，不是不想，而是实在是做不到。比如LLVM和Clang，已经算是这些项目中非常优秀的项目了，历史包袱也不是非常多，代码非常优秀，模块化，可是做了不知道多久还没有彻底从Autotools迁移到CMake。这些复杂的依赖项是没有办法说直接"as is"使用的，因为他们的目录的位置并不是遵循一个统一的标准，如果说有一个统一的标准，那么C++的包管理器会好做很多。 同样的问题，出现在同样历史悠久的PHP身上。PHP本身有非常多的坑，这个就不细说了，而Composer花费了近10年时间才逐渐将PHP变成了现在这个Modern的样子（当然还有PHP自己的努力）。 有C++包管理器尝试说要求每个添加进库的项目都必须是符合规定的，例如，比如使用CMake。很不幸，目前C++领域最多人用的包管理器是这个思路。CMake非常优秀，然而正如我上面所说。但逐一纠正每个包，几乎是不可能的。我认为更实际的做法是，为每个包写一个编译配置，只需要编译好的头文件和二进制符合规范即可。我们必须要兼顾到C/C++悠久的历史所导致的无数的编译环境，例如autotools, CMake, gyp, ninjia。 最近很火的Rust的包管理器Cargo，所使用的方法，如我所使用的一样，是将源代码包"as is"下载下来，在编译的时候，优先编译dependencies。我认为这是比较符合实际的做法，它避免了我所上面列举的一些问题： 1. Binary的规则太细并不互相兼容：重新编译可以保证编译选项是兼容的。
2. 所依赖的包太多历史包袱，无法兼容新的标准：即时编译以后将编译好的二进制和文件按照统一的规范存储到新的位置。 Rust的Cargo的一个问题是要求必须使用Rust的脚本编译，而不是Shell。这样子对于我们来说也许是坏消息。但对于Rust来说，可以避免其仓库被海量的C++代码库湮灭，也许是幸运。 就算是如我上面所说，还会有一些新的问题： 1. 编译的时间太久：于是可以使用缓存的方法，将一个依赖项的某一个配置缓存起来。这对于其他语言来说可能不是刚需，但对于C++来说，简直太需要了。
2. 为每个包写符合规范的配置选项，仍然会是一个很大的工作量。这一点我相信靠我们的努力，未来会做得更好。