Make or Break: 5 of the Best 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. For a bit more on Rake, check out this article on 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.
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.
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.
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.
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.
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.
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?
