Make (software)

From Wikipedia, the free encyclopedia
  (Redirected from GNU Make)
Jump to: navigation, search
Original author(s) Stuart Feldman
Initial release 1977
Type build automation tool




There are now a number of dependency-tracking build utilities, but Make is one of the most widespread, primarily due to its inclusion in Unix, starting with the PWB/UNIX 1.0, which featured a variety of tools targeting software development tasks. It was originally created by Stuart Feldman in April 1976 at Bell Labs.[1] In 2003 Dr. Feldman received the ACM Software System Award for the authoring of this widespread tool.[2]

Before Make's introduction, the Unix build system most commonly consisted of operating system dependent "make" and "install" shell scripts accompanying their program's source. Being able to combine the commands for the different targets into a single file and being able to abstract out dependency tracking and archive handling was an important step in the direction of modern build environments.

Modern versions[edit]

Make has gone through a number of rewrites, including a number of from-scratch variants which used the same file format and basic algorithmic principles and also provided a number of their own non-standard enhancements. Some of them are:

  • SunPro make is a rewrite[dubious ] of the UNIX make program that appeared in 1986 with SunOS-3.2. With SunOS-3.2, SunPro make was delivered as optional program; with SunOS-4.0, SunPro make was made the default make program.[3] In December 2006,[better source needed] it was made OpenSource as it is needed to compile OpenSolaris.[4][dubious ]
  • BSD Make (pmake or bmake[citation needed]), which is derived from Adam de Boor's work on a version of Make capable of building targets in parallel, and survives with varying degrees of modification in FreeBSD, NetBSD and OpenBSD.[citation needed] Distinctively, it has conditionals and iterative loops which are applied at the parsing stage and may be used to conditionally and programmatically construct the makefile, including generation of targets at runtime.[citation needed]
  • GNU Make is the standard implementation of make for Linux and OS X.[5] It provides several extensions over the original make, such as conditionals. It also provides many built-in functions which can be used to eliminate the need for shell-scripting in the makefile rules as well as to manipulate the variables set and used in the makefile.[6] For example, the documentation for the foreach function gives an example of setting a variable to the list of all files in a given directory.[7] GNU Make has been required for building gcc since version 3.4.[8] It is required for building the Linux kernel.[9][10]
  • Glenn Fowler's nmake[11] is unrelated to the Microsoft program of the same name. Its input is similar to make, but not compatible. This program provides shortcuts and built-in features, which according to its developers reduces the size of makefiles by a factor of 10.
  • Microsoft nmake, a command-line tool which normally is part of Visual Studio.[12] It supports preprocessor directives such as includes and conditional expressions which use variables set on the command-line or within the makefiles.[13][14] Inference rules differ from make; for example they can include search paths.[15] The make tool supplied with Embarcadero products has a command-line option that "Causes MAKE to mimic Microsoft's NMAKE."[16]

POSIX includes standardization of the basic features and operation of the Make utility, and is implemented with varying degrees of completeness in Unix-based versions of Make. In general, simple makefiles may be used between various versions of Make with reasonable success. GNU Make, BSD Make and Makepp can be configured to look first for files named "GNUmakefile",[17] "BSDmakefile"[18] and "Makeppfile"[19] respectively, which allows one to put makefiles which use implementation-defined behavior in separate locations.


Make is typically used to build executable programs and libraries from source code. Generally though, 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 ...]


Make decides whether a target needs to be regenerated by comparing file modification times. This solves the problem of avoiding the building of files which 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 triggers unnecessary rebuilding, which may inconvenience users.


Make searches the current directory for the makefile to use, e.g. GNU make searches files in order for a file named one of GNUmakefile, makefile, Makefile and then runs the specified (or default) target(s) from (only) that file.

The makefile language is similar to declarative programming.[20][21][22][23] This class of language, in which necessary end conditions are described but the order in which actions are to be taken is not important, is sometimes confusing to programmers used to imperative programming.

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. This problem is typically handled by generating platform specific build instructions, which in turn are processed by Make. Common tools for this process are Autoconf and CMake.


A makefile consists of rules. Each rule begins with a textual 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]

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 a 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 Automake toolchain provided by the GNU Project, 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 the 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"

Make can decide where to start through topological sorting.

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.

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

:@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, where Unix commands like cp are normally used. In contrast to that, Microsoft's nmake executes commands with cmd.exe where batch commands like copy are available but not necessarily cp.

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 echo can alternatively be obtained via the special targets ".IGNORE" and ".SILENT".[24]

Microsoft's NMAKE has predefined rules that can be omitted from these makefiles, e.g. "c.obj $(CC)$(CFLAGS)".


A makefile can contain definitions of macros. Macros are usually referred to as variables when they hold simple string definitions, like "CC=clang". 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, the macro "CC" is frequently used in makefiles to refer to the location of a C compiler, and the user may wish to specify a particular compiler to use.

New macros (or simple "variables") 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 the BSDs.


Macros can be composed of shell commands by 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. An extended example:

    PACKAGE   = package
    VERSION   = ` date +"%Y.%m%d" `
            #  Notice that only now macros are expanded for shell to interpret:
            #      tar -cf package-`date +"%Y%m%d"`.tar
            tar -cf $(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
            # 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.
            echo $@

Suffix rules[edit]

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[25] 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
            lynx -dump $<   >   $@

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

    $ make -n file.txt
    lynx -dump file.html > file.txt

Pattern rules[edit]

Suffix rules cannot have any prerequisites of their own.[26] If they have any, they are treated as normal files with unusual names, not as suffix rules. GNU make supports suffix rules for compatibility with old makefiles but otherwise encourages usage of pattern rules.[27]

A pattern rule looks like an ordinary rule, except that its target contains exactly one character '%'. The target is considered a pattern for matching file names: the '%' can match any substring of zero or more characters[28][dubious ], while other characters match only themselves. The prerequisites likewise use '%' to show how their names relate to the target name.

The above example of a suffix rule would look like the following pattern rule,

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

Other elements[edit]

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.

   target: component \
   Tab command ;          \
   Tab command |          \
   Tab piped-command

Example makefiles[edit]

Makefiles are traditionally used for compiling code (*.c, *.cc, *.C, etc.), but they can also be used for providing commands to automate common tasks. One such makefile is called from the command line:

    make                        # Without argument runs first TARGET
    make help                   # Show available TARGETS
    make dist                   # Make a release archive from current dir

The makefile:

    PACKAGE	 = package
    VERSION	 = ` date "+%Y.%m%d%" `
    RELEASE_DIR  = ..
    # Notice that the variable LOGNAME comes from the environment in
    # POSIX shells.
    # target: all - Default target. Does nothing.
	    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.
	    egrep "^# target:" [Mm]akefile
    # target: list - List source files
	    # Won't work. Each command is in separate shell
	    cd src
	    # Correct, continuation of the same shell
	    cd src; \
    # target: dist - Make a release.
	    tar -cf  $(RELEASE_DIR)/$(RELEASE_FILE) && \
	    gzip -9  $(RELEASE_DIR)/$(RELEASE_FILE).tar

Below is a very simple makefile that by default (the "all" rule 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 desires to start over. The $@ and $< are two of the so-called internal macros (also known as automatic variables) and stand for the target name and "implicit" source, respectively. In the example below, $^ expands to a space delimited list of the prerequisites. There are a number of other internal macros.[25][29]

    CFLAGS ?= -g
    all: helloworld
    helloworld: helloworld.o
	    # Commands start with TAB not spaces
    helloworld.o: helloworld.c
    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.

Many systems come with predefined Make rules and macros to specify common tasks such as compilation based on file suffix. This lets users 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
    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.
	$(CC) $(CFLAGS) -c $<
    .SUFFIXES: .c

That "helloworld.o" depends on "helloworld.c" is now automatically handled by Make. In such a simple example as the one illustrated here 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 so-called pattern matching rules that can be combined with compiler-assisted dependency generation. As a final example requiring the gcc compiler and GNU Make, here 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. Portable programs ought to avoid constructs used below.

    # 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.
    PROGRAM = foo
    C_FILES := $(wildcard *.c)
    OBJS := $(patsubst %.c, %.o, $(C_FILES))
    CC = cc
    CFLAGS = -Wall -pedantic
    all: $(PROGRAM)
    $(PROGRAM): .depend $(OBJS)
    depend: .depend
    .depend: cmd = gcc -MM -MF depend $(var); cat 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
    %: %.c
	rm -f .depend *.o
    .PHONY: clean depend

See also[edit]


  1. ^ ident.c, make source code from version 7 Unix
  2. ^ Matthew Doar (2005). Practical Development Environments. O'Reilly Media. p. 94. ISBN 978-0-596-00796-6. 
  3. ^ Usenet discussion about the early SunPro make
  4. ^ download location for devpro-make-src-20061219.tar.bz2
  5. ^ Arnold Robbins (2005), Unix in a Nutshell, Fourth Edition, O'Reilly 
  6. ^ "8. Functions for Transforming Text", GNU make (Free Software Foundation), 2013 
  7. ^ "8.5 The foreach Function", GNU make (Free Software Foundation), 2013 
  8. ^ "GCC 3.4 Release Series Changes, New Features, and Fixes". Free Software Foundation. 2006. 
  9. ^ Javier Martinez Canillas (December 26, 2012). "Kbuild: the Linux Kernel Build System". Linux Journal. 
  10. ^ Greg Kroah-Hartman (2006), Linux Kernel in a Nutshell, O'Reilly 
  11. ^ Glenn Fowler (January 4, 2012). "nmake Overview". Information and Software Systems Research, AT&T Labs Research. 
  12. ^ "NMAKE Reference Visual Studio 2013". Microsoft. 2014. 
  13. ^ "Makefile Preprocessing Directives". 2014. 
  14. ^ "Makefile Preprocessing Operators". Microsoft. 2014. 
  15. ^ "Search Paths in Rules". Microsoft. 2014. 
  16. ^ "MAKE". CodeGear(TM). 2008. 
  17. ^ "GNU `make'". Free Software Foundation. 
  18. ^ "Manual Pages: make". OpenBSD 4.8. 
  19. ^ "Makepp". 
  20. ^ an overview on dsls, 2007/02/27, phoenix wiki
  21. ^[dead link]
  22. ^ Re: Choreography and REST, from Christopher B Ferris on 2002-08-09
  23. ^ Target Junior Makefiles, Andrew W. Fitzgibbon and William A. Hoffman
  24. ^ make, The Open Group Base Specifications Issue 6
  25. ^ a b A listing of some Make internal macros at
  26. ^ "GNU make manual: suffix rules". Free Software Foundation. 
  27. ^ "GNU make manual: pattern rules". Free Software Foundation. 
  28. ^ See section Pattern Matching Rules in the SunPro man page
  29. ^ Automatic Variables GNU `make'

External links[edit]