Non-trivial compiled programs are generally not contained in a single source file. At the very least, they will incorporate code from libraries (archives of precompiled code containing commonly useful functions). Many programs are also broken up into multiple source files to avoid recompiling all of the code every time a change is made. A build system allows us to recompile only the source files that have changed, and then link all the compiled modules together. Compiling is the expensive part, linking is easy and quick.

There are many different build systems available for performing basic program builds, as well as higher level tools for generating build configurations.

Browse the web and you can find many heated debates about which build system is best, mostly based on arguments that will never apply to you, e.g. build system X will perform a parallel build on a 32-core machine 15% faster than build system Y. This might matter to a developer who runs enormous builds all day every day, but for the other 99.9% of us, it's irrelevant.

As with programming languages, build systems often get blamed for user errors. "You shouldn't use build system Z, because it allows you to shoot yourself in the foot". This is a nonsensical argument of course, because careless people will find a way to mess things up no matter what tools they use, while conscientious people will do good work with any tool. Be conscientious and your life will be simpler.

In this text, we will focus on make, the tried and true de facto standard build system for Unix. The make utility is discussed in Chapter 22, Building with Make. There are other systems with cool fancy features that some people get excited about, as well as a plethora of tools for generating makefiles, the project descriptions used by make for building.

However, make is easy to learn, available on every Unix system by default, and if you use it wisely, it will likely serve all of your needs very well.