C ++的类似Maven的依赖管理？ [关闭]答案

【问题标题】：Maven-like dependency management for C++? [closed]C ++的类似Maven的依赖管理？ [关闭]
【发布时间】：2010-11-11 06:52:19
【问题描述】：

假设我有一个 C++ 项目，该项目分为几个子项目。子项目都生成一个 DLL，并且不同的开发团队在每个子项目上工作。现在如果我想构建主项目，有没有办法避免自己构建所有子项目？

简而言之，我正在寻找以与 Maven 对 Java 类似的方式进行依赖管理（即二进制文件和头文件）的东西。

事实上，我尝试为此使用 Maven，但这相当麻烦，因为我必须经常手动创建包，Maven 错过了获取最新更改的机会。此外，运行编译有点麻烦，因为我必须从 Maven 中调用 NAnt（我使用 NAnt 的功能直接构建 Visual Studio 解决方案）。

关于如何做到这一点的任何提示和想法？

【问题讨论】：

使用 make 时的问题是我必须至少构建一次所有内容，因此还需要依赖项的源文件。尤其是在重建依赖库时，可能会非常耗时并严重影响生产力。还是我错过了什么？
这似乎是一个有用的问题。也许这个问题可以移植到另一个更欢迎这些问题的站点？我正在寻找 C++ 依赖管理的最佳实践。
这已经晚了大约 10 年，所以这里有 3 种可能性：你误用了 maven，你错过了 maven 的全部要点，或者 10 年前我没有对 C++ 使用 maven 对 C++ 的用处要小得多。我不能说 2009 年，但根据最近几年的经验，maven 正是您所描述的问题所用的。它完全符合您的要求，并且非常有效和良好，并且不会做您声称的负面事情。任何在 2019 年或之后阅读本文的人都应该强烈考虑为此目的使用 maven。

标签： c++ maven build dependency-management

【解决方案1】：

初步回答：我建议使用 CMake。它是一个多平台的 make 文件生成器（也可以生成 Visual Studio 或 Eclipse CDT 项目）。

http://www.cmake.org/

我确实有很好的经验。我最喜欢它的地方在于能够生成通用项目结构。因此，您通常可以包含用于单元测试等的子项目查找，而无需每次都更改脚本。

他们还有很多关于如何查找项目所需的预安装构建库的模块（如 Boost、QT 等）

更新：与此同时，为 C++ 引入了包管理。一些值得关注的项目：

conan.io 与主要构建工具集成：
- CMake
- Visual Studio
- 生成文件
- XCode
- ...
cpm 基于 CMake（注意 CPM 没有得到积极维护。）
Buckaroo

注意正如@RAM 在 cmets cpm 中指出的那样，不再积极维护。

【讨论】：

几个月前我使用过 CMake，确实，检查预安装的库非常有效。但是，其他二进制依赖项（即来自我的子项目的依赖项）无法轻松管理。我错过了什么吗？
@weberste，实际上没有类似 C/C++ 的 maven 工具。开发人员尝试使用类似 apt-get 的工具来处理依赖管理。
cpm 没有得到积极维护，自 2015 年初以来就已停止使用。
@RAM：感谢您指出这一点。我在帖子中添加了一条关于您的注释。
CMake 是一个构建系统，查找依赖项的能力有限。它不是 NPM、Cargo 等意义上的依赖管理器。

【解决方案2】：

对于依赖管理，它存在一个正在实现此类工具的新项目（它是一家初创公司）：https://github.com/biicode（C++ 依赖管理器）。您可以添加您的依赖项，它应该可以工作。

目前项目名称为conan.io，已被JFrog收购。

更新：该项目已死...不幸的是，这家初创公司似乎无法获得足够的付费客户，但服务器似乎工作正常...

UPDATE2：似乎有一个替代项目：conan.io（感谢@mucaho）

【讨论】：

我可以删除链接..项目已关闭，现在是conan.io
感谢您的更新！我主要是出于好奇，看起来仍然可以在他们的 github 上四处寻找documentation；它可能不如网站上的内容好，但我想总比没有好。只是想知道，conan.io 只是品牌重塑还是完全不同的产品？
不是一个品牌重塑，而是一个从头开始的全新项目，其中包含所有经验教训：完全开源、完全分散并使用内部服务器、支持所有构建系统、管理二进制文件。

【解决方案3】：

我推荐以下高级构建系统：

Maven Nar 插件：Using Maven for C/C++ projects
Gradle cpp plugin：这是一种更简单的方法，但目前正在孵化中，here the main features and a roadmap。
Conan 是更多的 C++ 方法，它是多平台的，它支持最常见的 C++ 构建系统。

【讨论】：

Maven Nar 插件得到很好的支持。我用过它，到目前为止我很喜欢。但是，您需要了解 Maven 不适合单一存储库。大多数 C++ 解决方案都需要 Mono repo 处理共享库等。

【解决方案4】：

如果你只想要依赖管理，试试Ivy，它可以很好地与Ant 集成（我假设NAnt 可以基于这个blog 做同样的事情，它是从Ivy 网站链接的）。

还有Byldan，一个.Net 版本的Maven。不过，不知道这对你有多大用处。

【讨论】：

【解决方案5】：

Make 和 GCC 是非常好的依赖检查组合。

GCC 可以自动生成 'make' 依赖文件（-MD 命令行开关），以便能够重建所有依赖于给定头文件的源文件，例如。

我有一些简单的规则可以剪切并粘贴到我的 makefile 中：

# compile c files   
%.o:    %.c
    ${CC} ${CFLAGS} -c $< -MD -MF $(<:%.c=%.dep) -o $@

# compile c++ files
%.opp:  %.cpp
    ${CPP} ${CPPFLAGS} -c $< -MD -MF $(<:%.cpp=%.dep) -o $@

现在，如果您的目标文件在 OBJ_C 和 OBJ_CPP 列表中声明：

.PHONY: cleandep
cleandep:
    rm -f $(OBJ_C:%.o=%.dep) $(OBJ_CPP:%.opp=%.dep)

-include $(OBJ_C:%.o=%.dep) $(OBJ_CPP:%.opp=%.dep)

Make 当然可以跟踪与其他项目的依赖关系等，例如必要时也重建一个共享库。

例如，如果您的其他团队总是将他们最新的 DLL 放在某个共享文件夹中：

myapp: ${SRC_CPP} ${LIB_DIR}other_team.lib
  ...

${LIB_DIR}other_team.lib: /shared_folder/latest/other_team.lib
  cp /shared_folder/latest/other_team.lib ${LIB_DIR}other_team.lib

【讨论】：

查看我对这个解决方案的担忧所附的评论
如果一个目标依赖于另一个文件，例如您的可执行文件依赖于共享库，您可以为该共享库制定规则，以确保您的库副本是最新的，而不需要源，例如通过简单地从特定位置或执行某些版本控制更新等获取最新副本。
${CC} ${CFLAGS} -c $< -MD -MF $(<:%.c=%.dep) -o $@ 我很难解析出所有这些 Make 符号，如果你想在命令行中独立运行它，它看起来像g++ -c main.cc -MD -MF test 这样的东西，它会把结果在名为“测试”的文件中。

【解决方案6】：

编辑：

Biicode 已弃用

替代：Conan.io

【讨论】：

Biicode is dead。继任者看起来是Conan.io。

【解决方案7】：

我推荐conan，我最近一直在使用它。维护项目中的所有依赖库和二进制文件非常强大。

【讨论】：

【解决方案8】：

您可以为使用过的库创建 NuGet 包，并使用 NuGet 进行依赖管理。

另请参阅，NuGet for C++

【讨论】：

NuGet 是 Visual Studio 扩展
@Toughy，它也可以用作独立的依赖管理。 (4M可执行文件)

【解决方案9】：

有许多工具位于 SCons 之上，提供类似于 Autotools 的更高级别的功能，它们试图让开发人员的生活更轻松（例如 WAF、SNOCS）。不幸的是，SCons 本身有一个主要缺点 - 大型项目的编译时间较长。

对于那些寻求简单依赖管理并在单个命令（编译器、x86/x64、调试/发布、静态/共享库、测试/安装目标等）。

SNOCS 还尝试通过将项目配置输出存储在单独的文件中来解决编译时间长的问题，这允许后续构建完全跳过配置阶段并直接进入构建阶段（最后一个功能正在构建中）

CMake 的配置在较大的解决方案中变得乏味，因此构建系统维护需要开发人员的大部分时间。幸运的是，正如 Martijn 已经提到的那样，biicode“使用 CMake 生成您的项目及其依赖项”。

【讨论】：

【解决方案10】：

试试SCons

SCons 是一种开源软件构建工具，即下一代构建工具。将 SCons 视为经典 Make 实用程序的改进的跨平台替代品，具有类似于 autoconf/automake 和编译器缓存（如 ccache）的集成功能。简而言之，SCons 是一种更简单、更可靠、更快捷的软件构建方式。

【讨论】：

SCons 没有任何内置的依赖管理或存储库。

【解决方案11】：

我建议使用所有构建依赖系统之母：make。

【讨论】：

我广泛使用它。 GCC 可以制作“make”可以吃的依赖文件。足够的另一个答案，也许......
make 实际上是每个人都想通过查看 build -automation-systems 来避免/替换的东西

【解决方案12】：

试试 scons，你会被迷住的。 Make 已经过时，维护起来困难且昂贵。

【讨论】：

我查看了 Scons，但没有找到管理二进制依赖项的方法。你有这方面的例子吗？
由于 scons 是 python，你可以编写任何你想要的代码来管理你的二进制依赖。也许在你的二进制依赖目录中有一个“SConscript”也有帮助。我不确定你在这里有什么要求。佩德罗。
所以你建议一个基于“我不确定你需要什么，但你可以自己用 Python 编程”的工具。那你为什么需要scons呢？