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

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

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

实际上，我试图为此使用Maven，但这非常麻烦，因为我不得不手动且非常频繁地创建软件包，Maven错过了最新的更改。另外，运行编译有点麻烦，因为我必须从Maven内部调用NAnt（我使用NAnt的功能直接构建Visual Studio解决方案）。

有关如何执行此操作的任何提示和想法？

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

http://www.cmake.org/

我真的有很好的经验。我最喜欢的是生成通用项目结构的能力。因此，您通常可以包含子项目查找以进行单元测试等，而无需每次都更改脚本。

他们还有很多模块，用于查找项目所需的预装构建库（例如Boost，QT等）。

更新：同时，我们付出了一些努力来引入C ++的软件包管理。一些值得关注的项目：

• conan.io与主要的构建工具集成：
  • CMake的
  • 视觉工作室
  • 生成文件
  • XCode
  • ...
• CPM基于CMake的（注 CPM没有被积极维护。）
• 巴卡鲁

注意，通过在评论CPM @RAM指出的是不再是积极维护。

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

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

更新：该项目已死...不幸的是，这家初创公司似乎无法获得足够的优质付费客户，但服务器似乎运行良好...

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

我建议使用以下高级构建系统：

• Maven Nar插件：将Maven用于C / C ++项目
• Gradle cpp插件：这是一种更简单的方法，但是目前正在孵化中，这里是主要功能和路线图。
• Conan是更多的C ++方法，它是多平台的，并且支持大多数常见的C ++构建系统。

如果仅需要依赖项管理，请尝试Ivy，它可以与Ant很好地集成（并且我认为NAnt可以基于此博客（从Ivy站点链接到该站点）进行相同的操作）。

还有Byldan，Maven的.Net版本。不知道这对您有多好。

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

编辑：

Biicode已弃用

另类： Conan.io

我建议我最近使用的柯南。维护项目中所有依赖的库和二进制文件非常强大。

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

另请参阅NuGet for C ++

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

我可以推荐尝试SNOCS（这是一个SCons的反向），对于那些你寻找一种简单的依赖管理，并在单个命令选择编译选项（编译器，在x86 / x64，调试/发布，静态/共享库，测试/安装目标等）。

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

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

尝试SCons

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

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

尝试使用scons，您将上瘾。Make已过时，维护困难且昂贵。