Make or Break: 5 of the Best Build Systems

Originally published at: http://www.sitepoint.com/comparison-build-systems/

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

“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.

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.

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.

Continue reading this article on SitePoint

Scons is another option, written in Python. Technically, Gulp and Grunt fit the mold too. These may be classified as ‘task runners’ but that is effectively what a build system is. Also, Gyp used by Chromium and a number of other projects like Node. When you write a native plugin for Node, you are required to use Gyp as you might expect.

I do not have a favourite but I generally use CMake with C/C++, and simple Makefiles for various things (including many non-compiling things). CMake has the easiest language to write plugins for detecting libs and such. Prior to things like Composer, Makefiles were the way to go in a PHP project to get dependencies.

You really can go insane with Make and the strange language therein (it is especially easy when you target only one OS), but I would not recommend it. I would rather use Autohell than that, and even that is not that great. Apple has tended to use Make (and not Automake) for their open source projects (like CoreFoundation), for which (no surprises here) they generally have no intention of being cross-platform.

Yes I also like Gulp - and it is my primary web build tool. However, I cannot use it for some of my other tasks including building TeX documents, compiling C/C++, deployment and packaging issues and much more.

At the moment I mainly use Jake, but in the past I’ve also used Make and Automake. The latter was a real time saver. Great comment about CMake - I do agree.

It’s great that you mention Scons. I actually did not know that - but it seems interesting. I’ve used Gyp naturally for building native Node.js modules, but that was only due to the lack of choices.

Thanks for your interesting comment!

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.