C++ 依赖生产没有被自动化的理论原因是什么？答案

【问题标题】：What is the theoretical reason for C++ dependency production not being automated?C++ 依赖生产没有被自动化的理论原因是什么？
【发布时间】：2013-01-10 17:06:27
【问题描述】：

C++ Buildsystem with ability to compile dependencies beforehand

Java 有 Maven，使用起来很愉快，只需指定已编译的依赖项，并存放到 Mavens 标准目录，这意味着依赖项的位置是标准化的，而不是经常使用的 C/C++ 依赖项拥有多个位置的方式（让我休息一下，就像任何人都记得特定部门的默认安装目录）。

对于每个单独的开发人员来说，这通常是非常低效的，他们必须经常查找、阅读、熟悉配置选项/构建，并最终为每个依赖项进行编译以简单地构建项目。

没有实施的理论原因是什么？

为什么很难用类似 maven 的声明格式提供以下选项的包？

version
platform (windows, linux)
src/dev/bin
shared/static
equivalent set of Boost ABI options when applicable

必须手动访问网站并在 2013 年搜索最古老的主要编程语言的依赖项是荒谬的。

【问题讨论】：

我认为您的问题实际上只是“C++ 是否有与 Maven 等价的东西？”...
我觉得更像是“很明显这个东西应该存在。它不存在。所以它不存在一定有很好的理由。那是什么原因？”
可能是因为 C++ ABI 太多了，而 Java（我认为）本质上指定了一个特定的 ABI？ Debian 系统也有类似的功能，虽然只适用于 Linux。
我认为简短的回答是：没有理论上的原因。这只是（无论出于何种原因）没人做过的事情。
@villapx 是 - “apt-get source [package]” 会将包的源下载到当前目录；并且“apt-get build-dep [package]”将安装必要的工具、库、头文件等，这些都是通过“dpkg-buildpackage”从源代码构建包所需的。

标签： c++ build

【解决方案1】：

没有任何理论上的原因。有很多实际原因。在 C++ 世界中有太多不同的处理方式，无法轻松地在依赖系统上标准化：

实现差异 - C++ 是一种复杂的语言，不同的实现在历史上对它的支持程度（它们正确处理各种中高级 C++ 代码的能力）存在差异。因此，不能保证可以在特定实现中构建库。
平台差异 - 某些平台可能不支持异常。标准库有不同的实现，各有利弊。与 Java 的标准化库不同，Windows 和 POSIX API 可能完全不同。 文件系统甚至不是标准 C++ 的一部分。
编译差异 - 静态还是共享？调试还是生产构建？是否启用可选依赖项？与具有非常稳定的字节码的 Java 不同，C++ 缺乏标准 ABI 意味着代码可能无法正确链接，即使是由同一编译器为同一平台构建的。
构建系统差异 - Makefiles？（如果是这样，GNU Make，还是别的什么？） Autotools？制作？ Visual Studio 项目文件？还有什么？
历史问题 - 由于 C 和 C++ 的时代，zlib 等流行的库比 Maven 等构建系统早了很多。当 zlib 正在做的工作时，为什么要切换到一些假设的 C++ 构建系统？如果一个更新的、更高级别的库依赖于像 zlib 这样的库，它如何切换到某个假设的构建系统？

另外两个因素使事情复杂化：

在 Linux 中，发行版打包系统确实提供了开发库头二进制文件的标准化存储库，具有（通常）标准化的 ABI 和指定项目构建依赖项的简单方法。这些（特定于平台的）解决方案的存在降低了跨平台解决方案的动力。
由于所有这些复杂因素和预先存在的方法，任何建立标准构建系统的尝试都将遇到 XKCD 的"Standards" 中描述的问题：
情况：有 14 个相互竞争的标准。
“14？可笑！我们需要制定一个涵盖每个人的用例的通用标准。”
Soon：有 15 个相互竞争的标准。

说了这么多：

对未来有一些希望。例如，CMake 似乎正在逐渐取代其他构建系统。一些 Boost 开发人员已经开始 Ryppl，试图做你所描述的事情。

【讨论】：

我会将语言差异更改为实现差异
Java 比你想象的更不标准，我不同意人们说 Java 是“标准”的，Java 需要与所有其他语言相同的测试周期，可能比其他语言更短，但我的关键是Java绝对不是标准的，看看Mac上第一个官方JDK花了多少时间，JDK 7是MAC OS上第一个官方JDK版本！今天Java真的是在Oracle/OpenJDK/Apple JVM之间割裂了，这只是前3名，不考虑过去和其他选项。

【解决方案2】：

（也发布在链接问题中）

现在我正在开发一种工具，该工具能够自动安装具有确切版本要求的 C/C++ 应用程序的所有依赖项：

编译器
库
工具（cmake、autotools）

现在它适用于我的应用程序。（按正确顺序安装 UnitTest++、Boost、Wt、sqlite、cmake）

名为 «C++ 版本管理器» 的工具（灵感来自优秀的 ruby 版本管理器）以 bash 编码并托管在 github 上：https://github.com/Offirmo/cvm

欢迎任何意见和建议。

【讨论】：

更新：我现在不再使用 C++，这个实验性工具的开发已经暂停。

【解决方案3】：

嗯，首先，解决所有依赖关系的系统默认情况下不会让您的工作效率更高，它可能会使您的工作效率更低。

关于语言之间的差异，我想说的是，在 Java 中你有包，当你必须组织并为你的代码提供有限的视野时，这些包很方便，而在 C++ 中你没有等效的概念。在 C++ 中，所有可以解决符号的库对于编译器来说都足够好，库的唯一真正要求是具有一定的 ABI 并解决所需的符号，没有自动化的方法可以让您选择正确的库，还解决了一个符号，这只是将您的函数链接到实际实现的问题，这甚至不授予您正确的链接阶段将使您的应用程序工作。

为此，您可以添加重要的变量，例如库版本、同一库的不同实现以及具有相同方法名称的不同库。

一个例子是 Mesa 库 VS 来自官方驱动程序的 opengl 库，或者您想要提供多个版本的任何库，每个库都可以解决所有符号，但可能有一个版本比其他版本更成熟，您可以要求编译器选择正确的，因为它们对于自己的目的都是一样的。

【讨论】：