存在一些用于程序包管理系统的编程语言：



用于TeX的CTAN

用于Perl的CPAN

Python的知识点和鸡蛋

Java的Maven

Haskell的cabal

Ruby的宝石


>适用于NodeJS的npm

用于前端Javascript和CSS的增强器

用于C＃的Nuget

用于PHP的composer

此类系统还有其他语言吗？ C和C ++呢？ （这是主要问题！）为什么他们没有这样的系统？并且为yum，apt-get或其他常规程序包管理系统创建程序包不是更好吗？

评论

Objective-C有Cocoapods（非常类似于红宝石和捆绑器）。奇怪的是C ++没有类似的东西。也许是因为C ++的同质性较差。苹果提供了更多标准的东西来重新构建软件包。在C ++中，几乎无法就使用哪种字符串类达成共识。
我只想指出，其他语言的软件包管理器并不完美。例如，在Ruby Gems中，可能经常会遇到一种不适用于特定操作系统（比Windows可能更多的Windows）的文档，并且文档并未告诉您它不适用于该操作系统。
stackoverflow.com/questions/7266097/…

#1 楼

实际上，有些人（知名度很高）正在努力创建并建立一个称为Ryppl的系统。
很难建立这样的C ++系统，因为它没有一个单一的播放器来决定它。 --UPDATE：不幸的是它被放弃了。

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

评论

哇，我想知道他们将如何抗击20年的“我们不需要包装经理！”

–TheLQ
2012年10月20日在18:28
好吧，他们一举成名，我将给他们带来疑问的机会并窥视一下。毕竟，Boost非常令人惊叹:)

–Onno
2012年10月22日6:46


@TheLQ-除了以前没有人提出过可行的解决方案之外，我认为没有其他可比之处。没有“我们不需要臭臭的软件包管理器”，没有“没有人给我看过任何有用的东西”。前者可能很难解决，但后者很简单：仅提供一些实际上可以帮助开发人员完成工作的东西。

–迈克尔·科恩（Michael Kohne）
2012年10月23日13:50
这个答案应该更新：1）Ryppl是一个死项目，即使它的网站也死了。 2）最近出现了cpm之类的其他项目（无论商业与否），因此要获取C ++的程序包管理器需要做很多工作。 3）我相信，只有使用该语言的模块并且其中一种工具能够最大程度地利用该语言，才会有赢家。

–克莱姆
2015年1月3日，21：34
@Klaim re：{直到模块使用该语言}据我所知，模块并不能使事情变得更容易，它只是#include命令的语法糖。它不会解决版本控制/下载/安装/兼容性/跨平台C ++问题的主要问题。

– ruslo
2015年11月3日，11：13

#2 楼

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

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

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

C ++是一种快速发展的语言，其标准在获得所有编译器的完全支持之前需要花费一些时间。不能缓解问题。

评论

好吧，您可以编写可移植的C ++，也可以编写特定的工具链。您的选择，两者都没有错，尽管在对后者没有优势的情况下不做前者则有些次优。

–重复数据删除器
15年11月11日在20:51
有可移植的C和C ++。如果无法通过安装程序轻松地独立安装库，则应重新制作。完全有可能做到这一点。即使在NodeJS中，许多模块都无法在Windows上构建，但是仍然设法存在，因此偶尔的构建问题也不成问题，并且具有集中式软件包管理器可以简化用户的反馈，并更有动力来处理问题。

–德米特里
16年7月17日在1:44

#3 楼

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

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

这使得创建仅下载和编译的包变得容易。当然，如果C或C ++在2013年推出，他们的社区可能会遵循类似的发展道路，但是他们没有，也没有一个流行的工具链可以应用程序包管理器。这使得这种程序的实施太麻烦了，不值得麻烦。 （您应该让用户在libfoo-gcc和libfoo-vs之间进行选择吗？您将其留给打包程序来解决吗？还是构建过程？如果是这样，那么与直接压缩包有什么不同？） />
因此，总结我对第一个问题的回答，我认为创建程序包管理器的模式主要用于推动采用。

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

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

评论

“其他语言/生态系统从拥有自己的集中式软件包存储库中可以获得什么？”。您需要成为一个非常有经验的开发人员，才能开始下载软件包并信任它们可以与您的软件一起正常工作。拥有软件包管理器使人们可以开始使用软件包，而不用处理上下文相关的构建说明等。我自己不知道如何提高MinGW的工作效率，因此我最终自己重复编写了很多功能，而不仅仅是使用它。没有它是愚蠢的。

–德米特里
16年7月17日在1:46
不必与各种安装/构建脚本和标志进行斗争将是一个巨大的胜利。

– themihai
17年11月15日在10:33

#4 楼

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

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

编程语言的另一种：


PHP的Composer and Pear


评论

是的，当然。在写最后三个问题时我在想什么？

–m0nhawk
2012年10月20日在9:37
问题在于这些软件包在全球而不是本地获取，并且将项目的依赖关系捆绑到一个文件夹中非常困难。这意味着一个项目可能会在您的系统上运行，但是一旦将它放在另一个系统上，您就需要记住它所依赖的内容，并获取所有内容并将它们放在您的项目期望的确切位置。这个过程是地狱。 GTK就是一个例子，它易于全局安装，而难于本地安装。

–德米特里
16年7月17日在1:48


#5 楼

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

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

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