成败：5种最佳构建系统

If we want to go beyond specialized task runners and web build systems, we probably think of the original Make. Make is a pretty simple but powerful application that follows a clear and concise design.

如果我们想超越专业的任务运行者和Web构建系统，我们可能会想到原始的Make。 Make是一个非常简单但功能强大的应用程序，它遵循清晰简洁的设计。

In this article, we’ll take a look at other popular build systems, which may fit your requirements even better than traditional solutions. The list is naturally far from being complete, but everything on here is there due to its features, impact, or uniqueness.

在本文中，我们将介绍其他流行的构建系统，它们可能比传统解决方案更好地满足您的要求。 当然，该列表还远远不够完整，但是由于其功能，影响或独特性，此处的所有内容都存在。

GNU Make (GNU Make)

The initial version of Make was written for the Unix operating system, but later other implementations and rewrites occurred, including the GNU Make. It’s required for building the Linux kernel. This implementation offers everything the original version had, along with additional extensions and improvements.

Make的初始版本是为Unix操作系统编写的，但后来发生了其他实现和重写，包括GNU Make 。 这是构建Linux内核所必需的。 此实现提供原始版本的所有内容，以及其他扩展和改进。

The basic concept is to write a special file, called “Makefile”, that describes the rules to build an application. Each rule may rely upon other given rules, forming a hierarchy. A rule usually exists in the form of a build target, or an output file. The idea is that a single rule defines how to create an output file from one or more required input files.

基本概念是编写一个称为“ Makefile”的特殊文件，该文件描述了构建应用程序的规则。 每个规则可以依赖于其他给定规则，从而形成层次结构。 规则通常以构建目标或输出文件的形式存在。 这个想法是，一条规则定义了如何从一个或多个必需的输入文件中创建输出文件。

The concept may sound simple, but saves Make developers from needing to create their own systems for evaluating if an output file needed to be created or not. Make gives us an abstraction layer that automatically performs the required checks. Every dependency for a rule is implicitly checked to determine if the input file changed since the last output file generation. This accelerates software build processes by omitting redundant compilations.

这个概念听起来很简单，但是使开发人员不必创建自己的系统来评估是否需要创建输出文件。 Make为我们提供了一个自动执行所需检查的抽象层。 隐式检查规则的每个依赖性，以确定自上次生成输出文件以来输入文件是否已更改。 通过省略多余的编译，可以加速软件构建过程。

CMake的 (CMake)

One of the earliest successors to Make was CMake, with ‘C’ standing for cross-platform. It features a true cross-platform solution for building software. Therefore, it’s mostly popular in projects that should be deployed across different platforms. The configuration files can be written with a scripting language that features a large list of commands.

Make最早的继任者之一是CMake ，“ C”代表跨平台。 它具有用于构建软件的真正的跨平台解决方案。 因此，它在应跨不同平台部署的项目中最为流行。 可以使用具有大量命令的脚本语言来编写配置文件。

CMake alone cannot run a build process. It’ll create a platform-specific file, which would be a Makefile on Linux. On Windows a Visual Studio compatible project file would be created, but there are other options such as using a Makefile as well. However, CMake is far more than just a layer on the top of the original Make. It can also automatically detect dependencies in languages such as C++ and Java. This makes the build process more reliable.

仅CMake无法运行构建过程。 它将创建特定于平台的文件，在Linux上将是Makefile。 在Windows上，将创建与Visual Studio兼容的项目文件，但是还有其他选项，例如也使用Makefile。 但是，CMake不仅仅是原始Make顶部的一层。 它还可以自动检测C ++和Java等语言的依赖关系。 这使构建过程更加可靠。

Another cool feature that comes with CMake is its ability to create packages in various formats. If we think of deployment, then creating a package sounds like the last step and probably also the most annoying one. Having a predefined solution for the process gives us a lot of comfort.

CMake附带的另一个很酷的功能是它能够创建各种格式的软件包。 如果我们考虑部署，那么创建一个程序包听起来就像是最后一步，可能也是最烦人的一步。 为该过程提供预定义的解决方案可以使我们感到很舒适。

耙 (Rake)

Why not create a build tool specifically for a programming language? We could name tools like MSBuild or others, which can be seen as such an attempt. But what if we want to go one step further and also use that programming language for the configuration files? Enter the world of Rake.

为什么不创建专门用于编程语言的构建工具？ 我们可以命名诸如MSBuild之类的工具或其他工具，可以将其视为这样的尝试。 但是，如果我们想更进一步，并且将该编程语言用于配置文件，该怎么办？ 进入Rake的世界。

Rake was not the first build tool that used an existing scripting language for setting up the build process. Nevertheless, its impact is undeniable. It’s the de facto standard for Ruby developers and since Ruby 1.9, Rake is also part of the standard library.

Rake并不是第一个使用现有脚本语言来设置构建过程的构建工具。 然而，其影响是不可否认的。 这是Ruby开发人员的事实上的标准，从Ruby 1.9开始，Rake也是标准库的一部分。

“What is the major advantage of Rake?” you might ask. First of all, it can process Ruby source files by default. Additionally, Ruby developers can use it instantly, as it does not require any new language or framework to be learned. Only the API of the tool is new, but the rest is familiar and follows the known patterns and principles. Finally, Rake uses Ruby’s advanced pattern matching to form regular expressions into filters for rules. For a bit more on Rake, check out this article on SitePoint.

“ Rake的主要优势是什么？” 你可能会问。 首先，它可以默认处理Ruby源文件。 此外，Ruby开发人员可以立即使用它，因为它不需要学习任何新的语言或框架。 该工具只有API是新的，其余的都是熟悉的，并且遵循已知的模式和原理。 最后，Rake使用Ruby的高级模式匹配将正则表达式形成规则过滤器。 有关Rake的更多信息， 请参阅SitePoint上的这篇文章 。

假 (FAKE)

There are dozens of other build tools that follow the approach of Rake, but one that I want to highlight is FAKE. The reason is simple: It uses a powerful functional language that has access to the whole .NET framework. To fully understand the idea behind FAKE, it’s important to know that FAKE was created at a time where Domain Specific Languages (DSLs) seemed to be the ultimate weapon.

还有许多其他遵循Rake方法的构建工具，但是我要强调的是FAKE 。 原因很简单：它使用功能强大的功能语言，可以访问整个.NET Framework 。 为了完全理解FAKE背后的思想，了解FAKE是在特定领域语言 (DSL)似乎是最终武器的时候创建的，这一点很重要。

The basic principles of FAKE are probably very similar to Jake. What differentiates FAKE from the competitors is the use of the F# pipe operator. This operator gives the whole build configuration a fluent touch. The integration with (.NET) unit-testing frameworks, adds testing as a crucial part of the (post-)build process.

FAKE的基本原理可能与Jake非常相似。 FAKE与竞争对手的不同之处在于使用了F＃管道运算符。 该操作员使整个构建配置更加流畅。 与(.NET)单元测试框架的集成将测试添加为(后期)构建过程的关键部分。

杰克 (Jake)

Having a build tool written in JavaScript for the Node.js environment, sounds like a good idea. Since Node.js runs on various platforms the build tool will run on these platforms as well. Additionally, we get the benefits of fast execution, concurrent callbacks, and a great debugging experience.

拥有一个用JavaScript编写的Node.js环境构建工具，听起来是个好主意。 由于Node.js在各种平台上运行，因此构建工具也将在这些平台上运行。 此外，我们还受益于快速执行，并发回调和出色的调试经验。

Jake, that I discussed in my first article on SitePoint, follows the same rule-dependency concept employed by Make but flavored with pattern matching as in Rake. Additionally, we have the packaging abilities, which may help us to create bundles for distribution, and parallel builds are supported.

我在关于SitePoint的第一篇文章中讨论的 Jake遵循了Make所使用的相同的规则依赖概念，但是具有与Rake一样的模式匹配。 此外，我们具有打包功能，这可以帮助我们创建分发包，并支持并行构建。

结论 (Conclusion)

These days we have a huge variety of possibilities for our application build process software. Even though Make is still the most used program for automating build processes in some contexts, other applications offer interesting features, which may simplify our desired tasks a lot.

如今，我们为应用程序构建过程软件提供了各种各样的可能性。 尽管在某些情况下Make仍然是使构建过程自动化的最常用的程序，但其他应用程序提供了有趣的功能，这些功能可以大大简化我们所需的任务。

Another important factor to consider is the familiarity with the used programming language. For instance, a team consisting of JavaScript developers should be quite comfortable with Jake. It’s definitely important that every team member is able to read, understand, and probably even modify the build process as needed.

要考虑的另一个重要因素是对所使用的编程语言的熟悉程度。 例如，一个由JavaScript开发人员组成的团队应该对Jake非常满意。 每个团队成员都必须能够阅读，理解甚至可能根据需要修改构建过程，这一点绝对重要。

It’s our job to decide what tool to consider, and this article should have convinced you that it’s worth looking at multiple candidates before deciding what tool to employ, as they all have something unique to offer.

决定要考虑的工具是我们的工作，并且本文应该说服您，在决定采用哪种工具之前，有必要考虑多个候选人，因为它们都有独特之处。

What’s your favorite build system? Do you have any other recommendations?

您最喜欢的构建系统是什么？ 您还有其他建议吗？

翻译自: https://www.sitepoint.com/comparison-build-systems/