Make (software)

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.[1] It was originally created by Stuart Feldman in April 1976 at Bell Labs.[2][3][1] Feldman received the 2003 ACM Software System Award for the authoring of this widespread tool.[4]

Feldman was inspired to write Make by the experience of a coworker in futilely debugging a program of his where the executable was accidentally not being updated with changes:

Make originated with a visit from Steve Johnson (author of yacc, etc.), storming into my office, cursing the Fates that had caused him to waste a morning debugging a correct program (bug had been fixed, file hadn't been compiled, cc *.o was therefore unaffected). As I had spent a part of the previous evening coping with the same disaster on a project I was working on, the idea of a tool to solve it came up. It began with an elaborate idea of a dependency analyzer, boiled down to something much simpler, and turned into Make that weekend. Use of tools that were still wet was part of the culture. Makefiles were text files, not magically encoded binaries, because that was the Unix ethos: printable, debuggable, understandable stuff.

— Stuart Feldman, The Art of Unix Programming, Eric S. Raymond 2003

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.

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:

• Sun DevPro Make appeared in 1986 with SunOS-3.2. With SunOS-3.2, It was delivered as optional program; with SunOS-4.0, SunPro Make was made the default Make program.[5] In December 2006, Sun DevPro Make was made open source as part of the efforts to open-source Solaris.[6][7]
• dmake or Distributed Make that came with Sun Solaris Studio as its default Make, but not the default one on the Solaris Operating System (SunOS). It was originally required to build OpenOffice, but in 2009[8] the build system was rewritten to use GNU Make. While Apache OpenOffice still contains a mixture of both build systems,[9] the much more actively developed LibreOffice only uses the modernized "gbuild" now.[8]
• BSD Make (pmake,[10] bmake[11] or fmake[12]), 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,[11] NetBSD[13] and OpenBSD.[14] 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,[15] including generation of targets at runtime.
• GNU Make (short gmake) is the standard implementation of Make for Linux and macOS.[16] 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.[17] For example, the foreach function can be used to iterate over a list of values, such as the names of files in a given directory.[18] GNU Make is required for building many software systems, including GCC (since version 3.4[19]), the Linux kernel,[20][21] Apache OpenOffice,[9] LibreOffice,[8] and Mozilla Firefox.[22]
• Rocky Bernstein's Remake[23] is a fork of GNU Make and provides several extensions over GNU Make, such as better location and error-location reporting, execution tracing, execution profiling, and it contains a debugger.
• Glenn Fowler's nmake[24] 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.[25] It supports preprocessor directives such as includes and conditional expressions which use variables set on the command-line or within the makefiles.[26][27] Inference rules differ from Make; for example they can include search paths.[28] The Make tool supplied with Embarcadero products has a command-line option that "Causes MAKE to mimic Microsoft's NMAKE."[29]. Qt Project's Jom tool is a clone of nmake.[30]
• Mk replaced Make in Research Unix, starting from version 9.[31] A redesign of the original tool by Bell Labs programmer Andrew G. Hume, it features a different syntax. Mk became the standard build tool in Plan 9, Bell Labs' intended successor to Unix.[32]
• Kati is Google's replacement of GNU Make, used in Android OS builds. It translates the makefile into ninja for faster incremental builds.[33]

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, Makepp and some versions of BSD Make default to looking first for files named "GNUmakefile",[34] "Makeppfile"[35] and "BSDmakefile"[36] 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 indicating 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 symbolic "phony" target named all.

Make decides whether a target needs to be regenerated by comparing file modification times.[37] 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 time zone 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.

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

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, or Makefile and then runs the specified (or default) target(s) from (only) that file.

The makefile language is similar to declarative programming.[38][39][40] 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, CMake or GYP (or more advanced NG).

target [target ...]: [component ...]
Tab ↹[command 1]
	   .
	   .
	   .
Tab ↹[command n]

targets : prerequisites ; command

hello: ; @echo "hello"

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

realclean: clean distclean

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

make file.txt

MACRO = definition

NEW_MACRO = $(MACRO)-$(MACRO2)

YYYYMMDD  = ` date `

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

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

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 $@

.SUFFIXES: .txt .html

# From .html to .txt
.html.txt:
	lynx -dump __SUB_LEVEL_SECTION_6__lt;   >   $@

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

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

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

The makefile:

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

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.[45][49]

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) 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 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
	$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^

clean: FRC
	$(RM) 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

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.
endif

PROGRAM = foo
C_FILES := $(wildcard *.c)
OBJS := $(patsubst %.c, %.o, $(C_FILES))
CC = cc
CFLAGS = -Wall -pedantic
LDFLAGS =
LDLIBS = -lm

all: $(PROGRAM)

$(PROGRAM): .depend $(OBJS)
	$(CC) $(CFLAGS) $(OBJS) $(LDFLAGS) -o $(PROGRAM) $(LDLIBS)

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 $@

%: %.o
	$(CC) $(CFLAGS) -o $@ $<

clean:
	rm -f .depend $(OBJS)

.PHONY: clean depend

• List of build automation software
• Dependency graph

Wikibooks has a book on the topic of: make

• GNU Make homepage
• Practical Makefiles, by Example
• Writing and Debugging a Makefile
• "Ask Mr. Make" series of article about GNU Make
• Managing Projects with GNU make -- 3.xth edition
• What is wrong with make?
• What’s Wrong With GNU make?
• Recursive Make Considered Harmful
• Advanced Auto-Dependency Generation.
• Using NMake
• Make7 - A portable open source make utility written in Seed7
• Microsoft's NMAKE predefined rules.