我对我最喜欢的语言的最大挫折之一是在一个统一的开发环境下让不同的库一起工作所需的努力。我最大的愿望是能够告诉我的 IDE 或其他任何东西,我需要某个库,它负责下载、编译(如有必要)、安装,然后设置包含和库路径。
我想要的是这个,但对于 C++。如果它可以与 Visual Studio 一起使用,我会更喜欢,但 gcc 也可以。或者,如果它是自己的独立系统,那也没关系。但是,它必须在 Windows 中工作。
有哪些有前途的项目可以解决这个问题?
我对我最喜欢的语言的最大挫折之一是在一个统一的开发环境下让不同的库一起工作所需的努力。我最大的愿望是能够告诉我的 IDE 或其他任何东西,我需要某个库,它负责下载、编译(如有必要)、安装,然后设置包含和库路径。
我想要的是这个,但对于 C++。如果它可以与 Visual Studio 一起使用,我会更喜欢,但 gcc 也可以。或者,如果它是自己的独立系统,那也没关系。但是,它必须在 Windows 中工作。
有哪些有前途的项目可以解决这个问题?
您是否将 Git 视为包管理器?我一直在使用 git submodules 进行依赖和子依赖,并结合免费的 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 签名,并允许人们通过将您的公钥添加到他们的密钥环来验证它。
所以我们有包下载,依赖版本,我们可以模拟“包签名”。一个缺失的部分是预先构建的二进制文件,在我看来这不是绝对必要的。另一个缺失的部分是全局包管理。当依赖项的依赖项更新时,您将不得不手动管理每个 git 存储库。
答案是使用 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++ 代码时,我永远不会回到系统依赖管理器。
这不太可能发生,因为不同的 C++ 库经常使用非常不同的构建系统。Autoconf、scons、make、MSBuild、VCBuild、Boost Jam、CMake、NMake 和 QMake 就是示例。此外,许多 C 和 C++ 开发人员使用 Yacc 和 Bison 等工具生成代码。
Maven 和 NuGet 以它们的方式工作,因为它们支持构建工具(相对)很少变化的生态系统。Maven 中的 Ant,NuGet 中的 MSBuild。构建一个类似的系统来与大量使用中的 C++ 构建系统一起工作是不可行和不切实际的(鉴于对此类系统的需求似乎不足)。
从 NuGet 2.5 开始,NuGet 支持本机项目。然而,手工制作包相当复杂,因此他们建议使用 CoApp 的 Powershell Tools for NuGet(此处的文档)。使用这些工具,您现在可以在 NuGet 上托管您的 C/C++ 包。
如果您使用的是 MinGW,那么已经有一个类似于 apt-get / aptitude 的包管理器可以满足您的需求:mingw-get
它的行为类似于 Debian 的 apt-get/aptitude。在已经包含的包中,您可以找到 expat、libxml2、zlib、pthread 等。
显然,您需要一份 MinGW 的副本才能开始使用它。
我一直在研究一个跨平台和跨架构的分布式包管理器。所有包都安装在项目目录中(有点像 nodejs 的工作方式)。这是一项正在进行的工作。
有Daveed 的模块提案,它没有进入 C++0x。
ryppl似乎正在做你需要的事情,而且跨平台:
我们的使命 [是] 为可移植的模块化 C++ 软件生态系统创造条件
已经在 GitHub 上为他们加注星标:https ://github.com/ryppl/ryppl
有CoApp,它似乎得到了微软的支持。