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

Question

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 年搜索最古老的主要编程语言的依赖项是荒谬的。

Answer 1

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

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

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

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

说了这么多:

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