Linux make command

On Unix-like operating systems, make is a utility for building and maintaining groups of programs (and other types of files) from source code.

This page covers the GNU/Linux version of make.

Description

The purpose of the make utility is to determine automatically which pieces of a large program need to be re-compiled, and issue the commands necessary to recompile them. This documentation describes the GNU implementation of make, which was written by Richard Stallman and Roland McGrath, and is currently maintained by Paul Smith. Many of the examples listed below show C programs, since they are most common, but you can use make with any programming language whose compiler can be run with a shell command. In fact, make is not limited to programs. You can use it to describe any task where some files must be updated automatically from others whenever the others change.

To prepare to use make, you must write a file called the makefile that describes the relationships among files in your program, and the states the commands for updating each file. In a program, typically the executable file is updated from object files, which are in turn made by compiling source files.

Once a suitable makefile exists, each time you change some source files, this simple shell command:

make

suffices to perform all necessary recompilations. The make program uses the makefile data base and the last-modification times of the files to decide which of the files need to be updated. For each of those files, it issues the commands recorded in the database.

make executes commands in the makefile to update one or more target names, where name is typically a program. If no -f option is present, make will look for the makefiles GNUmakefile, makefile, and Makefile, in that order.

Normally you should call your makefile either makefile or Makefile. (The officially recommended name is Makefile because it appears prominently near the beginning of a directory listing, right near other important files such as README.) The first name checked, GNUmakefile, is not recommended for most makefiles. You should use this name if you have a makefile that is specific to GNU make, and will not be understood by other versions of make. If makefile is a dash ("-"), the standard input is read.

make updates a target if it depends on prerequisite files that have been modified since the target was last modified, or if the target does not exist.

Syntax

make [ -f makefile ] [ options ] ... [ targets ] ...

Options

Typical Use

make is typically used to build executable programs and libraries from source code. Generally, make is applicable to any process that involves executing arbitrary commands to transform a source file to a target result. For example, make could be used to detect a change made to an image file (the source) and the transformation actions might be to convert the file to some specific format, copy the result into a content management system, and then send e-mail to a predefined set of users that the above actions were performed.

make is invoked with a list of target file names to build as command-line arguments:

make [TARGET ...]

Without arguments, make builds the first target that appears in its makefile, which is traditionally a target named all.

make decides whether a target needs to be regenerated by comparing file modification times. This solves the problem of avoiding the building of files that are already up to date, but it fails when a file changes but its modification time stays in the past. Such changes could be caused by restoring an older version of a source file, or when a network filesystem is a source of files and its clock or timezone is not synchronized with the machine running make. The user must handle this situation by forcing a complete build. Conversely, if a source file's modification time is in the future, it may trigger unnecessary rebuilding.

Makefiles

make searches the current directory for the makefile to use. GNU make searches files for a file named one of GNUmakefile, makefile, and then Makefile, and runs the specified target(s) from that file.

The makefile language is similar to declarative programming, in which necessary end conditions are described but the order in which actions are to be taken is not important. This may be confusing to programmers used to imperative programming, which explicitly describes how the end result will be reached.

One problem in build automation is the tailoring of a build process to a given platform. For instance, the compiler used on one platform might not accept the same options as the one used on another. This is not well handled by make on its own. This problem is typically handled by generating separate platform-specific build instructions, which in turn may be processed by make. Common tools for this process are autoconf and cmake.

Rules

A makefile essentially consists of rules. Each rule begins with a dependency line which defines a target followed by a colon (":") and optionally an enumeration of components (files or other targets) on which the target depends. The dependency line is arranged so that the target (left hand of the colon) depends on components (right hand of the colon). It is common to refer to components as prerequisites of the target.

target [target ...]: [component ...] [<TAB> command 1] . . . 
       [<TAB> command n]

Here, <TAB> is the tab character. Usually each rule has a single unique target, rather than multiple targets.

For example, a C .o object file is created from .c files, so .c files come first (i.e., specific object file target depends on a C source file and header files). Because make itself does not understand, recognize or distinguish different kinds of files, this opens up the possibility for human error. A forgotten or an extra dependency may not be immediately obvious and may result in subtle bugs in the generated software. It is possible to write makefiles which generate these dependencies by calling third-party tools, and some makefile generators, such as the GNU automake toolchain, can do so automatically.

After each dependency line, a series of command lines may follow which define how to transform the components (usually source files) into the target (usually the "output"). If any of the components have been modified, the command lines are run.

With GNU make, the first command may appear on the same line after the prerequisites, separated by a semicolon:

targets : prerequisites ; command

for example:

hello: ; @echo "hello"

Each command line must begin with a tab character to be recognized as a command. The tab is a whitespace character, but the space character does not have the same special meaning. This is problematic, since there may be no visual difference between a tab and a series of space characters. This aspect of the syntax of makefiles is often subject to criticism, and is important to take note.

However, GNU make (since version 3.82) allows the user to choose any symbol (one character) as the recipe prefix using the .RECIPEPREFIX special variable, for example:

.RECIPEPREFIX := : all: :@echo "recipe prefix symbol is set to '$(.RECIPEPREFIX)'"

Each command is executed by a separate shell or command-line interpreter instance. Since operating systems use different command-line interpreters this can lead to unportable makefiles. For instance, GNU make by default executes commands with /bin/sh, which is the shell where Unix commands like cp are normally used.

A rule may have no command lines defined. The dependency line can consist solely of components that refer to targets, for example:

realclean: clean distclean

The command lines of a rule are usually arranged so that they generate the target. An example: if "file.html" is newer, it is converted to text. The contents of the makefile:

file.txt: file.html lynx -dump file.html > file.txt

The above rule would be triggered when make updates "file.txt".

In the following invocation, make would typically use this rule to update the "file.txt" target if "file.html" were newer:

make file.txt

Command lines can have one or more of the following three prefixes:

• a hyphen-minus (-), specifying that errors are ignored
• an at sign (@), specifying that the command is not printed to standard output before it is executed
• a plus sign (+), the command is executed even if make is invoked in a "do not execute" mode

Ignoring errors and silencing all echo output can also be obtained via the special targets ".IGNORE" and ".SILENT", respectively.

Macros

A makefile can contain definitions of macros. Macros are usually referred to as variables when they hold simple string definitions, like "CC=clang", which would specify clang as the C compiler. Macros in makefiles may be overridden in the command-line arguments passed to the make utility. environment variables are also available as macros.

Macros allow users to specify the programs invoked and other custom behavior during the build process. For example, as just shown, the macro "CC" is frequently used in makefiles to refer to the location of a C compiler.

New macros are traditionally defined using capital letters:

MACRO = definition

A macro is used by expanding it. Traditionally this is done by enclosing its name inside $(). An equivalent form uses curly braces rather than parenthesis, i.e., ${}, which is the style used in BSD operating systems.

NEW_MACRO = $(MACRO)-$(MACRO2)

Macros can be composed of shell commands using the command substitution operator, denoted by backticks ("` `").

YYYYMMDD = ` date `

The content of the definition is stored "as is". Lazy evaluation is used, meaning that macros are normally expanded only when their expansions are actually required, such as when used in the command lines of a rule. For example:

PACKAGE   = package
VERSION   = ` date +"%Y.%m%d" `
ARCHIVE   = $(PACKAGE)-$(VERSION)
dist:
     #  Notice that only now macros are expanded for shell to interpret:
     #      tar -cf package-`date +"%Y%m%d"`.tar
tar -zcf $(ARCHIVE).tar .

The generic syntax for overriding macros on the command line is:

make MACRO="value" [MACRO="value" ...] TARGET [TARGET ...]

Makefiles can access any of a number of predefined internal macros, with "?" and "@" being the most common.

target: component1 component2
     echo $? contains those components, which need attention 
             (i.e., they ARE YOUNGER than current TARGET).
     echo $@ evaluates to current TARGET name from among those left of the colon.

Suffix Rules

Suffix rules have "targets" with names in the form .FROM.TO and are used to launch actions based on file extension. In the command lines of suffix rules, POSIX specifies that the internal macro "$<" refers to the first prerequisite and "$@" refers to the target. In this example, which converts any HTML file into text, the shell redirection token ">" is part of the command line whereas "$<" is a macro referring to the HTML file:

.SUFFIXES: .txt .html
# From .html to .txt
.html.txt:
        lynx -dump $<   >   $@

When called from the command line, the above example expands the command:

make -n file.txt

into:

lynx -dump file.html > file.txt

Other Elements

• Single-line comments are started with the hash symbol ("#").
• Some directives in makefiles can include other makefiles.
• Line continuation is indicated with a backslash ("\") character at the end of a line, as in the following:

   target: component \
              component
      <TAB>command ; \
      <TAB>command | \
      <TAB>piped-command

Exit Status

GNU make exits with a status of:

• 0 if all makefiles were successfully parsed and no targets that were built failed;
• 1 if the -q flag was used and make determines that a target needs to be rebuilt; and
• 2 if any errors were encountered.

Examples

Makefiles are traditionally used for compiling code (*.c, *.cc, *.C, etc.), but they can also be used for providing commands to automate common tasks.

Here's an example of three ways to run make given a certain makefile. The make commands are listed first, and then the makefile:

make

Without any argument, make will run the first target;

make help

When given the help argument, make will show available targets;

make dist

When given the argument dist, make will create a release archive from the current directory.

Here is the makefile for the above make commands:

PACKAGE      = package
VERSION      = ` date "+%Y.%m%d%" `
RELEASE_DIR  = ..
RELEASE_FILE = $(PACKAGE)-$(VERSION)
# Notice that the variable LOGNAME comes from the environment in
# POSIX shells.
#
# target: all - Default target. Does nothing.
all:
        echo "Hello $(LOGNAME), nothing to do by default"
        # sometimes: echo "Hello ${LOGNAME}, nothing to do by default"
        echo "Try 'make help'"
# target: help - Display callable targets.
help:
        egrep "^# target:" [Mm]akefile
# target: list - List source files
list:
        # Won't work. Each command is in separate shell
        cd src
        ls
        # Correct, continuation of the same shell
        cd src; \
        ls
# target: dist - Make a release.
dist:
        tar -cf  $(RELEASE_DIR)/$(RELEASE_FILE) && \
        gzip -9  $(RELEASE_DIR)/$(RELEASE_FILE).tar

Next, here is a very simple makefile that by default (the "all" rule, which is listed first) compiles a source file called "helloworld.c" using the system's C compiler, and also provides a "clean" target to remove the generated files if the user wants to start over. The $@ and $< are two internal macros (also known as automatic variables) that stand for the target name and implicit source, respectively. In the example below, $^ expands to a space-delimited list of the prerequisites.

Here's the makefile:

CFLAGS ?= -g
all: helloworld
helloworld: helloworld.o
        # Commands start with TAB not spaces
        $(CC) $(LDFLAGS) -o $@ $^
helloworld.o: helloworld.c
        $(CC) $(CFLAGS) -c -o $@ $<
clean: FRC
        rm -f helloworld helloworld.o
# This pseudo target causes all targets that depend on FRC
# to be remade even in case a file with the name of the target exists.
# This works with any make implementation under the assumption that
# there is no file FRC in the current directory.
FRC:

Many systems come with predefined make rules and macros to specify common tasks such as compilation based on file suffix. This allows user to omit the actual (often unportable) instructions of how to generate the target from the source(s). On such a system the above makefile could be modified as follows:

all: helloworld
helloworld: helloworld.o
    $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^
clean: FRC
    rm -f helloworld helloworld.o
# This is an explicit suffix rule. It may be omitted on systems
# that handle simple rules like this automatically.
.c.o:
    $(CC) $(CFLAGS) -c $<
FRC:
.SUFFIXES: .c

Using this makefile, the fact that "helloworld.o" depends on "helloworld.c" is now automatically handled by make. In this simple example this hardly matters, but the real power of suffix rules becomes evident when the number of source files in a software project starts to grow. One only has to write a rule for the linking step and declare the object files as prerequisites. make will then implicitly determine how to make all the object files and look for changes in all the source files.

Simple suffix rules work well as long as the source files do not depend on each other and on other files such as header files. Another route to simplify the build process is to use pattern matching rules that can be combined with compiler-assisted dependency generation.

The next example requires the gcc compiler. It is a generic makefile that compiles all C files in a folder to the corresponding object files and then links them to the final executable. Before compilation takes place, dependencies are gathered in makefile-friendly format into a hidden file ".depend" that is then included to the makefile.

# Generic GNUMakefile
# Just a snippet to stop executing under other make(1) commands
# that won't understand these lines
ifneq (,)
This makefile requires GNU Make.
endif
PROGRAM = foo
C_FILES := $(wildcard *.c)
OBJS := $(patsubst %.c, %.o, $(C_FILES))
CC = cc
CFLAGS = -Wall -pedantic
LDFLAGS =
all: $(PROGRAM)
$(PROGRAM): .depend $(OBJS)
    $(CC) $(CFLAGS) $(OBJS) $(LDFLAGS) -o $(PROGRAM)
depend: .depend
.depend: cmd = gcc -MM -MF depend $(var); cat depend >> .depend;
.depend:
    @echo "Generating dependencies..."
    @$(foreach var, $(C_FILES), $(cmd))
    @rm -f depend
-include .depend
# These are the pattern matching rules. In addition to the automatic
# variables used here, the variable $* that matches whatever % stands for
# can be useful in special cases.
%.o: %.c
    $(CC) $(CFLAGS) -c $< -o $@
%: %.c
    $(CC) $(CFLAGS) -o $@ $<
clean:
    rm -f .depend *.o
.PHONY: clean depend

Related commands

cd — Change the working directory.
sh — The Bourne shell command interpreter.