man make: a Primer on the Make Utility


In a compiled language, the makefile is arguably the most important part of any programming project. To compile your project, you first have to compile each source file into an object file, which in turn needs to be linked with system libraries into the final executable file. Each command can have a considerable number of arguments added in. That's a lot of typing and a lot of potential for mistakes. The more source files you have, the more complex the compilation process becomes, unless you use makefiles. Most Linux users have at least a cursory knowledge of make and makefiles (because that's how we build software packages for our systems), but not much more than that. Most developers probably don't have too much in-depth experience with makefiles, because most Integrated Development Environments (IDEs) have the capability of managing makefiles for them. Although this is convenient most of the time, knowing more about how make works and what goes into makefiles can help you troubleshoot compilation errors down the road.

According to make's man page, "The purpose of the make utility is to determine automatically which pieces of a large program need to be recompiled, and issue the commands to recompile them." Essentially, make is used to determine efficiently (and without user error) which portions of the source code have been updated since the last compilation and recompile them. It can be used for more than just compiling programs. Because it isn't limited to any particular language, you can use it for anything you can come up with that relates to the modified date of a group of files.

Running make is a straightforward process. The more convoluted portion of using make is constructing the makefile. The makefile is a file that consists of a series of rules that define the dependencies of your project. These rules govern the behavior of make during execution.


Command lines must be indented with tab characters; spaces cause funky errors. This has been a design flaw in make for decades. Empty lines must still have a tab character or else make will throw a fit.

The Basics:

  • Comments start with a pound sign (#).

  • Continuation of a line is denoted by a back slash (\).

  • Lines containing equal signs (=) are variable definitions.

  • Each command line typically is executed in a separate Bourne shell—that is, sh1.

  • To execute more than one command line in the same shell, type them on the same line, separated by semicolons. Use a \ to continue the line if necessary.

Listing 1. Example Makefile

CFLAGS=-c -Wall
SOURCES=main.cpp hello.cpp factorial.cpp


        $(CC) $(LDFLAGS) $(OBJECTS) -o $@

        $(CC) $(CFLAGS) $< -o $@

Rules and Targets

Each rule in the makefile is an independent series of commands that are executed in order to build a target. Make does not necessarily run each rule in order. Make will run through the rules recursively, building each target in turn, based on modification. Rules are formatted like this:

target: dependency list ...



The target is typically the name of a file, but it can be a phony target (discussed later in this article). The dependency list is a space-separated list of files that designate whether the target needs to be rebuilt. The commands can be any shell command, so long as the target is up to date at the end of them. It is imperative that you indent the commands with a tab character and not spaces. This is a design flaw in make that has yet to be fixed, and it will cause some strange and obscure errors should you use spaces instead of tabs in your makefile.

When make encounters a rule, it first checks the files listed in the dependency list to ensure that they haven't changed. If one of them has, make looks through the makefile for the rule containing that file as the target. This recursion continues until a rule is found where all the dependencies are unchanged or rebuilt (or have no further dependencies), and then make executes the listed commands for that rule before returning to the previous rule, and so on, until the root rule has been satisfied and its commands run.

You may use pattern-matching characters to describe dependencies in the dependency list or in commands, but they may not be used in the target.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Thanks a lot for the intro

Anonymous's picture

Just a question:
For the last line in page 2:

will produce the output abcdef xyzabc def.

Why not:

will produce the output abcdef defabc def?

Make is an old system that

Anonymous's picture

Make is an old system that should only be used by complex build system maintainers that need the extra power and automatic tools (and by complex build systems I mean the Linux Kernel -- which uses some autobuild system itself (KBuild), that is built on top of a specialized make system).

To compile programs you should instead use autotools - at least automake and for ease of use I highly recommend autoconf.

Great intro to the topic - 2

Anonymous's picture

Great intro to the topic - 2 things that I noticed as I was following the tutorial:

In Listing 1:


can be replaced by


since, according to your description about suffix rules, $(EXECUTABLE) depends on .o files, which will be rebuilt automatically on changes to .c files

Also, the .SUFFIXES fake target is missing from the listing:

.SUFFIXES: .o .c

One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix