我最喜欢的语言之一就是在一个统一的开发环境下让不同的图书馆一起工作所需的努力。我最大的愿望是能够告诉我的IDE，或者其他什么，我需要一个特定的库，它负责下载它，编译它（如果需要），安装它，然后设置包含和库路径。
我想要的是this，但对于C ++。我更喜欢它是否适用于Visual Studio，但gcc也可以。或者，如果它是它自己的独立系统，那也没关系。但是，它确实必须在Windows中运行。
哪些有前景的项目可以解决这个问题？
答案 0 :(得分：16)
您是否认为Git是包裹经理？我一直在使用git子模块来实现依赖关系和子依赖关系，并结合免费的git托管服务，这个想法非常强大。
进入你的git项目，
git submodule add git://somehosting.com/you/package.git
git submodule init package
git submodule update package
cd package && ./configure --stuff && make && cd ..
选择特定的依赖版本，
cd package && git checkout v3.2 && cd .. && git add package/
git commit -am "package version 3.2 pinned" && git push
现在，您已将包依赖项固定到特定标记，并将设置保存到项目存储库中。下次有人这样做：
git pull && git submodule update
他们的包依赖性也将固定到v3.2。
某些包管理系统还具有签名包。 Git允许您GPG sign your tags，并允许用户通过将您的公钥添加到其密钥环来验证它。
所以我们有包下载，依赖版本，我们可以模拟“包签名”。一个缺失的部分是预建的二进制文件，在我看来并不是绝对必要的。另一个缺失的部分是全球包管理。当依赖关系的依赖关系得到更新时，您必须手动管理每个git存储库。
答案 1 :(得分：12)
答案是使用Conda进行打包/依赖管理以及您喜欢用于构建的任何工具（我使用CMake）。
在这里查看：
Conda类似于apt-get，yum，nuget等包管理器，但具有以下几个重要优势：
1）完全跨平台（目前Linux，Windows和OSX，但可以轻松添加其他平台）
2）不需要root访问权限。事实上，根本不关心你的系统包。它类似于在你的homedir中构建一个完整的堆栈（如果你想要的话，直到libc），除了有人已经为你构建它们。通过使包可重定位来实现这种魔力。
3）您可以并排维护多个不同的环境。你的一个应用程序是否需要python 2.7.6，而另一个需要python 2.7.4？没问题 - 他们可以和平共存
4）你再也不会被迫为各种Linux发行版维护单独的版本。正确构造的Conda环境将适用于其中任何一个。不要忘记其他平台（例如Windows和OSX）！5）您不再与系统或IT部门为您决定的库版本结合。例如，我被迫在RHEL5节点上工作。 Python有一个笑话（现在已超过10年）。通过使用Conda，我绕过了这种痛苦，并且能够在不影响任何其他人的情况下使用我想要的任何Python版本。
6）环境可以压缩成“安装人员”。分发。
7）您可以在专有库的防火墙后面维护自己的私有存储库。公共集中式存储库称为Binstar。您的依赖关系可以来自（或两者）。
许多人错误地认为Conda是一个仅限Python的系统，但实际上Conda是为原生包装而创建的（它与语言无关）。它拥有巨大的Python存在，仅仅是因为它最初的动机是克服Python其他打包系统（pip + pypi）中可怕的本机库支持。
Conda目前唯一的问题是Binstar（中央存储库）还没有包装。你肯定会遇到你想要的遗失库 - 但这很容易修复：你可以自己构建你喜欢的任何软件包并将其推送到Binstar。我必须为数十个本地图书馆做这件事。它运作得很好。
在开发C ++代码时，我永远不会回到系统依赖关系管理器。
答案 2 :(得分：8)
从NuGet 2.5开始，NuGet supports native projects。但是，手工制作包非常复杂，因此他们建议使用CoApp的Powershell工具来实现NuGet（documentation here）。使用这些工具，您现在可以在NuGet上托管您的C / C ++包。
答案 3 :(得分：7)
这不太可能发生，因为不同的C ++库通常使用VASTLY不同的构建系统。例如，Autoconf，scons，make，MSBuild，VCBuild，Boost Jam，CMake，NMake和QMake。此外，许多C和C ++开发人员使用Yacc和Bison等工具生成代码。
Maven和NuGet以他们的方式工作，因为他们支持生态系统（构建工具的变化相对较小）。在Maven的案例中是Ant，在NuGet案例中是MSBuild。构建一个类似的系统来处理正在使用的大量C ++构建系统是不可行的，也是不切实际的（考虑到对这类系统的需求似乎不足）。
答案 4 :(得分：5)
如果您使用的是MinGW，那么已经有一个类似于apt-get / aptitude的包管理器可以满足您的需求：mingw-get
它的行为类似于Debian的apt-get / aptitude。在已包含的软件包中，您可以找到expat，libxml2，zlib，pthread等。
显然，你需要一份MinGW来开始使用它。
答案 5 :(得分：3)
我一直在研究cross-platform and cross-architecture distributed package manager。所有包都安装在项目目录中（有点像nodejs的工作方式）。这是一项正在进行的工作。
答案 6 :(得分：2)
Daveed's module proposal ，它没有进入C ++ 0x。
答案 7 :(得分：1)
有CoApp，似乎得到了微软的支持。
答案 8 :(得分：1)