类似Maven的C ++依赖pipe理?

假设我有一个C ++项目被拆分成几个子项目。 子项目都产生一个DLL,不同的开发团队在每个子项目上工作。 现在,如果我想构build主项目,是否有办法避免自己构build所有的子项目?

简而言之,我正在寻找一些能够像Maven一样对Java进行依赖pipe理(即二进制文件和头文件)的方法。

实际上,我尝试过使用Maven,但是这样做比较麻烦,因为我必须手动创build软件包,而且相当频繁,Maven错过了select最近的更改。 另外,运行编译还有点麻烦,因为我必须从Maven内部调用NAnt(我使用NAnt的function直接构buildVisual Studio解决scheme)。

任何提示和想法如何做到这一点?

我会build议使用CMake。 它是一个多平台的make文件生成器(也生成Visual Studio或Eclipse CDT项目)。

http://www.cmake.org/

我做了很好的经验。 我喜欢的最好的事情是生产通用项目结构的能力。 所以你可以一般地包含子项目查找unit testing等,而不必每次都改变脚本。

他们还有很多关于如何查找项目所需的预安装构build库的模块(如Boost,QT等)


更新:与此同时,还有一些努力来为C ++引入包pipe理。 有些项目值得一看:

  • conan.io集成了主要的构build工具:
    • CMake的
    • 视觉工作室
    • Makefile文件
    • 的XCode
  • 基于CMake的CPM

对于依赖pipe理,它存在一个新的项目(这是一个启动公司),它正在实现这种types的工具: https : //www.biicode.com/ (一个C ++依赖pipe理器)。 你可以添加你的依赖,它应该工作。

目前,该项目名称为conan.io ,被JFrog收购。

更新:该项目已经死了 …不幸的是,似乎创业无法得到足够的付费客户,但服务器似乎工作正常…

UPDATE2:似乎有一个替代项目: conan.io (谢谢@mucaho)

我推荐以下高级构build系统:

  • Maven Nar插件: 在C / C ++项目中使用Maven
  • Gradle的cpp插件 :这是一个更简单的方法,但它正在孵化, 这里的主要特点和路线图 。

如果你只需要依赖pipe理,试试常春藤 ,它很好地集成了Ant(我假设NAnt可以根据这个从Ivy站点链接的博客来做同样的事情)。

另外还有一个.Net版本的Byven 。 不知道这对你有多好。

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

GCC可以自动生成“make”依赖文件(-MD命令行切换),以便能够重build所有依赖给定头文件的源文件。

我有一些简单的规则,我把它们粘贴到我的makefiles中:

# 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可以跟踪其他项目的依赖关系,例如,也可以根据需要重build共享库。

例如,如果其他团队始终将其最新的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开发人员的多平台工具和托pipe服务

编辑:

Biicode已弃用

select: Conan.io

我推荐我现在使用的柯南 。 在项目中维护所有相关的库和二进制文件是非常强大的。

您可以为使用的库创buildNuGet包,并使用NuGet进行依赖pipe理。

另请参阅NuGet for C ++

有许多工具位于SCons之上,提供了类似于试图让开发者生活更轻松的自动工具(例如WAF,SNOCS)的更高级的function。 不幸的是,SCons本身有一个主要的缺点 – 大型项目的编译时间较长。

我可以推荐尝试SNOCS (这是一个SCons逆转)为那些寻找一个简单的依赖pipe理,并select单一命令(编译器,x86 / x64,debugging/发布,静态/共享库,testing/安装目标等)。

SNOCS还尝试通过将项目configuration输出存储在单独的文件中来解决冗长的编译时间问题,从而允许相应的构build完全跳过configuration阶段并直接进入构build阶段(现在正在构build上一个function)

CMake的configuration在更大的解决scheme中变得单调乏味,所以构build系统维护占用了开发人员大部分时间。 幸运的是,Martijn已经提到biicode “使用CMake来产生你的项目的依赖”。

我build议使用所有构build依赖系统的母亲:make。

试试SCONS

SCons是一个开源软件构build工具,也就是下一代构build工具。 把SCons想象成一个经典的Make实用程序的改进的跨平台替代品,其集成function类似于autoconf / automake和编译器caching(如ccache)。 简而言之,SCons是构build软件的一种更简单,更可靠,更快捷的方式。

尝试scons,你会被迷住。 制作过时,维护困难和昂贵。