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

C++ Build Systems - What to use?

提问by Graham

I'm looking at starting a new project in C++ - just in my own time initially - and I'm investigating the build systems that are available. It would appear that the answer is "Many, and they're all awful".

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

The features that I specifically need for this are:

我特别需要的功能是：

1. C++11 support
2. Cross platform (Linux as main target, but able to build on at least Windows as well)
3. Decent unit testing support
4. Support for multiple modules for separating code out
5. Support for code generation (Using asn1c or protobuf - not 100% sure yet)
6. Easy to maintain

1. C++11 支持
2. 跨平台（Linux 作为主要目标，但至少也可以在 Windows 上构建）
3. 体面的单元测试支持
4. 支持多个模块分离代码
5. 支持代码生成（使用 asn1c 或 protobuf - 还不是 100% 确定）
6. 易于维护

Now, I know I can do 1-4 of those using CMake and Autotools easily enough. Probably also with SCons and Waf and the couple of others too. The problem is that I've never worked out how to correctly do code generation using them - that is source files that do not exist until the build process is first run, so source files that the build system must be able to convert into executable code but doesn't actually know about until the build starts... (ASN1C in particular generates dozens of header and source files that must be able to work together, and the actual set of files generates depends on the contents of your asn file) There's also the fact that none of these are especially easy to maintain - CMake and Autotools have their own huge set of scripts that you need to manage for them to work, and Waf and Scons require that anybody working with them has decent knowledge of python (I don't) to work with them...

现在，我知道我可以轻松地使用 CMake 和 Autotools 完成其中的 1-4 个。可能还有 SCons 和 Waf 以及其他几个人。问题是我从来没有想过如何使用它们正确地生成代码 - 即在首次运行构建过程之前不存在的源文件，因此构建系统必须能够将源文件转换为可执行代码但在构建开始之前实际上并不知道......（特别是 ASN1C 会生成几十个必须能够一起工作的头文件和源文件，而实际生成的文件集取决于您的 asn 文件的内容）还有一个事实，这些都不是特别容易维护 - CMake 和 Autotools 有自己的大量脚本，你需要管理它们才能工作，

So - what build systems are recommended for something like this? Or will I be stuck with make files and shell scripts for now?

那么 - 对于这样的事情，推荐什么构建系统？或者我现在会被 make 文件和 shell 脚本困住吗？

回答by charley

+1 for, "Many, and they're awful."

+1 表示“很多，而且它们很糟糕。”

But, the "richest" and "most-scalable" is probably CMake, which is a Makefile-generator (also generates native MSVC++ *.proj/*.sln). Weird syntax, but once you learn it, it can allow you to nicely generate builds for different platforms. If I "started-fresh", I'd probably use CMake. It should handle your list, although your "code-generation" could take on "a-life-of-its-own" beyond the build system depending on what you want to do. (See below.)

但是，“最丰富”和“最可扩展”的可能是CMake，它是一个 Makefile 生成器（也生成本机 MSVC++ *.proj/ *.sln）。奇怪的语法，但是一旦你学会了它，它可以让你很好地为不同的平台生成构建。如果我“重新开始”，我可能会使用CMake. 它应该处理您的列表，尽管您的“代码生成”可能会在构建系统之外进行“自己的生活”，具体取决于您想要做什么。（见下文。）

For simple projects, the QMakegenerator is ok (you don't need to use the Qt libraries to use QMake). But, you're not describing "simple" -- code generation and "extra-phases" means you probably want CMakeor something with a rich API for your own extensions, like Scons(or Waf).

对于简单的项目，QMake生成器就可以了（使用 QMake 不需要使用 Qt 库）。但是，您不是在描述“简单”——代码生成和“额外阶段”意味着您可能想要CMake或为您自己的扩展提供丰富的 API，例如Scons(或Waf)。

We use Sconsat work. It produces "bullet-proof-builds", but it's really slow. No other system will be as bullet-proof as Scons. But, it's slow. It is written in Python and we've extended the interface for our "workspace-organization" (where we merely specify module dependencies), and that is part of the Sconsdesign intent (this type of extension through Python). Convenient, but builds are slow. You get bullet-proof builds (any developer box can make the final release), but it's slow. And, it's slow. Don't forget that if you use Scons, though, that it's slow. And, it's slow.

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

It makes me ill to think that a decade after the Year 2000, we still don't have flying cars. We'll probably have to wait another hundred years or something to get them. And, we will then all probably be flying around in our flying cars that are stillbeing constructed with crappy build systems.

想到 2000 年之后的十年，我们仍然没有飞行汽车，这让我感到不适。我们可能还得再等一百年或什么才能得到它们。而且，我们可能都将乘坐我们的飞行汽车四处飞行，这些汽车仍在使用蹩脚的构建系统构建。

Yes, they are all awful.

是的，他们都很可怕。

[ABOUT CODE GENERATION]

[关于代码生成]

Sconsworks on "phases", and they are "somewhat-static". It can build code that is generated as part of the build (people are doing this in a couple of different ways), but this has been described as, "something very un-Scons-like".

Scons适用于“阶段”，它们是“有点静态的”。它可以构建作为构建的一部分生成的代码（人们以几种不同的方式执行此操作），但这被描述为“非常不象 Scons 的东西”。

If it's simple "preprocess some files and generate source files", then no biggie (you have lots of options, and this is why qmakewas written -- for the mocpreprocessing of *.hpp/*.cppfiles).

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

However, if you are doing this in a "heavy-manner", you're going to need to script your own. For example, we had as-a-part-of-the-build scripts that queried the databases and generated C++ classes to interface between the "layers" (in traditional 3-tier application development). Similarly, we generated server/client source code through IDLs, and embedded version information to permit multiple clients/servers to run simultaneously with different versions (for the same "client" or "server"). Lots of generated source code. We could "pretend" that is "the-build-system", but really, it's a non-trivial-infrastructure for "configuration management", of which part of it is the "build-system". For example, this system had to, "take-down" and "start-up" servers as a part of this process. Similarly, the regression-tests were executed as a part of this process, with heavy "reporting" and "difference-testing" between versions -- all as a part of our "build-scripts".

但是，如果您以“繁重的方式”执行此操作，则需要编写自己的脚本。例如，我们有作为构建脚本的一部分，用于查询数据库并生成 C++ 类以在“层”之间进行接口（在传统的 3 层应用程序开发中）。同样，我们通过 IDL 生成服务器/客户端源代码，并嵌入版本信息以允许多个客户端/服务器同时运行不同版本（对于相同的“客户端”或“服务器”）。大量生成的源代码。我们可以“假装”那是“构建系统”，但实际上，它是“配置管理”的重要基础设施，其中一部分是“构建系统”。例如，这个系统不得不“取下”和“

回答by Nate Glenn

You can use Gradle now: https://docs.gradle.org/current/userguide/native_software.html

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

This seems to have matured quite a bit in the years since I originally posted this. The page saying that the project is "incubating" has disappeared, but I can't find any official announcement removing this status.

自从我最初发布这篇文章以来，这似乎已经成熟了很多年。说项目“孵化”的页面已经消失了，但是我找不到任何取消此状态的官方公告。

回答by leetNightshade

I recently found out about these, I have not personally used them yet:

我最近发现了这些，我还没有亲自使用它们：

Ninja, a small build system focused on speed. Google now uses Ninja to build Android instead of Make: link.

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

Shake, a powerful and fast build system.

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

Tup, a high performance build system. Algorithmicbased design. Analysis of Tup.

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

All are now cross-platform and support Windows. I'm not yet sure about the rest of your requirements as, again, I have yet to test them myself. They are being used in commercial development, CIGpicked Ninja up. First two are akin to Scons, Ant, etc.

所有现在都是跨平台的并支持 Windows。我还不确定您的其他要求，因为我还没有亲自测试它们。它们被用于商业开发，CIG选择了 Ninja。前两个类似于 Scons、Ant 等。

回答by aegor

Scons is very friendly and flexible system, but you right, Lothar, it really slow.

Scons 是非常友好和灵活的系统，但是你说得对，Lothar，它真的很慢。

But there is a way to increase the performance of programs written in Python. This use of the JIT. Of all known projects, PyPy is a very powerful, fast-growing and motivated JIT-backed - Python 2.7 implementation. PyPy compatibility with Python 2.7 is simply amazing. However, Scons declared as unsupported project on the PyPy compatibility wiki. Waf, on the other hand, modeled as python-based autotools sucessor, is fully supported by PyPy infrastructure. In my projects the speed of the assembly has increased 5-7 times in the transition to PyPy. You can see the performance reports from PyPy.

但是有一种方法可以提高用 Python 编写的程序的性能。这使用了 JIT。在所有已知的项目中，PyPy 是一个非常强大、快速增长且有动力的 JIT 支持 - Python 2.7 实现。PyPy 与 Python 2.7 的兼容性非常惊人。但是，Scons 在PyPy 兼容性 wiki上声明为不受支持的项目。 另一方面，Waf被建模为基于 Python 的自动工具的继承者，完全由 PyPy 基础设施支持。在我的项目中，在过渡到 PyPy 的过程中，组装速度提高了 5-7 倍。您可以从 PyPy 中查看性能报告。

For modern and relatively fast build system Waf is good choice.

对于现代且相对较快的构建系统，Waf 是不错的选择。

回答by Mike B

Google build system is a good alternative: http://bazel.io/

谷歌构建系统是一个不错的选择：http: //bazel.io/

回答by Torsten

I used SCons and am impressed by this build system. SCons is extensible by python and python itself - it's great, because Python has all that you need, just code the logic, all the low-level functionality is already implemented in SCons and Python and is crossplatform. If have good programming skills then your build scripts will be looking perfect and easy.

我使用了 SCons，这个构建系统给我留下了深刻的印象。SCons 可以由 python 和 python 本身扩展 - 这很棒，因为 Python 拥有您需要的一切，只需编写逻辑，所有低级功能都已经在 SCons 和 Python 中实现并且是跨平台的。如果具有良好的编程技能，那么您的构建脚本将看起来完美而简单。

Make, CMake and similar build systems seems as trash of macroses. Waf is SCons analog. I'm trying Waf but SCons will be more friendly and so I stayed with SCons.

Make、CMake 和类似的构建系统似乎是宏的垃圾。Waf 是 SCons 模拟。我正在尝试 Waf，但 SCons 会更友好，所以我留在了 SCons。

By crowd opinion SCons is too slow, but in the middle of a project I didn't see any difference between make and SCons by build speed. Instead, SCons has well worked with parallel builds, while make has big troubles with it.

根据群众意见，SCons 太慢了，但在项目的中间，我没有看到 make 和 SCons 之间的构建速度有任何区别。相反，SCons 可以很好地处理并行构建，而 make 却有很大的麻烦。

Also, SCons allows you to get - configure, build, deploy, generate configuration from templates, run tests and do any other task that can be done can coding with python and SCons - all in one. That is a very big advantage.

此外，SCons 允许您获取 - 配置、构建、部署、从模板生成配置、运行测试和执行任何其他可以使用 python 和 SCons 编码的任务 - 全部合而为一。这是一个非常大的优势。

For a simple project CMake is also a good choice.

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

回答by user827992

just to add my cents: premake

只是为了增加我的美分：预制

http://industriousone.com/premake

http://industriousone.com/premake

there is also a dedicated webpageon the wiki.

维基上还有一个专门的网页。

回答by thegreendroid

You can use Ceedling. Note, however it only supports C at the moment and it is tightly coupled to the author's Unity and CMock testing frameworks.

您可以使用Ceedling。但是请注意，它目前仅支持 C，并且与作者的 Unity 和 CMock 测试框架紧密耦合。

It can be forked and modified to work with a C++ compiler and unit testing / mocking framework fairly easily.

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

Also Tupis a worthy mention. It is extremely fast but it knows nothing about testing frameworks etc. which means you'll have to write your own build system using Tup. If you plan on doing TDD, Tup is probably the way to go.

此外托普是值得一提。它非常快，但它对测试框架等一无所知。这意味着您必须使用 Tup 编写自己的构建系统。如果你打算做 TDD，Tup 可能是你要走的路。