Make (software)

Original author(s) Stuart Feldman
Initial release 1977
Type build automation tool

In software development, Make is a utility that automatically builds executable programs and libraries from source code by reading files called makefiles which specify how to derive the target program. Make can decide where to start through topological sorting. Though integrated development environments and language-specific compiler features can also be used to manage the build process in modern systems, Make remains widely used, especially in Unix.



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 1977 at Bell Labs. In 2003 Dr. Feldman received the ACM Software System Award for the authoring of this widespread tool.[1]

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.[citation needed] 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

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:

  • BSD Make, 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. Most notably, 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.
  • GNU Make is frequently used in conjunction with the GNU build system. Its departures from traditional Make are most noticeable in pattern-matching in dependency graphs and build targets, as well as a number of functions which may be invoked allowing functionality like listing the files in the current directory. It is also included in Apple’s Xcode development suite for the Mac OS.
  • Microsoft nmake, commonly available on Windows. It is fairly basic in that it offers only a subset of the features of the two versions of Make mentioned above. Microsoft's nmake is not to be confused with nmake from AT&T and Bell Labs for Unix.

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 and BSD Make can be configured to look first for files named "GNUmakefile" and "BSDmakefile" respectively,[2][3] 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, any process that involves transforming a source file to a target result (by executing arbitrary commands) is applicable to Make. 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 [TARGET ...]

Without arguments, Make builds the first target that appears in its makefile, which is traditionally a symbolic "phony" 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 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 file to run from current directory. E.g. the GNU Make searches files in order GNUmakefile, makefile, Makefile.

The makefile language is similar to declarative programming.[4][5][6][7] 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 a set of files 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).

An example is a specific object file target which depends on a C source file and header files. Because Make itself does not understand or differentiate 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 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 commands are run.

Each line must begin with a tab character to be recognised 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. When using makefile generators or text editors with explicit makefile support, this issue is likely less important.

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 will be used.

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

Usually each rule has a single unique target, rather than multiple targets.

A rule may have no command lines defined. The dependency line can consist solely of components that call other targets like:

    realclean: clean distclean

The commands 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 necessary.

    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".[8]


A makefile can contain definitions of macros. Macros are usually referred to as variables when they hold simple string definitions, like "CC=gcc". 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 $(). Very rarely, though possible, inside ${}.


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 -zcf $(ARCHIVE).tar .

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

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

Makefiles can access predefined internal macros.

    target: component1 component2
            echo $? contains those components, that need attention, THAT ARE YOUNGER than current TARGET
            echo $@ evaluates to current TARGET name to the left

Suffix rules

Suffix rules are in the form FROM.TO and they can be used to launch actions based on file extension. In the case of suffix rules, internal macro $< refers the component and $@ refers to the TARGET. An example to convert any HTML file into text; notice the shell redirection token > in the middle:

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

When called from command line, the above example expands.

    $ make -n file.txt
      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.

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

Example makefiles

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"
            # very rarely: 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 would compile a source called "helloworld.c" using gcc, a C compiler, and specifies a "clean" target to remove the generated files, for example to start over. The .PHONY tag is a technicality that tells Make that a particular target name does not produce an actual file. 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. There are a number of other internal macros.[9][10]

    CC     = gcc
    CFLAGS = -g
    all: helloworld
    helloworld: helloworld.o
            # Commands start with TAB not spaces
            $(CC) $(LDFLAGS) -o $@ $^
    helloworld.o: helloworld.c
            $(CC) $(CFLAGS) -c -o $@ $<
            rm -f helloworld helloworld.o
    # This is GNU makefile extension to notify that roughly means: 'clean' does
    # not depend on any files in order to call it.
    .PHONY: clean

Many systems come with a version of Make configured to handle common tasks like compiling based on file suffixes, which allows one to leave out the actual instructions from the target and source specification. Assuming such a system, the above example could be shortened as follows:

    all: helloworld
    helloworld: helloworld.o
    helloworld.o: helloworld.c
            rm -f helloworld helloworld.o
    .PHONY: clean

Make allows for custom suffix rules to be defined, allowing for powerful abstraction of rules by separating the file build relationships from the construction rules.

An example makefile for GNU Make:

    # Just a snippet to stop executing under other make(1) commands
    # that won't understand these lines
    ifneq (,)
    This makefile requires GNU Make.
    include makefile/
    include makefile/
    # Define macros. In this case "simple variables that don't expand"
    # Can be overridden on command line
    CC     = gcc
    CFLAGS = -Wall -pedantic -g
        echo "Nothing to do, yet"

See also


  1. ^ Matthew Doar (2005). Practical Development Environments. O'Reilly Media. pp. 94. ISBN 978-0596007966. 
  2. ^ "GNU `make'". Free Software Foundation. 
  3. ^ "Manual Pages: make". OpenBSD 4.8. 
  4. ^ an overview on dsls, 2007/02/27, phoenix wiki
  5. ^[dead link]
  6. ^ Re: Choreography and REST, from Christopher B Ferris on 2002-08-09
  7. ^ Target Junior Makefiles, Andrew W. Fitzgibbon and William A. Hoffman
  8. ^ make, The Open Group Base Specifications Issue 6
  9. ^ A listing of some Make internal macros at
  10. ^ Automatic Variables GNU `make'

External links

Reference, manuals, books


Debugging GNU Make


Wikimedia Foundation. 2010.

Look at other dictionaries:

  • Software cracking — is the modification of software to remove or disable features which are considered undesirable by the person cracking the software, usually related to protection methods: copy protection, trial/demo version, serial number, hardware key, date… …   Wikipedia

  • Make — may refer to: Make (software), a computer software utility Make (magazine), a DIWO (Do It With Others) technology periodical and the associated television program MAKE Architects, a UK architecture practice Make, Botswana, a small village in the… …   Wikipedia

  • Software engineering demographics — There are many software engineers. Canada, the European Union, Japan, and Australia will probably find corresponding numbers of SE practitioners. European Union [ en.htm] India There has been a healthy growth in the number… …   Wikipedia

  • make — ▪ I. make make 1 [meɪk] verb made PTandPP [meɪd] making PRESPART 1. [transitive] MANUFACTURING to produce something by working or by using industrial processes …   Financial and business terms

  • Software prototyping — Software prototyping, a possible activity during software development, is the creation of prototypes, i.e., incomplete versions of the software program being developed.A prototype typically simulates only a few aspects of the features of the… …   Wikipedia

  • Software patent debate — is the argument dealing with the extent to which it should be possible to patent software and computer implemented inventions as a matter of public policy. Policy debate on software patents has been active for years. [Cite book |last=Nichols… …   Wikipedia

  • Software testing — is an empirical investigation conducted to provide stakeholders with information about the quality of the product or service under test [ [ Exploratory Testing] , Cem Kaner, Florida Institute of Technology,… …   Wikipedia

  • Software versioning — is the process of assigning either unique version names or unique version numbers to unique states of computer software. Within a given version number category (major, minor), these numbers are generally assigned in increasing order and… …   Wikipedia

  • Software rot — Software rot, also known as code rot or software erosion or software decay or software entropy, is a type of bit rot. It describes the perceived slow deterioration of software over time that will eventually lead to it becoming faulty, unusable,… …   Wikipedia

  • Make — (engl. machen, erstellen) ist ein Computerprogramm, das Shellskript ähnlich Kommandos in Abhängigkeit von Bedingungen ausführt. Es wird hauptsächlich bei der Softwareentwicklung eingesetzt. Genutzt wird es beispielsweise, um in einem Projekt, das …   Deutsch Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”

We are using cookies for the best presentation of our site. Continuing to use this site, you agree with this.