C + + 构建系统-使用什么？

我正在考虑用 C + + 开始一个新项目——最初只用我自己的时间——并且我正在研究可用的构建系统。答案似乎是“很多，而且他们都很糟糕”。

我特别需要的功能是:

  1. C + + 11支持
  2. 跨平台(Linux 作为主要目标，但至少也能在 Windows 上构建)
  3. 良好的单元测试支持
  4. 支持分离代码的多个模块
  5. 支持代码生成(使用 asn1c 或 Protobuf ——还不能100% 确定)
  6. 易于维护

现在，我知道我可以做1-4这些使用 CMake 和 Autotools 足够容易。可能还有 SCons 和 Waf 还有其他几个人。问题是，我从来没有想出如何正确地使用它们来生成代码——也就是说，在构建过程首次运行之前不存在的源文件，所以构建系统必须能够将源文件转换成可执行代码，但是在构建开始之前实际上并不知道。(ASN1C 特别生成几十个头文件和源文件，这些文件必须能够一起工作，实际生成的文件集取决于你的 asn 文件的内容)还有一个事实是，这些都不是特别容易维护-CMake 和 Autotools 有自己的庞大的脚本集，你需要管理他们的工作，和 Waf 和 Scon 要求任何人与他们一起工作有体面的 Python 知识(我不)与他们一起工作...

那么，对于这种情况，建议使用什么样的构建系统呢？或者我现在只能使用 make 文件和 shell 脚本？

84781 次浏览
小开

我使用了 SCons，并且对这个构建系统印象深刻。SCons 可以通过 Python 和 Python 自身进行扩展——这非常好，因为 Python 具备所有您需要的东西，只需要编写逻辑代码，所有底层功能都已经在 SCons 和 Python 中实现，并且是跨平台的。如果有良好的编程技能，那么您的构建脚本将看起来完美和容易。

Make，CMake 和类似的 build 系统看起来像是宏观层面的垃圾。 沃夫是 SCons 的类比。我正在尝试沃夫，但 SCons 会更友好，所以我留在 SCons。

人们认为 SCons 太慢了，但是在一个项目中，我没有看到 make 和 SCons 在构建速度上有什么不同。相反，SCons 能够很好地处理并行构建，而 make 则有很大的问题。

此外，SCons 允许您通过模板进行配置、构建、部署、生成配置、运行测试以及执行任何其他可以使用 python 和 SCons 进行编码的任务。这是个很大的优势。

对于一个简单的项目，CMake 也是一个不错的选择。

小开

“很多，而且很糟糕”加1

但是，“最丰富”和“最具可伸缩性”的可能是 CMake，它是一个 Makefile 生成器(也生成本地 MSVC + + *.proj/*.sln)。奇怪的语法，但是一旦您学会了它，就可以很好地为不同的平台生成构建。如果我“重新开始”，我可能会使用 CMake。它应该能够处理您的列表，尽管您的“代码生成”可能会在构建系统之外采取“自生自灭”的方式，这取决于您想要做什么。(见下文)

对于简单的项目，使用 QMake生成器是可以的(不需要使用 Qt 库来使用 QMake)。但是，您并不是在描述“简单”——代码生成和“额外阶段”意味着您可能需要 CMake或者具有丰富 API 的东西用于您自己的扩展，比如 Scons(或 Waf)。

我们在工作中使用 骗子。它产生“防弹建设”，但它真的很慢。没有其他系统能像 Scons那样防弹。但是很慢。它是用 Python 编写的，我们已经扩展了“工作空间-组织”的接口(在这里我们仅仅指定模块依赖) ，这是 Scons设计意图的一部分(这种类型的扩展是通过 Python 实现的)。很方便，但是构建速度很慢。您可以获得防弹版本(任何开发人员框都可以发布最终版本) ，但是速度很慢。而且很慢。但是，不要忘记，如果使用 Scons，它的速度很慢。而且很慢。

一想到2000年已经过去十年了，我们仍然没有飞行汽车，我就感到不舒服。我们可能要再等上一百年或者更久才能拿到它们。然后，我们都可能会飞行在我们的飞行汽车 还是正在建设与蹩脚的建设系统。

是的，他们都很糟糕。

[关于代码生成]

Scons工作在“阶段”上，它们是“有点静态的”。它可以构建作为构建的一部分生成的代码(人们通过几种不同的方式来完成) ，但是这被描述为“一些非常不像 Scon 的东西”。

如果只是简单地“预处理一些文件并生成源文件”，那么没什么大不了的(您有很多选项，这就是为什么编写 qmake的原因——用于 moc对 *.hpp/*.cpp文件的预处理)。

但是，如果您正在以一种“沉重的方式”进行此操作，那么您需要自己编写脚本。例如，我们有作为构建的一部分的脚本，它查询数据库并生成 C + + 类以在“层”之间进行接口(在传统的3层应用程序开发中)。类似地，我们通过 IDL 生成服务器/客户机源代码，并嵌入版本信息，以允许多个客户机/服务器同时运行不同的版本(对于相同的“客户机”或“服务器”)。大量生成的源代码。我们可以“假装”它是“构建系统”，但实际上，它是“组态管理”的一个非常重要的基础设施，其中一部分是“构建系统”。例如，这个系统必须将“下载”和“启动”服务器作为这个过程的一部分。类似地，回归测试作为这个过程的一部分执行，版本之间有大量的“报告”和“差异测试”——所有这些都作为我们的“构建脚本”的一部分。

小开

顺便说一句，预制

Http://industriousone.com/premake

在维基上也有一个 专题网页。

小开

骗子是非常友好和灵活的系统，但你是对的，洛萨，它真的很慢。

但是有一种方法可以提高用 Python 编写的程序的性能。JIT 的这种使用。在所有已知的项目中，PyPy 是一个非常强大、发展迅速且受到 JIT 支持的 Python 2.7实现。PyPy 与 Python 2.7的兼容性简直令人惊叹。但是，Scon 在 PyPy 兼容性 wiki上声明为不受支持的项目。 另一方面，Waf 被建模为基于 Python 的 autotools 子工具，PyPy 基础设施完全支持它。在我的项目中，在转换到 PyPy 的过程中，程序集的速度提高了5-7倍。您可以看到来自 PyPy 的性能报告.

对于现代和相对快速的建设系统 Waf 是不错的选择。

小开

你可以使用 希德林。注意，不过目前它只支持 C，并且与作者的 Unity 和 CMock 测试框架紧密耦合。

它可以很容易地分叉和修改，以便与 C + + 编译器和单元测试/模拟框架一起工作。

同样值得一提的是 Tup。它的速度非常快，但它对测试框架等一无所知，这意味着你必须使用 Tup 编写自己的构建系统。如果您计划进行 TDD，Tup 可能是最佳选择。

小开

现在可以使用 Gradle: https://docs.gradle.org/current/userguide/native_software.html

自从我最初发布这篇文章以来，这篇文章似乎已经成熟了不少。说这个项目正在“孵化”的页面已经消失了，但是我找不到任何官方声明去除这个状态。

小开

我发现这些，我还没有亲自使用它们所有:

Ninja ，一个专注于速度的小型构建系统，Google 现在使用 Ninja 来构建 Android 而不是 Make: 链接。

Shake ，一个强大而快速的构建系统。

一个高性能的构建系统。基于 算法的设计。 Tup 分析。

现在所有这些都是跨平台的，并且支持 Windows。我还不确定你们其他的要求，因为我还没有亲自测试过。它们正在被用于商业开发，CIG抓住了忍者。我已经使用并且喜欢忍者的轻松和速度与项目生成器。前两个类似于骗子、蚂蚁等等。

小开

Google 构建系统是一个很好的选择: http://bazel.io/


提交答案