C 以及 C++ 虽然经历过标准化，但缺乏单一的掌控者。现实世界里的 C/C++ 犹如神圣罗马帝国，固然有一个委员会在名义上号令天下，但事实上是各路诸侯的方言割据：Vistual Studio 的 C 与 GCC 的 C 不一样，而 GCC 的 C 又与 Clang 的 C 不一样；除去这些巨头之外，又有 Intel 的 C、Borland 的 C、K&R C、甚至谭浩强的 C，它们彼此都不尽相同；而如果愿意再细分的话，每一类处理器、操作系统、函数库的 C 都有或多或少的不同。

具体不同在何处呢？举例而言，在语法层面上，GCC 为 C 增加了许多扩展

这种纷乱的异构盛况，其他语言也不是没有，但在 C/C++ 这边是如此严重，使得维护一个像 pip 这样(在大部分时候)可以跨硬件架构、跨操作系统、跨语言版本、跨工具链的包管理工具变得极为困难。而且大多数 C 开发者事实上并没有这样的需求，因为需要用 C 语言做的事情通常比较底层，与操作系统紧密相关，甚至就是用来开发操作系统本身，毕竟它诞生的使命就是开发 Unix。五十年过去，现代 Unix-like 操作系统仍旧紧密围绕着 C 构建而成，而这些操作系统的包管理工具实际上也管理着一部分 C/C++ 的生态。许多为人熟知的 Linux 发行版将软件包分为「实体包」和「开发包」两类，通过同一套命令安装；BSD 则有「二进制包管理」和「源代码包管理」之区分，通过 package 和 port 两套系统完成。

以正则表达式库 PCRE 为例，在 Debian / Redhat 一类发行版上，`apt install libpcre3` / `yum install pcre` 会安装已经编译好的二进制文件到 /lib 中，`apt install libpcre3-dev` / `yum install pcre-devel` 则会安装对应的头文件到 /usr/include 中去

当然，系统级别的包管理器毕竟由管理系统的角度而设计，无法(很好地)解决一些软件开发所需解决的专门问题，比如多个版本的并存，依赖关系的管理，乃至于软件的调试、包装和部署。所以为了 C/C++ 而专门设计的包管理器同样存在，目前看起来发展相对成熟，用户群也相对稳定的，大概是 JFrog 的 Conan

那么 Conan 跟 vcpkg 如何解决「跨硬件架构、跨操作系统、跨语言版本、跨工具链」来维护程序包这个问题呢？vcpkg 解决得并不太好，至少目前(二〇二〇年底)它的出发点其实还是以 Visual Studio C++ 项目为优先服务对象提供解决方案。而 Conan 相对而言比较全面，但机制也更复杂：先以名为 conanfile.py 的 Python 脚本来描述一个包所适用的架构、操作系统、编译类型、以及其依赖，并根据其中与编译相关的条件生成一个 hash，然后将源代码或者二进制库和头文件分别按照 hash 打包。包的使用者则自行指定、或要求 Conan 自动检测所在编译环境，也生成一个 hash，据此下载对应的包，然后 Conan 根据脚本进行需要的编译、patch 等工作，然后将头文件与二进制库的路径生成为可以被 MSBuild、CMake、QMake 等构建工具所使用的文件。

这个答案一直在我草稿箱里扔了五六年，刚写好时觉得这是典型的用很多废话来回答简单的问题，想想还是算了。而今天写 conanfile 到痛不欲生又想起它，感觉还是解释了一个内行人肯定知晓、新手却未必了然的现况，就决定还是改一下发布出来。五六年后的世界还是变化很大的，知乎早已不是那个知乎(划掉)比如 vcpkg 这个东西，这问题提出来的时候还根本不存在。

C 语言很古老，但并不意味着它已经停止演进——嗯，我这里顺便推一本书，21st Century C: C Tips from the New School：

以及，如果你还不知道的话，《C专家编程》，这本倒是有中文版：

参考