vcpkg 是发布开源和跨平台 C++ 库的宝贵选择吗

Question

我是Linux用户，只在Linux上开发。我知道如何使用 Make 和 CMake 来构建我的库，但随着我的进步和扩大项目的难度，我现在必须以最少的用户输入解决跨平台兼容性问题。

为了实现我的目标，vcpkg 是一个不错的选择吗？如果不是，那么在开发 Windows 应用程序时选择使用包管理器是否合理？

我的目标是，我的库的 Windows 用户在下载和安装后可以轻松地使用它们，即通过包含相关标头，并且理想情况下，如果使用 Eclipse 或 MSVC，则不必担心针对静态进行编译和链接。

请记住，我不是一名专业的软件开发人员，而是一名计算科学家，他试图不搞乱他工作中的软件工程部分，同时努力让最终用户（其他计算机科学研究员）的生活成为可能尽可能简单。

我正在寻找的是一个关于当今跨多个操作系统构建、运输和使用库的事实上的标准的观点。

Answer 1

这将是一个非常有争议的观点，但我希望您真诚地接受它，因为它来自与多个包管理器的多年专业经验。

是的，vcpkg它是 Windows 和 Linux 上最好的包管理器。

许多人会将柯南宣传为世界上最好的东西，但我的经验是，它充其量是混乱的。您添加A依赖B于C不同版本的软件包（例如 boost）的软件包。这是依赖地狱。

vcpkg另一方面，有一个精选的版本库列表，这些库彼此 100% 兼容。因此，您可以保证从 vcpkg 采购的任何软件包组合都不会导致您的应用程序出现链接问题。从这个意义上说，它非常稳定和专业。

一旦您准备好升级依赖项，例如一两年后，您只需从 vcpkg 升级到新的受祝福的版本，该版本也是相互兼容的。因此，没有什么意外，没有几天在 StackOverflow 上谷歌搜索并生气以解决奇怪的编译器错误。

我过去工作过的公司是芝加哥的一家大型期权交易公司，他们有一个人负责在内部按需发布 vcpkg 软件包。我们正在谈论 O/S (Redhat) 上不可用的 +250 个软件包。一切都很顺利，根据书本，通过 Jenkins 的 CD/CI 管道非常棒。

然后，几个部门极力要求安装 Conan，因为他们想要最新的软件包，即发布后不到 6 个月的软件包。好吧，猜猜当时发生了什么。团队无法重用彼此构建的软件，因为它们的依赖关系彼此完全不兼容。编写管道库的 IT 团队突然无法满足服务台团队的请求，因为一旦他们链接到他们的库，就会经常与他们的应用程序使用的库发生冲突。一切都开始破裂。CD/CI 已不复存在，因为不可能让 Jenkins 摄取那么多的自定义脚本。软件包不再由受祝福的中央公司来源发布，团体开始编译自己的二进制文件，通常直接从他们的主文件夹$HOME/stuff到位于交易所内的生产机器中。可怕的东西。

最后他们聘请了一个由 7 名顾问组成的团队，负责构建系统和柯南。如果你明白我的意思的话，那么这家顾问公司是 CIO 的朋友，这是件好事。