C++构建系统

Question

我将很快开始一个新的C++项目(也可能有一些C组件),我正在寻找一个现代的,工业级的(即非beta)构建系统.该软件将在3 - 5年内由多个开发人员创建,并将在Linux上运行(稍后可能支持Mac OS X和Windows ).我正在寻找具有make比例如更好的可理解性,易用性和可维护性的东西,但仍然足够强大以处理复杂的项目.开源软件是首选.

我开始寻找到Boost.Build,CMake,Maven和SCons到目前为止,喜欢的功能和所有这些概念,但我缺乏经验,使一个大型项目的决定.

Answer 1

我没有其他人的经验,但如果您正在寻找跨平台的跨工具链构建系统,请使用CMake.CMake实际上不是一个构建系统,它是一个构建脚本生成器 - 它为许多构建系统生成实际的构建脚本,并且(在我看来,这是实力)为Visual Studio和KDevelop等主要IDE生成项目文件.顺便提一下,最近的KDevelop版本具有Intellisense for CMake文件.

生成的构建脚本或Visual Studio解决方案不像手动创建时那样优雅,但由于您也不必手动维护它们,所以没关系.

CMake的缺点是它并没有真正附带很多内置工具,或者是一种简单的扩展方法(比如MSBuild,当然这只是一个构建系统,而不是一个生成器).我们的Linux开发人员倾向于调用Unix命令行工具来执行压缩/解压缩等操作,这些工具在典型的Windows安装中不可用,而相比之下,MSBuild在社区项目中提供了数千个附加命令,因此您无需使用在命令行中,为MSBuild创建一个新的任务非常简单.我目前正在研究如何解决CMake的这些限制,因为它目前意味着我们无法完全构建在Windows上,即使代码本身可以正常构建.

编写CMake文件并不是一种美妙的体验,但没关系.这种语言有一些奇怪的怪癖(比如必须在else和endif中完全重复if条件,这会让你发疯,特别是在试验时),你真的,真的很讨厌在每个文件中都有一个名为CMakeLists.txt的文件.每个目录都有自定义构建规则(在大型项目中可能很多),它们都只显示在IDE中的名称;)

Answer 2

未来几年......

• 从我所看到的,SCons正在逐渐消失.我完全不喜欢它.
• Waf太棒了(在我看来).如果您正在研究SCons,请首先尝试Waf.但是,并行构建始终会显示所有发生的错误...因此,您的屏幕会出现错误消息.此外,扩展可能会有点复杂.
• Boost.Build是我的最爱之一,但却拥有世界上最糟糕的文档.除此之外,它非常灵活,几乎可以做任何事情.但有时候它可能有点慢.
• CMake只适用于生成Ninja脚本; 其他任何东西都是垃圾(1行1可执行项目的4000行makefile)
• Tup很好,但它没有任何配置.
• Autoconf仍然是autocrap.

其他未提及的:

• Kbuild有点奇怪,但看起来不错.这是我所知道的一切.
• mk-configure非常适合制作爱好者.
• 摇与摇C语言的灵活,让你做任何事......如果你知道Haskell和不介意放弃VS支持.
• Jamplus喜欢-m32在每个糟糕的编译器命令结束时推迟,这对64位系统来说很糟糕.
• 苔原可能有点重复,但仍然非常快速和准确.
• Bam ...... Tundra更好.它快速而不牺牲准确性.
• Gyp(用于谷歌Chrome/Chromium)未被记录,但是它是CMake的绝佳替代品.
• 如果你重视简洁,那么Premake就很棒,但是当看到简单的东西时,它会变得很烦人.
• Bakefile非常严格,但对于简单的项目非常有用.
• fbuild是我最喜欢的(和Boost.Build一起).它的文档很少,但有很多例子和非常易读的源代码.构建脚本也很​​简短.它用于构建(并为其设计)Felix.它也非常非常快,并且几乎总是非常准确,并且具有自动并行性,不会泛滥屏幕.永远.我正在使用它来构建一个正则表达式JIT引擎,我非常非常高兴.它也很容易扩展.然而,尽管我从未遇到过任何实际问题,但它在技术上仍处于测试阶段.

如果您喜欢makefile生成器,我建议使用fbuild或Boost.Build ...或Gyp.

如果你想扩展基本功能,一定要使用fbuild.如果你有很多特定于平台的标志/选项和大量的混乱,请使用Boost.Build.如果您需要makefile生成器或有很多配置,请尝试Gyp.

Answer 3

我已经使用SCons超过一年了,这真的很酷.它是一个完整的构建系统,而不是构建脚本生成器.

它是基于Python的,你可以在Python中编写SConstruct和SConscript(相当于Makefile),它允许你调用你想要的任何可用库,以及一个更清晰的Makefile授权语法.

由于Python是跨平台的,SCons也是如此,没有问题.

它捆绑了许多目标:

• 检测可用的二进制文件并自动将多个扩展名映射到正确的二进制文件
• 根据操作系统检测对象/库的正确扩展名,但您可以覆盖它
• 提供常用操作(在构建后延迟)的工具,如Move,Copy,Tar,你可以提供自己的python脚本并挂钩它们
• 开箱即用,但在每个级别提供许多自定义钩子

它非常高效,甚至提出了高级功能(比如在sqlite数据库中存储预处理文件的哈希值,而不是使用时间戳),即使您最终确定了策略.

它还提供免费的依赖循环检测(Makefiles绝对没有的东西),界面通常只是更好/自动化.

我说它有效吗？那么它显然允许并行执行多个作业;)

它也是免费的,就像在免费饮料中一样,随意贡献;)

我只能推荐它.

Answer 4

另外一个工具是TUP.我使用这个工具的经历非常好.托普

• 自动处理依赖关系(无需调用gcc -M).
• 使用部分依赖图,因此它非常快.
• 它以一种出色的方式支持递归目录结构(Tuprules.tup)
• 以出色的方式支持git:可以根据目标列表自动创建.gitignore文件.
• 非常容易使用,Tupfiles的语法非常简单.
• 它维护源文件的一致构建,即使重命名文件或删除文件也是如此.因此,构建的二进制文件始终反映源的当前状态.这也意味着,您永远不需要清理您的项目.

在将它用于两个非常复杂的项目后,我只能说一件坏事:

• 与ClearCase动态视图一起使用很复杂.

Answer 5

我有机会自己比较所有这些.首先我们使用了make.这很难看.你必须成为专家才能真正了解正在发生的事情.我不会再忍受痛苦了.

然后我们搬到了SCons.它的语法还可以,你仍然可以做丑陋的事情,因为你可以编写自己的脚本,这些脚本往往是程序.这为您提供了很大的灵活性.但是我们踢了SCons,因为我们不得不等待大约20秒的时间进行项目扫描,另外20次进行构建.然后我的大学编写了python代码来将它的扫描结果缓存到文件中,几乎使性能翻倍.您仍然需要等待大约20秒才能进行构建,当您添加文件或从项目中删除一个文件时,您必须使用--fill-cache参数重新运行构建.

然后我把项目移到CMake,这绝对是我的首选工具.它的结构和语法非常易读且也有文档记录.它为几乎每个IDE生成项目,并且早期支持市场上的新IDE.然后,构建过程与IDE一样快,只需在添加新项目或更改项目属性时返回到CMake以继续使用CMake

所以我建议CMake