GNU Build System - Introduction
As programmers, we work very hard to maximize the number of people that would want to use our software. And we do this by providing the best product possible. When programmers talk about "A good product", most of the time they are thinking in terms of performance, minimum bugs, stability… But there is an aspect that plays a major role in projects' quality that we don't discuss very often. Which is the way you set for your project to go from source code to the executable binaries. We call the tools you set up for this process a build system. If you are using a compiled programming language, the build system you make for your project can drastically affect its admissibility.
In this article, I want to discuss with you guys some considerations one should take into account while setting up a build system. I will walk my way from there by presenting you with one of the most popular approaches people use to address this issue. This approach is what's known as the GNU Build System. I'll try to provide you with a broad idea on what GNU Build System is, how it came into existence in the first place and why you might consider using it in your future projects. The aim is to get you motivated enough so that you will want to learn more about it.
"It is a truth universally acknowledged, that as a developer in possession of a new package, you must be in want of a build system." – Quote from GNU Build System's official documentation.
What is a build system?
If you ever worked on a C or C++ project, then you have probably used a build system. Maybe without knowing it. Probably because your IDE automatically took care of that for you. Or maybe you built your own, using make (GNU make), CMake or just a plain shell script. What we call a build system is the automated process you have set up to easily build your project.
Why use GNU Build System?
It is perfectly fine to forge your own build system. Or use the one generated by your IDE and call it a day. But imagine that you are working on a program or a library that is so good that any living person with a computer would want to make use out of it at some point. In this case you might want to ask yourself a few questions regarding the build system you are using.
Platform dependency
Your hand made build system works fine in your local machine. But will it work on a different platform? You definitely can work that out! But how much time would you spend adapting and testing against every OS, compiler and hardware possible?…
Dependency management
At some point you might need an external library for your project. Are you going to ship your project with all the needed dependencies? And if you do. Will you ship the binaries or the source code? If you are going with binary dependencies. How many binaries will be there to support all the targeted platforms. If you choose to ship the source code for your dependencies, you might think about people who already have the needed library installed on their system. Are you going to make them compile and install another copy of the same library?…
User-friendliness
Since you made your own build system, you are the only one who understands how it works. People will not be able to use it, unless you write a documentation for it. And since it is capable of adapting to multiple platforms and supports shared dependencies. The documentation should explain how that works in order to point to the right dependencies and compile for the right platform. And even if you manage to write a documentation that explains all these details. How much time people are willing spend reading a documentation for something they will use probably once a year at most?
These are just some considerations I was able to think about. Building a good build system is a daunting task. And even if you manage to build a decent one, there is a good chance that people will have a hard time using it since it is not popular. That's why it is better to pick a good build system that people are already familiar with. This will help to get a lot more people to be able to easily use your software.
Now if you agree with that, let me present to you one of the most popular build systems out there. I figured that the best way to do that is by giving you the historical context that gave birth to it first.
GNU project
GNU project was founded to offer free software to everyone who needs it. And this by allowing everyone who is able to do useful things and are willing to do it for free to contribute to the project. It is the same project behind Linux operating system. Or GNU Linux as it should normally be called. Because the aim is to make a lot of developers freely contribute to the project, the GNU community also defines all sorts of standards and conventions that developers should adhere to. These conventions gained so much popularity that unrelated projects started using them as well. In the same philosophy GNU Build System was born.
GNU Build System
GNU Build System is the convention that the GNU project defined as the standard way a build system should be. Basically, it says that a project should be shipped with at least two files. A configure script and a Makefile. Both of which should adhere to a minimalist command line interface that is also defined in the convention. If you are not trying to use more advanced features, the building process should be as simple as running ./configure && make.
Besides that, a set of tools were made available to developers to generate such a build system. Those tools are called Autotools and are composed mainly of two programs; Autoconf and Automake. Automake generates the configure script and Automake generates the Makefile(s).
The following scheme is an overly simplified overview of how Autotools work. Remember, this article is just an introduction. I don't want to get into technical stuff yet.
The scheme shows that with Autotools – in most cases – all you have to do is provide two files. configure.ac and Makefile.am in which, using a special syntax, you specify thing like what you need for the project to be built (a C compiler, the libraries your project depends on…) and where your source code files are… Autoconf and Automake take care of the rest for you.
In the same way as the other conventions, GNU Build System became so popular that projects outside the GNU community started using it. And because of its popularity Autotools have gotten better at supporting a huge amount of platforms and gained a ton of features.
With all that said, I should warn you though. Autotools have a bit of a learning curve to them. The official documentation is very complete and well-structured. It even has some very good examples. And still, I found some difficulties while I was trying to learn them.
This is why I decided to use this blog to document what I learned in a format that seems – to me at least – easier than the official documentation. The way I decided to do it is by writing small and easy to digest articles. I try to keep the articles short and talk only about one aspect of the subject.
I hope that other readers would also find this series of articles useful. And if not, I would love to hear any suggestions that may make it better.
If I got you interested enough in the subject, I invite you take a look at the Getting Started article.
Over and out,
AA