- 已关闭**。此问题为opinion-based。当前不接受答案。
- 想要改进此问题吗？**请更新此问题，以便editing this post可以用事实和引文来回答。
14小时前关门了。
Improve this question
我是一个Linux用户，只在Linux上开发。我知道如何使用Make和CMake来构建我的库，但随着我项目的进展和难度的增加，我现在必须用最少的用户输入来解决跨平台兼容性问题。
为了达到我的目标，vcpkg是一个好的选择吗？如果不是，在开发Windows应用程序时，选择使用包管理器是合理的吗？
我的目标是，我的库的Windows用户在下载和安装后使用它们时应该花费最少的精力，即通过包括相关的头文件，理想情况下，如果使用Eclipse或MSVC，不必担心针对静态文件进行编译和链接。
请记住，我不是一个专业的软件开发人员，而是一个计算科学家，他试图不搞砸他工作中的软件工程部分，同时试图使最终用户（其他comp scis研究员）的生活尽可能简单。
我所寻找的是一种观点，即今天可以被认为是跨多个操作系统构建、发布和使用库的事实上的标准。
1条答案
按热度按时间bvjveswy1#
这将是一个非常有争议的意见，但我希望你能真诚地接受它，因为它来自多年的专业经验与几个包经理。
是的，
vcpkg是Windows和Linux上最好的包管理器。很多人都认为柯南是最好的，但我的经验是，它充其量是混乱的。你添加依赖于
C的包A和B（比如boost），但版本不同。这是依赖地狱。另一方面，
vcpkg有一个版本库的管理列表，这些库彼此100%兼容，因此可以保证从vcpkg获得的任何包组合都不会导致应用程序的链接问题，从这个意义上讲，它是非常稳定和专业的。一旦你准备好升级你的依赖项，比如说一两年后，你就可以从vcpkg升级到一个新的版本，它也是相互兼容的。所以没有惊喜，没有几天的谷歌搜索和对StackOverflow的愤怒，寻找解决奇怪的编译器错误。
在我以前工作的公司，芝加哥的一家大型期权交易公司，他们有一个人负责按需在内部发布vcpkg软件包。我们正在谈论的是O/S（Redhat）上没有的+250软件包。一切都很顺利，通过Jenkins的CD/CI管道非常棒，照章办事。
然后有几个人极力要求安装柯南，因为他们想拥有最新的软件包，意思是从发布到现在不到6个月的软件包。好吧，猜猜当时发生了什么。团队不能重用他们从彼此构建的软件，因为他们的依赖关系彼此完全不兼容。编写管道库的IT组突然无法满足来自桌面组的请求，因为一旦他们链接到他们的库，它会经常与他们的应用程序使用的库发生冲突。一切都开始崩溃。CD/CI不复存在了，因为不可能让Jenkins摄取那么多自定义脚本。软件包不再由一家中央受祝福的公司发布，团队开始编译他们自己的二进制文件，经常直接从他们的主文件夹
$HOME/stuff进入位于交易所内的生产机器。最后他们雇佣了一个由7名顾问组成的团队，负责构建系统和柯南。好消息是顾问公司与CIO是朋友，如果你明白我的意思的话。