# Why are there no package management systems for C and C++? [closed]

There are some programming languages for which exist a package management system:

Is there any other languages with such systems? What about C and C++? (that's the main question!) Why there are no such systems for them? And isn't creating packages for yum, apt-get or other general package management systems better?

## closed as primarily opinion-based by user53019, Thomas Owens♦Aug 15 '13 at 17:42

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

• Objective-C has Cocoapods (very similar to ruby gems and bundler). So kind of odd that C++ doesn't have something similar. Perhaps because C++ is less homogenous. Apple provides more standard stuff to build packages on top off. In C++ one can hardly agree on what string class to use. – Erik Engheim Jun 12 '13 at 21:22
• I would just like to point out that the package managers from other languages are not perfect. For example, in Ruby Gems one may often encounter a gem that doesn't work for a specific OS (more than likely Windows) and the documentation doesn't tell you it doesn't work for that OS. – Travis Pessetto Aug 15 '13 at 17:53

Actually some people (of noticeable boost fame) are working hard to create and establish such a system called Ryppl. It is hard to establish such a System for C++, because it has no single player which can dictate it. --UPDATE: Unfortunately it is abandonned.

On your second question, a normal package manager (besides not being cross platform) does not handle the specific needs of developers.

• Wow, I wonder how they are going to fight 20 years of "We don't need a package manager!" – TheLQ Oct 20 '12 at 18:28
• Well, them being of Boost fame, I'll give them the benefit of the doubt and take a peek. Boost, after all, is quite amazing :) – Onno Oct 22 '12 at 6:46
• @TheLQ - I don't think there's anything to fight other than that no one has previously presented a workable solution. There's no 'we don't need not stink'n package manager' there's 'No one's shown me anything that seems useful'. The former can be difficult to get around, but the latter is simple: just present something that actually help devs do their job. – Michael Kohne Oct 23 '12 at 13:50
• This answer should be updated: 1) Ryppl is a dead project, even it's website is dead. 2) Other projects (commercial or not) like cpm have spawn recently so there is a lot of work being done for getting a package manager for C++. 3) I believe that there will be no winner until modules are in the language and one of the tools manage to exploit that to the fullest. – Klaim Jan 3 '15 at 21:34
• @Klaim re:{until modules are in the language} as far as I understand modules doesn't make things easiler, it's just a syntax sugar for the #include command. It will not solve the main problem of versioning/downloading/installing/compatibility/cross-platformic C++ issues. – ruslo Nov 3 '15 at 11:13

I think that a problem with C and even more with C++ is that they are more heterogeneous languages: even though these languages are standardized there exist different compilers with different options or different sets of supported features. E.g., I remember posting a question about C++ on stack overflow with an example that was working perfectly on GCC / Linux and someone immediately posted an answer saying that my code was non-standard.

Having a package system like the ones mentioned in the question would imply having a common language and libraries that are supported uniformly by all major compilers on all common operating systems. E.g., you do not want to download a C++ package and discover that it won't compile on your version of compiler X because it was developed on compiler Y on another operating system.

I could imagine that a system based on make and configure scripts (as commonly found on Linux, cygwin and other Unix flavors) could work. But why should Visual Studio users adopt it? The same is valid if one started a package system based on Microsoft Compilers (and libraries).

The fact that C++ is a fast evolving language and its standards always take some time before being fully supported by all compilers does not alleviate the problem.

• Well, you can write portable C++, or you can write to a specific toolchain. Your choice, and nothing wrong with either, though not doing the former when there's no advantage to the latter is somewhat suboptimal. – Deduplicator Nov 11 '15 at 20:51
• There is portable C and C++. If a library can't be installed in a standalone way by an installer easily, it should be remade. It's perfectly possible to accomplish this. Even in NodeJS many modules fail to build on Windows, but it still manages to exist, so occasional build issues are not a problem, and having a centralized package manager streamlines feedback from users and makes it more incentive to deal with issues. – Dmitry Jul 17 '16 at 1:44

I think the questions we need to ask in order to answer yours are "What do other languages/ecosystems gain from having their own centralized package repository?" and "Does this apply to C/C++?"

I feel the answer to the first question has something to do with the initial promotion of a new language: the early adopters want to make it as easy as possible for newcomers to enter the ecosystem, acquire useful, tested code and contribute back their own. For obvious reasons, the "usage graph" always has a single root - the creator(s) of the language. There's usually one reference implementation (at least initially) and therefore any code you might want to share has to conform to it.

This makes it easy to create packages that just download and compile. Certainly, had C or C++ been introduced in 2013, their communities could have followed a similar evolutionary path, but they hadn't and there's no one single prevailing toolchain to apply a package manager to. This makes the implementation of such a program too troublesome to be worth the hassle. (should you make users choose between libfoo-gcc and libfoo-vs? Do you leave it up to the packager to resolve? Or the build process? If so, how is a package any different than a straight-up tarball?)

So to sum up my answer to the first question, I think the pattern of creating package managers serves mostly to drive adoption.

With that in mind, I think it's fairly easy to see why no single system has risen to fulfill this need - because the need doesn't exist for C and C++ programmers. What does constitute a problem for the C and C++ community (or any programmer community, really) is the need originally implied: to distribute, keep up to date and contribute back code. This has been solved many times by different people with varying degrees of success, and indeed one system is gaining significant market share: git (and some other systems before that).

Basically when the problems differ, the solutions look different too, but IMHO the difference between typing gem install and git clone is moot.

• "What do other languages/ecosystems gain from having their own centralized package repository?". You need to be a very very experienced developer to start downloading packages and trusting them to work properly with your software. Having a package manager allows people to just start using packages instead of dealing with context sensitive build instructions/so on. I myself can't figure out how to get boost to work on MinGW, so I end up writing much of it's functionality myself over and over, instead of just using it. It's silly not to have. – Dmitry Jul 17 '16 at 1:46
• Not having to fight with various install/build scripts and flags would be a great win. – themihai Nov 15 '17 at 10:33

There is a little confusion in this question. The above mentioned software manage extensions for specific programming languages. They provide libraries and source code that afterwards can be used in you program with your programming language of choice.

While general system level package mangers usually provide binary packages that can be used regardless of the application. They are more oriented at the system and user. Of course, system level package management systems like Aptitude, rpm, Entropy can provide any package, being it binary or source code. That's why you will find in them most of the extensions you would install with ... Gem for example.

Than, what you mentioned as Yum and Apt-get or Rigo are just user interfaces for the package management systems below them.

One more for the list o programming languages:

• Composer and Pear for PHP
• Yeah, definitely. What I was thinking about when writting last three questions? – m0nhawk Oct 20 '12 at 9:37
• The issue is that these packages get globally rather than locally, and bundling dependancies of your project into a single folder is very difficult. This means that a project might work on your system but as soon as you put it on another system you need to remember what it depends on and get all of them and put them in exact places your project expects them to be. This process is hell. An example of this is GTK, easy to globally install, hard to locally install. – Dmitry Jul 17 '16 at 1:48

I realize this is not a cross-platform solution, but it should be added to the mix.

CoApp recently announced support for C++ package management using NuGet: http://blog.nuget.org/20130426/native-support.html

This currently only works with the Visual Studio compiler, but there have been many requests to get this working on other platforms.