C ++构build系统

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

我到目前为止已经开始关注Boost.BuildCMakeMavenSCons ,喜欢所有这些特性和概念,但是我缺乏为大型项目做决定的经验。

Solutions Collecting From Web of "C ++构build系统"

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

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

由于Python是跨平台的,SCons也是如此,在那里没有问题。

它捆绑了很多目标:

  • 检测到可用的二进制文件,并自动将许多扩展名映射到正确的二进制文件
  • 根据操作系统检测对象/库的正确扩展名,尽管您可以覆盖它
  • 为移动,复制,焦点提供常用操作的设施(在构建之后被延迟),并且您可以提供自己的Python脚本并挂钩它们
  • 开箱即用,但在每个级别上都提供了许多定制化的钩子

这是非常有效的,甚至提出了高级功能(如将预处理文件的散列存储在sqlite数据库中,而不是使用时间戳),即使您最终决定了策略。

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

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

而且它也是免费的,就像免费饮料一样,随时可以贡献;)

我只能推荐它。

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

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

CMake的不足之处在于它并不是真的带有很多内置工具,或者是一个简单的扩展方法(比如MSBuild,当然这只是一个构建系统,而不是一个生成器)。 我们的Linux开发人员倾向于调用Unix命令行工具来执行诸如压缩/解压缩之类的东西,这在典型的Windows安装中是不可用的,而MSBuild从社区项目中可以获得数以千计的附加命令,所以您不需要使用命令行,为MSBuild创建一个新的任务非常简单。 我目前正在研究如何解决CMake的这些限制,因为它目前意味着我们不能完全在Windows上构建,尽管代码本身可以很好地构建。

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

未来几年…

  • 从我所看到的, SCons正在流行起来。 我根本不喜欢它。
  • Waf真棒(在我看来)。 如果您正在研究SCons,请先尝试Waf。 但是,并行构建会始终显示所有发生的错误…因此,期待屏幕上充满错误消息。 而且,扩展可能会有点复杂。
  • Boost.Build是我的最爱之一,但却是地球上最糟糕的文档。 除此之外,它非常灵活,可以让你做任何事情。 有时候可能有点慢。
  • CMake只适用于生成忍者脚本; 其他任何东西都是垃圾(1行1个可执行项目的4000行makefile)
  • Tup很好,但是缺少配置的东西。
  • Autoconf仍然是autocrap 。

其他未提及的:

  • Kbuild是一个有点古怪,但看起来不错。 这是我所知道的一切。
  • mk-configure非常适合做恋人。
  • 用shake-language-c来动摇是非常灵活的,可以让你做任何事情…如果你了解Haskell并且不介意放弃VS的支持。
  • Jamplus喜欢在每一个令人厌烦的编译器命令结束时将-m32 移到 64位系统上。
  • 苔原可以是一个重复,但仍然非常快速和准确。
  • Bam … Tundra更好。 它速度快,不会牺牲准确性。
  • Gyp (用于Google Chrome / Chromium)没有记录,但是是CMake的一个很好的选择。
  • 如果你珍惜简单, Premake是非常棒的,但是当它看起来很简单的时候,它会变得烦人。
  • Bakefile是非常有限的,但对于简单的项目来说非常有用 。
  • fbuild是我最喜欢的(与Boost.Build一起)。 这是相当没有文档,但有很多的例子和非常可读的源代码。 生成脚本也很短。 它被用来为Felix构建(并且被设计)。 它也非常非常快,而且几乎总是非常准确,并且具有自动并行性,不会使您的屏幕泛滥。 永远。 我正在使用它来构建一个正则表达式JIT引擎,我非常高兴。 这也很容易扩展。 不过,从技术上来说它还处于测试阶段,尽管我从来没有遇到过任何真正的问题。

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

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

我有机会自己比较所有这些。 首先我们使用make 。 这是丑陋的。 你必须专家真正了解发生了什么事情。 我不会再次痛苦。

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

然后我把项目移到了CMake上 ,这肯定是我选择的工具。 它的结构和语法非常好可读,也有文档记录。 它为您生成几乎所有IDE的项目,并且早期支持市场上的新IDE。 构建过程与IDE一样快,只需要添加新项目或更改项目属性以保留CMake时,就只需返回到CMake

所以我会建议CMake

另一个工具是TUP 。 这个工具我的经验非常好。 托普

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

在用于两个相当复杂的项目之后,我只能说一件坏事:

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

看看Waf 。 这是一个体面的系统,我用我的大部分项目是用Python编写的,源自Scons,Make和其他类似的系统。

从你提到的,我已经试过Maven – 它太严格,不扩展,是专为Java,所以我不会考虑它。 我也听到有人使用“Automake”,他们开玩笑地称之为“Autobreak”

恕我直言,寿命长的项目应该更喜欢纯粹的Make,GNU Make。 Make有几个强大的功能,通常不使用,这有助于避免样板代码(例如使用eval / call,非递归构建)。 它与其他任何构建系统兼容(例如,在我们的项目中,我们成功地将它与Ant结合,用于Java构建)。 它有一个很好的文档,并为大多数开发人员所熟悉。

根据我的经验,总是可以将项目的制造系统隔离到大多数项目makefiles包含2行的地方:目标名称和“include $ {MKSYS_HOME} /makesystem.mk”。

我努力了:

  1. scons <—太慢了。
  2. waf <—很好,但在我看来是过度工程 。 有时候不容易猜到要做什么。
  3. cmake <—不好的语法,但相当强大,速度相当快。
  4. autotools(mythbuster docs) <—只有unix。 最好的处理交叉编译。
  5. tup < – 它太快而正确,令人难以置信。

你正在寻找工业实力。 我会说scons出来了,因为它太慢了恕我直言,即使它很好。 它也没有配置阶段。

waf看起来不错,但是我发现如何以正确的方式来做一些事情,特别是嵌套的项目。

autotools是非常强大的,但它是如果你想支持Windows。 交叉编译在autotools中非常强大。

CMake:我认为你应该去做这个。 它非常快,它像自动工具一样处理配置,但在Windows中工作,它为xcode,visual studio,make等生成项目。 如果你有一个多平台的项目,这是一个很好的功能,因为你可以生成所选IDE的项目。 但是我必须说,我不太喜欢这个语法。 无论如何,它处理好大项目。 如果我想要一个“工业强度”的解决方案,我会去cmake。 即使我个人讨厌一点,这是唯一可行的选择。

Tup:我认为这更多是以unix为导向的。 但我必须说,对我来说,这是最好的,而且是非常快速和简单的。 我喜欢它。 但是你需要的是cmake。

另一个要看的是Bakefile 。

它的主要优点是采用了一个相对简单的输入文件(不管怎样,XML都是简单的),并且输出了许多不同的本机构建系统文件:基于autoconf的系统(Linux,OS X命令行,BSD …)上的Makefile.in, Visual C ++解决方案和项目文件,Xcode项目,MinGW和通用Unix Makefiles等

这就是说,我不知道我会从一开始就使用这样的系统。 由于最初的目标是Linux,而其他的是“maybes”,所以考虑从automake开始,并将Bakefile(或其他)移走,直到进行移植。 在实际需要之前建造东西总是一个错误。 在这种情况下总是存在一个折衷 – 最常见的分母综合征 – 如果你今天不需要支付罚款,就把它扣除,直到你必须支付; 你可能永远不必支付。 如果你用automake去建立你的文件,这个迁移不会太痛苦。