Make (software)

In software development, Make is a build automation tool that builds executable programs and libraries from source code by reading files called makefiles which specify how to derive the target program. Though integrated development environments and language-specific compiler features can also be used to manage a build process, Make remains widely used, especially in Unix and Unix-like operating systems.

Make

Paradigm	macro, declarative
Designed by	Stuart Feldman
First appeared	April 1976; 48 years ago (1976-04)
Implementation language	C
OS	Unix-like, Inferno
File formats	Makefile
Major implementations
BSD, GNU, nmake
Dialects
BSD make, GNU make, Microsoft nmake
Influenced
Ant, Rake, MSBuild, and others

Make is not limited to building programs. It can also be used to manage any project where some files need to be updated automatically from other files whenever the other files change.

Origin

Make is one of the most widespread dependency-tracking build utilities, primarily due to its early inclusion in Unix, starting with PWB/UNIX 1.0, which featured a variety of tools for software development tasks.^[1] It was created by Stuart Feldman in April 1976 at Bell Labs.^[2][3][1] Feldman received the 2003 ACM Software System Award for authoring the 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 code. Being able to combine the commands for the build targets into a single file and being able to abstract dependency tracking and archive handling was an important step in the direction of modern build environments.

Derivatives

Make has been rewritten numerous times, including new implementations that use the same file format and basic algorithmic principles and also provide non-standard enhancements. Examples are:

• Sun DevPro Make appeared in 1986 with SunOS-3.2. With SunOS-3.2, It was delivered as an optional program; with SunOS-4.0, SunPro Make was made the default Make program.^{[5][better source needed]} 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.^{[citation needed]}
• 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 GNU Compiler Collection (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, as of 2020 used in Android OS builds. It translates the makefile into ninja for faster incremental builds (similar to the cmake metatool).^[33]
• Snakemake is a python-driven implementation for compiling and running bioinformatics workflows.^[34]

POSIX includes standardization of the basic features and operation of the Make utility, and is implemented with varying degrees of compatibility with 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",^[35] "Makeppfile"^[36] and "BSDmakefile"^[37] respectively, which allows one to put makefiles which use implementation-defined behavior in separate locations.

Behavior

Make is traditionally used for compiling source code files (e.g. *.c, *.ts files, etc.) to a target object file type that can be directly executed either as a standalone executable (as is the case for C source code), or not (as is the case for TypeScript source code).

Make is not limited to object files only: It is applicable in any use case where a set of files is dependent on the content of another set of files. Make includes a dependency mechanism to manage these relations correctly. A possible use case not related to programming is to detect a change made to an image file (the source) and then convert the file to some specific format, copy the result into a content management system, and send e-mail to a set of users indicating that the actions were performed.

Make is invoked with a list of target names in form of 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 which doesn't correspond to any stored file.

Make decides whether a target needs to be regenerated by comparing file modification times.^[38] 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 also traditionally used for providing commands to automate common software development 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 check # Unit testing without installation 

Makefiles

Makefile

Uniform Type Identifier (UTI)	public.make-source^[39]

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

The makefile language is similar to declarative programming.^{[40][41][42][43]} 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.

A common problem in build automation is the tailoring of a build process to a given platform. For example, the compiler used on one platform might not accept the same options as the one used on another. 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).

Makefiles may contain five types of constructs:^[44]

• An explicit rule says when and how to remake one or more files, called the rule's targets. It lists the other files that the targets depend on, called the prerequisites of the target, and may also give a recipe to use to create or update the targets.
• An implicit rule says when and how to remake a class of files based on their names. It describes how a target may depend on a file with a name similar to the target and gives a recipe to create or update such a target.
• A variable definition is a line that specifies a text string value for a variable that can be substituted into the text later.
• A directive is an instruction for make to do something special while reading the makefile such as reading another makefile.
• Lines starting with # are used for comments.

Rules

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

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.

Each dependency line may be followed by a series of TAB indented command lines which define how to transform the components (usually source files) into the target (usually the "output"). If any of the prerequisites has a more recent modification time than the target, the command lines are run. The GNU Make documentation refers to the commands associated with a rule as a "recipe".

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; it has been described by Eric S. Raymond as "one of the worst design botches in the history of Unix"^[46] and The Unix-Haters Handbook said "using tabs as part of the syntax is like one of those pungee stick traps in The Green Berets". Feldman explains the choice as caused by a workaround for an early implementation difficulty preserved by a desire for backward compatibility with the very first users:

Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history.

— Stuart Feldman^[46]

GNU Make. since version 3.82, allows the choice of 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 example, GNU Make (all POSIX Makes) executes commands with /bin/sh by default, 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 omit the recipe. The dependency line can consist solely of components that refer to other 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 rule above 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.^[47]

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

Macros

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 $(). (Omitting the parentheses leads to Make interpreting the next letter after the $ as the entire variable name.) An equivalent form uses curly braces rather than parentheses, i.e. ${}, which is the style used in the BSDs.

NEW_MACRO = $(MACRO)-$(MACRO2) 

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" ` 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 . 

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

A somewhat common syntax expansion is the use of +=, ?=, and != instead of the equal sign. It works on BSD and GNU makes alike.^[48]

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^[49] 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 example above expands.

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

Pattern rules

Suffix rules cannot have any prerequisites of their own.^[50] 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.^[51]

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

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

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

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 \ component Tab ↹command ; \ Tab ↹command | \ Tab ↹piped-command 

Example makefiles

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

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 makefile above 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 

Dependency tracking

Makefile consist of dependencies and a forgotten or an extra one may not be immediately obvious to the user and may result in subtle bugs in the generated software that are hard to catch. Various approaches may be used to avoid this problem and keep dependencies in source and makefiles in sync. One approach is by using compiler to keep track of dependencies changes .e.g GCC can statically analyze the source code and produce rules for the given file automatically by using -MM switch. The other approach would be makefiles or third-party tools that would generate makefiles with dependencies (e.g. Automake toolchain by the GNU Project, can do so automatically).

Another approach is to use meta-build tools like CMake, Meson etc.

See also

•  Free and open-source software portal

• List of build automation software
• Dependency graph

References

1. Thompson, T. J. (November 1980). "Designer's Workbench: Providing a Production Environment". Bell System Technical Journal. 59 (9): 1811–1825. doi:10.1002/j.1538-7305.1980.tb03063.x. S2CID 27213583. In the general maintenance of DWB, we have used the Source Code Control System and make utility provided by the PWB/UNIX* interactive operating system.
2. "V7/usr/src/cmd/make/ident.c". tuhs.org. 1 September 2013. Archived from the original on 1 September 2013. Retrieved 18 March 2018.
3. Feldman, S. I. (April 1979). "Make --- A Program for Maintaining Computer Programs". Software: Practice and Experience. 9 (4): 255–265. CiteSeerX 10.1.1.39.7058. doi:10.1002/spe.4380090402. S2CID 33059412.
4. Matthew Doar (2005). Practical Development Environments. O'Reilly Media. p. 94. ISBN 978-0-596-00796-6.
5. "Google Groups". arquivo.pt. Archived from the original on 22 January 2011. Retrieved 18 March 2018.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
6. . 12 December 2013. Archived from the original on 12 December 2013. Retrieved 18 March 2018.
7. Grisanzio, Jim. The OpenSolaris Story.
8. "Development/Gbuild - The Document Foundation Wiki". wiki.documentfoundation.org. Retrieved 18 March 2018.
9. "Apache OpenOffice Building Guide - Apache OpenOffice Wiki". wiki.openoffice.org. Retrieved 18 March 2018.
10. FreeBSD 2.0.5 Make Source Code, 1993
11. "Bmake(1)".
12. https://manpages.debian.org/jessie/freebsd-buildutils/fmake.1 ^{[bare URL plain text file]}
13. "make". NetBSD Manual Pages. Retrieved 9 July 2020.
14. "make(1) - OpenBSD manual pages". man.openbsd.org. Retrieved 18 March 2018.
15. "make". FreeBSD. Retrieved 9 July 2020. Makefile inclusion, conditional structures and for loops reminiscent of the C programming language are provided in make.
16. Arnold Robbins (2005), Unix in a Nutshell, Fourth Edition, O'Reilly
17. "8. Functions for Transforming Text", GNU make, Free Software Foundation, 2013
18. "8.5 The foreach Function", GNU make, Free Software Foundation, 2013
19. "GCC 3.4 Release Series Changes, New Features, and Fixes". Free Software Foundation. 2006.
20. Javier Martinez Canillas (December 26, 2012). "Kbuild: the Linux Kernel Build System". Linux Journal.
21. Greg Kroah-Hartman (2006), Linux Kernel in a Nutshell, O'Reilly
22. "Build Instructions".
23. Rocky Bernstein. "Remake – GNU Make with comprehensible tracing and a debugger".
24. Glenn Fowler (January 4, 2012). . Information and Software Systems Research, AT&T Labs Research. Archived from the original on September 2, 2015. Retrieved May 26, 2014.
25. "NMAKE Reference Visual Studio 2015". Microsoft. 2015.
26. "Makefile Preprocessing Directives". 2014.
27. "Makefile Preprocessing Operators". Microsoft. 2014.
28. "Search Paths in Rules". Microsoft. 2014.
29. "MAKE". CodeGear(TM). 2008.
30. "Jom - Qt Wiki". Qt Project. 2021.
31. McIlroy, M. D. (1987). A Research Unix reader: annotated excerpts from the Programmer's Manual, 1971–1986 (PDF) (Technical report). Bell Labs. CSTR 139.
32. Hume, Andrew G.; Flandrena, Bob (2002). "Maintaining files on Plan 9 with Mk". Plan 9 Programmer’s Manual. AT&T Bell Laboratories. from the original on July 11, 2015.
33. "google/kati: An experimental GNU make clone". GitHub. 30 November 2020.
34. Mölder, Felix; Jablonski, Kim Philipp; Letcher, Brice; Hall, Michael B.; Tomkins-Tinch, Christopher H.; Sochat, Vanessa; Forster, Jan; Lee, Soohyun; Twardziok, Sven O.; Kanitz, Alexander; Wilm, Andreas (2021-04-19). "Sustainable data analysis with Snakemake". F1000Research. 10: 33. doi:10.12688/f1000research.29032.2. ISSN 2046-1402. PMC 8114187. PMID 34035898.
35. "GNU 'make'". Free Software Foundation.
36. "Makepp".
37. "Free BSD make".
38. How to sort Linux ls command file output September 13, 2016, at the Wayback Machine
39. "makefile". Apple Developer Documentation: Uniform Type Identifiers. Apple Inc.
40. Adams, P. and Solomon, M., 1993, An overview of the CAPITL software development environment. In International Workshop on Software Configuration Management (pp. 1-34). Berlin, Heidelberg: Springer Berlin Heidelberg.
41. an overview on dsls October 23, 2007, at the Wayback Machine, 2007/02/27, phoenix wiki
42. Re: Choreography and REST September 12, 2016, at the Wayback Machine, from Christopher B Ferris on 2002-08-09
43. Target Junior Makefiles January 7, 2010, at the Wayback Machine, Andrew W. Fitzgibbon and William A. Hoffman
44. 3.1 What Makefiles Contain, GNU make, Free Software Foundation
45. "Prerequisite Types (GNU make)". GNU.org. GNU Project. Retrieved 15 December 2020.
46. "Chapter 15. Tools: make: Automating Your Recipes", The Art of Unix Programming, Eric S. Raymond 2003
47. make – Shell and Utilities Reference, The Single UNIX Specification, Version 4 from The Open Group
48. make(1) – FreeBSD General Commands Manual
49. "make". www.opengroup.org. Retrieved 18 March 2018.
50. "GNU make manual: suffix rules". Free Software Foundation.
51. "GNU make manual: pattern rules". Free Software Foundation.
52. See section Pattern Matching Rules in the SunPro man page May 29, 2014, at the Wayback Machine
53. Automatic Variables April 25, 2016, at the Wayback Machine GNU `make'

External links

 

Wikibooks has a book on the topic of: make

• GNU Make homepage