为什么没有针对C和C ++的程序包管理系统？[关闭]

软件包管理系统存在一些编程语言：

• TeX的CTAN
• Perl的CPAN
• Python的点子和鸡蛋
• Java Maven
• 阴谋的哈斯克尔
• 红宝石宝石
• NPM对的NodeJS
• 前端Javascript和CSS的Bower
• nuget for C＃
• PHP 作曲家

这样的系统还有其他语言吗？C和C ++呢？（这是主要问题！）为什么没有适用于他们的系统？而不是创建包yum，apt-get或其他一般的包管理系统更好？

实际上，有些人（知名度很高）正在努力创建和建立一个名为Ryppl的系统。很难为C ++建立这样的系统，因为它没有一个可以控制它的播放器。-更新：不幸的是它被放弃了。

关于第二个问题，普通的软件包管理器（除了不是跨平台的）不能满足开发人员的特定需求。

我认为C甚至C ++的问题在于它们是更加异构的语言：即使这些语言是标准化的，仍然存在具有不同选项或不同支持功能集的不同编译器。例如，我记得在一个堆栈溢出问题上发布了一个有关C ++的问题，该示例在GCC / Linux上运行得非常好，有人立即发布了一个回答，说我的代码是非标准的。

如果拥有像问题中提到的那样的软件包系统，则意味着拥有所有通用操作系统上所有主要编译器统一支持的通用语言和库。例如，您不想下载C ++软件包并发现它无法在您的编译器X版本上编译，因为它是在另一个操作系统的编译器Y上开发的。

我可以想象一个基于make和configure脚本（通常在Linux，cygwin和其他Unix风格上找到）的系统可以工作。但是，Visual Studio用户为什么要采用它？如果启动基于Microsoft编译器（和库）的软件包系统，则同样有效。

C ++是一种快速发展的语言，其标准始终需要一段时间才能被所有编译器完全支持，这一事实并不能缓解该问题。

我认为，为了回答您的问题，我们需要提出的问题是“其他语言/生态系统从拥有自己的集中化软件包存储库中可以获得什么？” 和“这是否适用于C / C ++？”

我觉得第一个问题的答案与新语言的初步推广有关：早期采用者希望新来者尽可能容易地进入生态系统，获取有用的，经过测试的代码并回馈自己的语言。出于明显的原因，“使用图”始终只有一个根-语言的创建者。通常有一个参考实现（至少在最初是这样），因此您可能希望共享的任何代码都必须遵循该参考实现。

这使得创建仅下载和编译的软件包变得容易。当然，如果C或C ++在2013年推出，他们的社区可能会遵循类似的发展道路，但是他们没有，也没有一个流行的工具链可以应用程序包管理器。这使得这种程序的实施太麻烦了，不值得麻烦。（您应该让用户在libfoo-gcc和libfoo-vs之间进行选择吗？您让它由打包程序来解决吗？还是由构建过程来决定？如果是这样，那么与直接压缩包有什么不同？）

因此，总结我对第一个问题的回答，我认为创建软件包管理器的模式主要是用来推动采用。

考虑到这一点，我认为很容易理解为什么没有单个系统能够满足这一需求-因为C和C ++程序员不存在这种需求。对于C和C ++社区（或实际上是任何程序员社区）真正构成问题的是最初隐含的需求：分发，保持最新并贡献代码。这已经由不同的人以不同程度的成功解决了很多次，实际上，一个系统正在获得可观的市场份额：git（以及之前的一些其他系统）。

基本上，当问题有所不同时，解决方案看起来也有所不同，但是恕我直言，键入gem install和git clone模拟之间的区别是没有意义的。

这个问题有点混乱。上面提到的软件管理特定编程语言的扩展。它们提供了库和源代码，这些库和源代码随后可在您使用所选的编程语言进行编程时使用。

虽然一般的系统级程序包管理器通常提供二进制程序包，但无论应用程序如何，都可以使用它们。他们更面向系统和用户。当然，诸如Aptitude，rpm，Entropy之类的系统级软件包管理系统可以提供任何软件包，无论是二进制还是源代码。这就是为什么您会在其中找到大多数将与... Gem一起安装的扩展的原因。

然后，您所说的Yum和Apt-get或Rigo只是它们下面的软件包管理系统的用户界面。

编程语言列表的另一种：

• PHP的Composer和Pear

我意识到这不是一个跨平台的解决方案，但是应该将其添加到组合中。

CoApp最近宣布使用NuGet支持C ++软件包管理：http : //blog.nuget.org/20130426/native-support.html

当前，这仅适用于Visual Studio编译器，但是有许多要求使它在其他平台上运行。