Are there any efforts to create a package manager for C++? [closed]

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?

Solution 1:

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.

Solution 2:

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.

Solution 3:

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).