Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

There are some programming languages for which exist their own package management systems:

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?

share|improve this question

closed as primarily opinion-based by GlenH7, 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.

3  
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. –  Adam Smith Jun 12 '13 at 21:22
    
This question appears to be off-topic because it is a poll based question. Multiple answers could address this question equally well, which makes it a poor fit the for StackExchange Q&A format. –  GlenH7 Aug 15 '13 at 16:59
    
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
3  
NuGet for .NET –  Daniel Little Aug 15 '13 at 23:55
1  
I would add Composer for PHP –  JanL Dec 1 '13 at 17:14

6 Answers 6

up vote 23 down vote accepted

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.

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

share|improve this answer
1  
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
8  
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
    
The problem with C/C++ is that the package manager need to be aware of more preconditions like CPU architecture, OS and static/dynamic libraries –  jgauffin Dec 19 '12 at 13:12
    
@jgauffin Not completely, this is solved by the build system, not the package manager. Ryppl apparently rely on CMake to help on this but if my memory is correct it can also work with other build system of the library packaged, like boost build for example. –  Klaim Dec 20 '12 at 0:57

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.

share|improve this answer

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.

share|improve this answer

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
share|improve this answer
    
Yeah, definitely. What I was thinking about when writting last three questions? –  m0nhawk Oct 20 '12 at 9:37

C and C++ can use the GNU Build System which includes AutoMake and other tools. It's a tad more "DIY" than some but it seems to work pretty well.

share|improve this answer
7  
While make does help the compilation part, I think the OP is talking about more of the packaging and repository parts of a build system –  TheLQ Oct 20 '12 at 18:31

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.