51

One of my biggest frustrations with my favorite language is the effort it takes to get different libraries working for together under one unified development environment. My biggest wish is to just be able to tell my IDE, or whatever, that I need a certain library, and it takes care of downloading it, compiling it(if necessary), installing it, then setting up the include and library paths.

What I want is this, but for C++. I would prefer if it works with Visual Studio, but gcc is okay too. Or if it is it's own separate system, that's fine too. It does, however, have to work in Windows.

What promising projects are out there to solve this problem?

Benjamin Lindley
  • 101,917
  • 9
  • 204
  • 274
  • 3
    hrmm http://stackoverflow.com/questions/1541771/using-maven-for-c-c-projects – Matt K Sep 01 '11 at 04:25
  • 1
    In the free-*nix-like world there is `pkg-config`. This lets you author files which define linker and compiler flags, i.e. `pkg-config --cflags --libs` – asveikau Sep 01 '11 at 04:45
  • Linux has it, Windows has it too... So what exactly do you want? –  Sep 01 '11 at 18:20
  • @Vlad: Windows has what? I'm looking for something that gives me the ability to use a wide variety of 3rd Party C++ libraries without having to follow unique installation instructions for each and every one. – Benjamin Lindley Sep 01 '11 at 18:38
  • @Benjamin: I never use Windows, but I know Cygwin provides packages for development. I guess MinGW too, according to Eran. –  Sep 01 '11 at 18:44
  • Relevant: http://nuget.codeplex.com/discussions/396720 and http://nuget.codeplex.com/discussions/280649 – Grault Jun 09 '13 at 03:30
  • http://programmers.stackexchange.com/questions/170679/why-are-there-no-package-management-systems-for-c-and-c – Ciro Santilli OurBigBook.com Aug 05 '15 at 08:00
  • Recently came across [conan.io](http://conan.io/) in HackerNews. It's described as the _Open-Source C and C++ package manager_. – legends2k Nov 08 '16 at 08:45
  • [Does C++ have a package manager like npm, pip, gem, etc? - Stack Overflow](https://stackoverflow.com/questions/27866965/does-c-have-a-package-manager-like-npm-pip-gem-etc) – user202729 Dec 30 '21 at 05:14

9 Answers9

20

Have you considered Git as a package manager? I've been using git submodules for dependencies and sub-dependencies and combined with free git hosting services, the idea is quite powerful.

Just go into your git project, 

git submodule add git://somehosting.com/you/package.git
git submodule init package
git submodule update package
cd package && ./configure --stuff && make && cd ..

To select particular dependency versions,

cd package && git checkout v3.2 && cd .. && git add package/
git commit -am "package version 3.2 pinned" && git push

Now you've pinned your package dependency to a particular tag and saved your settings to your project repository. Next time someone does:

git pull && git submodule update

Their package dependency will also be pinned to v3.2.

Some package management systems also feature signed packages. Git allows you to GPG sign your tags and lets people verify it by adding your public key to their keyring.

So we have package downloading, dependency versions and we can emulate "package signing". One missing part is pre-built binaries which, in my opinion isn't an absolute necessity. Another missing part is global package management. You will have to manually manage each git repository when a dependency of a dependency gets updated.

nurettin
  • 11,090
  • 5
  • 65
  • 85
14

The answer is to use Conda for packaging/dependency management and whatever tool you like for building (I use CMake).

Check it out here:

http://conda.pydata.org/

Conda is similar to package managers like apt-get, yum, nuget, etc, but with several important advantages:

1) fully cross-platform (currently Linux, Windows, and OSX, but other platforms can be added easily)

2) does NOT require root access to use. In fact, doesn't care about your system packages at all. It's similar to building out an entire stack (down to libc if you want) in your homedir, except somebody already built them for you. This magic is achieved by making packages relocatable.

3) you can maintain as many different environments as you want side-by-side. Does one of your applications require python 2.7.6, but another one needs python 2.7.4? No problem - they can coexist in peace

4) you will never again be forced to maintain separate builds for the various Linux distros. A properly-constructed Conda environment will work on any of them. Don't forget other platforms as well (e.g. Windows and OSX)!

5) you are no longer married to versions of libraries that were decided FOR you by a system or an IT department. For example, I was forced to work on RHEL5 nodes. The Python there is a joke (over 10 years old now). By using Conda I bypassed that pain and was able to work on any version of Python that I wanted without affecting anybody else.

6) environments can be zipped up into "installers" for distribution.

7) you can maintain your own private repository behind your firewall for proprietary libraries. The public centralized repository is called Binstar. Your dependencies can come from either (or both).

Many people mistakenly believe that Conda is a Python-only system, but actually Conda was created for native packaging (it is language agnostic). It has a huge Python presence simply because its original motivation was to overcome terrible native library support in Python's other packaging system (pip + pypi).

The only problem with Conda currently is that Binstar (the central repository) doesn't have every package yet. You will definitely encounter missing libraries that you want - but that's easy to fix: you can build whatever package you like yourself and push it to Binstar. I've had to do this for dozens of native libraries. It works quite well.

I'll never go back to system dependency managers when developing C++ code.

Spencer Stirling
  • 141
  • 1
  • 2
  • 3
    Why the downvote? Explain what's wrong with my post, and what the right answer is. Good luck. I've been responsible for building massive cross-platform C++ codebases for several years (dozens of dependencies, mixed opensource/proprietary, and millions of lines of code). I've tried ryppl (now abandoned), maven-nar, gradle, ant, and one that I wrote myself in CMake. The Conda/Binstar system is the best that I've experienced BY FAR. The others were woefully inadequate for serious cross-platform C++ shops – Spencer Stirling Nov 08 '14 at 17:00
  • I did not downvote, but did you check the link you posted? That doc does not mentiong how to setup a c++ and not even mentioning any thing about c++. – r0n9 Apr 10 '21 at 14:44
8

As of NuGet 2.5, NuGet supports native projects. However, making the package by hand is pretty complex, so they suggest using CoApp's Powershell Tools for NuGet (documentation here). Using these tools, you can now host your C/C++ packages on NuGet.

JKor
  • 3,822
  • 3
  • 28
  • 36
  • 2
    +1. It should be noted that this runs into the same issue I pointed at in my 2011 answer -- namely, being MSBuild only -- and in this respect is similar to `pkg-config` in Unix land. I don't believe there is any intent to make NuGet work cross platform, for example. Its a good solution on Windows and I hope it does well, but it doesn't solve this problem in the general case for C++ the way Maven does for Java or the way NuGet does for C#. – Billy ONeal Oct 20 '13 at 07:02
8

This is unlikely to occur simply because differing C++ libraries often use VASTLY different build systems. Autoconf, scons, make, MSBuild, VCBuild, Boost Jam, CMake, NMake, and QMake are examples. Additionally, a lot of C and C++ developers generate code with tools like Yacc and Bison.

Maven and NuGet work the way they do because they support ecosystems with (relatively) little variation in build tools. Ant in Maven's case, MSBuild in NuGet's case. Building a similar system to work with the vast array of C++ build systems in use would be infeasible and impractical (given the seeming lack of demand for such systems).

Billy ONeal
  • 104,103
  • 58
  • 317
  • 552
  • I don't think he's looking for a universal package manager, just one for Visual Studio. So the existence of other make systems isn't really a problem. – Ben Voigt Sep 01 '11 at 04:41
  • 1
    @Ben: Problem is, whatever libraries he's using would need to support that package manager, which is unlikely because library developers (generally) care about more than one programming environment. – Billy ONeal Sep 01 '11 at 04:42
  • 4
    Not necessarily. With traditional package managers (for applications), there's often a package maintainer for each OS, not necessarily affiliated with the developer. For example, many applications are available as RPM, ipkg, ebuild, etc, but these generally aren't provided by the developer. Libraries can similarly be packaged by a third-party. Besides, something like this already exists for C++ applications on POSIX, `pkg-config`. – Ben Voigt Sep 01 '11 at 04:45
  • 2
    @Ben: Yeah. Because that's used by 'everybody'. :) I'm not saying such a thing isn't possible. Merely that it is extremely unlikely. C++ runs everywhere; this makes it difficult to make any kind of general package system. It would be possible; just extremely hard. – Billy ONeal Sep 01 '11 at 04:50
5

If you are using MinGW, there is already a package manager similar to apt-get / aptitude which does what you want: mingw-get

It behaves similar to Debian's apt-get/aptitude. Among the packages that are already included you can find expat, libxml2, zlib, pthread etc.

Obviously, you will need a copy of MinGW to start working with it.

clstrfsck
  • 14,715
  • 4
  • 44
  • 59
Eran
  • 2,310
  • 1
  • 13
  • 13
3

I've been working on a cross-platform and cross-architecture distributed package manager. All packages are installed in the project directory (a bit like how nodejs works). It is a work in progress.

ioquatix
  • 1,411
  • 17
  • 32
  • Link didn't survive the time. – Johan Boulé Jun 27 '15 at 11:53
  • @JohanBoule Thanks, fixed. – ioquatix Jun 28 '15 at 12:24
  • Thanks for fixing the link. I will have a look. – Johan Boulé Jul 14 '15 at 15:09
  • I do like the stated goal of your project and I share the feeling about the actual problems you describe. It's well summarized. As to whether one should try and solve it alone, I think it's not possible as it involve other people to agree on using a common system. Perhaps the best "place" to get involved in to help the whole opensource community converge into something currently is freedesktop.org. – Johan Boulé Jul 14 '15 at 16:29
2

ryppl seems to be doing what you required and more, cross platform:

Our mission [is] to create the conditions for a portable, modular C++ software ecosystem

Already starred them on GitHub: https://github.com/ryppl/ryppl

Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985
2

There is Daveed's module proposal, which didn’t make it into C++0x.

Cheers and hth. - Alf
  • 142,714
  • 15
  • 209
  • 331
  • 1
    Modules are a replacement for the header file system, not anything like a package manager as Maven or NuGet are. – Billy ONeal Sep 01 '11 at 04:41
  • @Billy: that depends on the module concept. – Cheers and hth. - Alf Sep 01 '11 at 04:44
  • @Alf: No it doesn't, as evidenced by e.g. `pkg-config`. – Ben Voigt Sep 01 '11 at 04:51
  • @Ben: your argument does not make sense, sorry. anyway, read the proposal linked to. what part of "library" do you not understand? – Cheers and hth. - Alf Sep 01 '11 at 04:56
  • 3
    @Alf P. Steinbach: What the OP wants is for example, if I need the Boost libraries for my project, I can tell the IDE or the package manager to download the Boost package or something from a known online repository and automatically set up include paths and do any other necessary configuration tasks. That is something completely outside the scope of the modules proposal. LaTeX has [the Comprehensive TeX Archive Network](http://www.ctan.org/ctan.html) that allows my LaTeX installation to download whatever package I need. That's what the OP is looking for, but for C++. – In silico Sep 01 '11 at 05:02
  • @In silico: it is unclear what you're arguing against. you say that "that" is something outside the scope of modules, but that only limits what you could meaningfully mean by "that". modules in the sense of e.g. Daveed's proposal solve about half of the problem, namely the language-dependent half. the other half, finding a library to download and getting it, is pretty language independent. – Cheers and hth. - Alf Sep 01 '11 at 06:00
  • @Alf P. Steinbach: Correct. But a package manager does not require that the C++ language implement the module proposal. The existence or feasibility of a C++ package manager is not contingent on this particular proposal. In other words, you can have a perfectly working package manager system with the existing C++ language. – In silico Sep 01 '11 at 06:04
  • @Alf P. Steinbach: I guess we are in agreement then. I saw your reply to Billy ONeal and perhaps interpreted it the wrong way. – In silico Sep 01 '11 at 06:11
  • @Alf: You said that a package manager "depends on the module concept", i.e. that implementation of modules is a prerequisite for a package manager. `pkg-config` shows that a package manager doesn't need C++1y modules. Unless by *that* you didn't mean a package manager, but Billy's comment. – Ben Voigt Sep 01 '11 at 14:15
  • @Ben: no, my words did not occur in the context you have now added. they were an answer to Billy's comment, as indicated by `@Billy:`. the good Billy said "Modules are...", and i said, that depends on the module concept. some people, mainly C programms, think a function is a module. some people, e.g. Betrand Meyer, thinks a class is a module. some people, e.g. Niklaus Wirth, thinks a Modula module (or Pascal unit or Ada package) is a module. some people, e.g. Daveed, thinks a library is a module. and so on. however, there is not room here on SO to educate people. so i state just the core truth – Cheers and hth. - Alf Sep 01 '11 at 15:04
  • @Alf: Ok, now I understand what you meant by "that" (Billy's whole comment), and now you understand how I read it ("a package manager such as Maven or NuGet"), so we can probably clean up the comments produced from this misunderstanding. – Ben Voigt Sep 01 '11 at 15:50
1

There is CoApp, which seems to have Microsoft's support.

Ferruccio
  • 98,941
  • 38
  • 226
  • 299
  • CoApp is a tool to generate NuGet packages. So to generate a C++ NuGet package you can use either Nuget XML files or CoApp file. – Sergey Shandar Nov 27 '13 at 01:00