| Make | |
|---|---|
| Paradigm | macro,declarative |
| Designed by | Stuart Feldman |
| First appeared | April 1976; 49 years ago (1976-04) |
| Implementation language | C |
| OS | Unix-like,Inferno |
| File formats | Makefile |
| Majorimplementations | |
| BSD, GNU, nmake | |
| Dialects | |
| BSD make, GNU make, Microsoft nmake | |
| Influenced | |
| Ant,Rake,MSBuild, andothers | |
Insoftware development,Make is acommand-line interfacesoftware tool that performs actions ordered by configureddependencies as defined in aconfiguration file called amakefile. It is commonly used forbuild automation tobuildexecutable code (such as aprogram orlibrary) fromsource code. Make is also not limited to building and can perform any operation available via theoperating system shell.
Make is widely used, especially inUnix andUnix-likeoperating systems, even though many competing technologies and tools are available, including similar tools that perform actions based on dependencies, somecompilers and interactively via anintegrated development environment.
In addition to referring to the originalUnix tool, Make is also a technology since multiple tools have beenimplemented with roughly the same functionality – including similar makefilesyntax andsemantics.
Stuart Feldman created Make while atBell Labs. An early version was completed in April 1976.[1][2][3] Feldman received the 2003ACM Software System Award for authoring Make.[4]
Feldman describes the inspiration to write Make as arising from a coworker's frustration with the available tooling of the time:
Make originated with a visit fromSteve 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 *.owas 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 theUnix ethos: printable, debuggable, understandable stuff.
— Stuart Feldman,The Art of Unix Programming,Eric S. Raymond 2003
Before Make, building on Unix mostly consisted ofshell scripts written for each program's codebase. Make's dependency ordering and out-of-date checking makes the build process more robust and more efficient. The makefile allowed for better organization of build logic and often fewer build files.
Make is widely used in part due to its early inclusion inUnix, starting withPWB/UNIX 1.0, which featured a variety of software development tools.[3]
Make has beenimplemented numerous times, generally using the same makefile format and providing the same features, but some providing enhancements from the original. Examples:
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.
In general, based on a makefile, Make updates target files from source files if any source file has a newertimestamp than the target file or the target file does not exist. For example, this could include compilingC files (*.c) intoobject files, then linking the object files into an executable program. Or this could include compilingTypeScript files (*.ts) toJavaScript for use in a browser. Other examples include: convert a source image file to another format, copy a file to a content management system, and send e-mail about build status.
A makefile defines targets where each is either a file to generate or is a user-defined concept, called aphony target.
Make updates the targets passed as arguments:
make[-fmakefile][options][targets]
If no target is specified, Make updates the first target in the makefile which is often a phony target to perform the most commonly used action.
Make skips build actions if the target file timestamp is after that of the source files.[38] Doing so optimizes the build process by skipping actions when the target file is up-to-date, but sometimes updates are skipped erroneously due to file timestamp issues including restoring an older version of a source file, or when anetwork filesystem is a source of files and its clock or time zone is not synchronized with the machine running Make. Also, if a source file's timestamp is in the future, make repeatedly triggers unnecessary actions, causing longer build time.
When Make starts, it uses the makefile specified on the command-line or if not specified, then uses the one found by via specific search rules. Generally, Make defaults to using the file in theworking directory namedMakefile. GNU Make searches for the first file matching:GNUmakefile,makefile, orMakefile.
Make processes the options of the command-line based on the loaded makefile.
| Makefile | |
|---|---|
| Uniform Type Identifier (UTI) | public.make-source[39] |
Themakefile language is partiallydeclarative programming where end conditions are described but the order in which actions are to be taken is not.[40][41][42][43] This type of programming can be confusing to programmers used toimperative programming.
Makefiles can contain the following constructs:[44]
#Each rule begins with adependency line which consists of the rule'starget name followed by a colon (:), and optionally a list of targets (also known as prerequisites) on which the rule's target depends.[45]
target [target ...]: [component ...]Tab ↹[command 1] . . .Tab ↹[command n]
Usually a rule has a single target, rather than multiple.
A dependency line may be followed by a recipe: a series ofTAB indented command lines that define how to generate the target from the components (i.e. source files). If any prerequisite has a more recent timestamp than the target file or the target does not exist as a file, the recipe is performed.
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. Even though aspace is alsowhitespace, Make requires tab. Since this often leads to confusion and mistakes, this aspect of makefile syntax is subject to criticism.Eric S. Raymond describes it as "one of the worst design botches in the history of Unix"[46] andThe Unix-Haters Handbook said "using tabs as part of the syntax is like one of those pungee [sic] stick traps inThe Green Berets". Feldman explains the choice as caused by aworkaround for an early implementation difficulty, and preserved by a desire forbackward 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:
.RECIPEPREFIX:=:all::@echo"recipe prefix symbol is set to '$(.RECIPEPREFIX)'"
Each command is executed in a separateshell. Since operating systems use different shells, this can lead to unportable makefiles. For example, GNU Make (all POSIX Makes) executes commands with/bin/sh by default, whereUnix commands likecp are normally used. In contrast, Microsoft'snmake executes commands with cmd.exe wherebatch commands likecopy are available but not necessarily cp.
Since a recipe is optional, the dependency line can consist solely of components that refer to other targets:
realclean:cleandistclean
The following example rule is evaluated when Make updates target file.txt viamake file.txt. If file.html is newer than file.txt or file.txt does not exist, then the command is run to generate file.txt from file.html.
file.txt:file.htmllynx-dumpfile.html>file.txt
A command can have one or more of the following prefixes (after the tab):
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).
A makefile can define and use macros. Macros are usually referred to asvariables when they hold simple string definitions, likeCC=clang. Macros in makefiles may be overridden in thecommand-line arguments passed to the Make utility.Environment variables are also available as macros.
For example, the macroCC is frequently used in makefiles to refer to the location of aC compiler. If used consistently throughout the makefile, then the compiler used can be changed by changing the value of the macro rather than changing each rule command that invokes the compiler.
Macros are commonly named inall-caps:
MACRO=definition
A macro value can consist of other macro values. The value of macro is expanded on each uselazily.
A macro is used by expanding either via $NAME or $(NAME). The latter is safer since 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 inBSD.
NEW_MACRO=$(MACRO)-$(MACRO2)
Macros can be composed of shell commands by using thecommand substitution operator!=.[48]
YYYYMMDD!=date
The command-line syntax for overriding a macro is:
makeMACRO="value"[MACRO="value"...]TARGET[TARGET...]
Makefiles can access predefinedinternal macros, with? and@ being common.
target:component1component2# echo components YOUNGER than TARGETecho$?# echo TARGET nameecho$@
A common syntax when defining macros, which works on BSD and GNU Make, is to use+=,?=, and!= instead of the equal sign (=).[49]
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[50] 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-nfile.txtlynx -dump file.html > file.txt
Suffix rules cannot have any prerequisites of their own.[51] 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 ofpattern rules.[52]
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,[53] 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:%.htmllynx-dump$<>$@
Single-linecomments are started with thehash symbol (#).
A directive specifies special behavior such asincluding another makefile.
Line continuation is indicated with a backslash\ character at the end of a line.
target: component \ componentTab ↹command ; \ another-command | \ piped-command
The following commands are in the context of the makefile that follows.
make# updates first target, 'all'makehelp# updates target 'help' to list targetsmakedist# updates target 'dist' to build for distribution
PACKAGE=packageVERSION=`date"+%Y.%m%d%"`RELEASE_DIR=..RELEASE_FILE=$(PACKAGE)-$(VERSION)# Default target# note: variable LOGNAME comes from the environmentall:echo"Hello$(LOGNAME), nothing to do by default"echo"Try 'make help'"# Display targets by searching this filehelp:egrep"^# target:"[Mm]akefile# Make a releasedist:tar-cf$(RELEASE_DIR)/$(RELEASE_FILE)&&\gzip-9$(RELEASE_DIR)/$(RELEASE_FILE).tar
Below is a 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.[50][54]
CFLAGS?=-gLDLIBS+=-lmall:Out.txtOut.txt:helloworld./$<>$@helloworld:helloworld.o$(CC)$(LDFLAGS)-o$@$^$(LDLIBS)helloworld.o:helloworld.c$(CC)$(CFLAGS)-c-o$@$<clean:$(RM)Out.txthelloworldhelloworld.o
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:helloworldhelloworld:helloworld.o$(CC)$(CFLAGS)$(LDFLAGS)-o$@$^clean:$(RM)helloworldhelloworld.o# suffix rule.c.o:$(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# snippet to fail if not GNUifneq (,)ThismakefilerequiresGNUMake.endifPROGRAM=fooC_FILES:=$(wildcard*.c)OBJS:=$(patsubst%.c,%.o,$(C_FILES))CC=ccCFLAGS=-Wall-pedanticLDFLAGS=LDLIBS=-lmall:$(PROGRAM)$(PROGRAM):.depend$(OBJS)$(CC)$(CFLAGS)$(OBJS)$(LDFLAGS)-o$(PROGRAM)$(LDLIBS)depend:.depend.depend:cmd =gcc -MM -MFdepend$(var);catdepend >> .depend;.depend:@echo"Generating dependencies..."@$(foreachvar,$(C_FILES),$(cmd))@rm-fdepend-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:cleandepend
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 using the compiler to keep track of dependencies changes. GCC can statically analyze the source code and produce rules for the given file automatically by using the-MM switch. The other approach would be makefiles or third-party tools that would generate makefiles with dependencies (e.g.Automake toolchain by theGNU Project, can do so automatically).
Another approach is to use meta-build tools likeCMake,Meson etc.
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.
{{cite web}}: CS1 maint: bot: original URL status unknown (link)Makefile inclusion, conditional structures and for loops reminiscent of the C programming language are provided in make.
make – Shell and Utilities Reference,The Single UNIX Specification, Version 5 fromThe Open Groupmake(1) – FreeBSD General CommandsManual
| File system | |
|---|---|
| Processes | |
| User environment | |
| Text processing | |
| Shell builtins | |
| Searching | |
| Documentation | |
| Software development | |
| Miscellaneous | |
| International | |
|---|---|
| National | |
