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 searches the current directory for the makefile to use, e.g. GNU Make searches files in order for a file named one of .mw-parser-output .monospacedfont-family:monospace,monospaceGNUmakefile, makefile, or Makefile and then runs the specified (or default) target(s) from (only) that file.
The makefile language is similar to declarative programming.[39][40][41] 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 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.[43]
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.
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"[44] 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:
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 (all POSIX Makes) 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 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.
Suffix rules cannot have any prerequisites of their own.[48] 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.[49]
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 $
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:
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.
If you want to run or update a task when certain files are updated, the make utility can come in handy. The make utility requires a file, Makefile (or makefile), which defines set of tasks to be executed. You may have used make to compile a program from source code. Most open source projects use make to compile a final executable binary, which can then be installed using make install.
If we try to run make after the changes, only the target say_hello will be executed. That's because only the first target in the makefile is the default target. Often called the default goal, this is the reason you will see all as the first target in most projects. It is the responsibility of all to call other targets. We can override this behavior using a special phony target called .DEFAULT_GOAL.
Before running make, let's include another special phony target, .PHONY, where we define all the targets that are not files. make will run its recipe regardless of whether a file with that name exists or what its last modification time is. Here is the complete makefile:
As such, when you run the make command inside of make, you can use the export directive to make it accessible to sub-make commands. In this example, cooly is exported such that the makefile in subdir can use it.
To prepare to use make, you must write a file calledthe makefile that describes the relationships among filesin your program and provides commands for updating each file.In a program, typically, the executable file is updated from objectfiles, which are in turn made by compiling source files.
suffices to perform all necessary recompilations. The make programuses the makefile data base and the last-modification times of the files todecide which of the files need to be updated. For each of those files, itissues the recipes recorded in the data base.
In this chapter, we will discuss a simple makefile that describes how tocompile and link a text editor which consists of eight C source filesand three header files. The makefile can also tell make how torun miscellaneous commands when explicitly asked (for example, to removecertain files as a clean-up operation). To see a more complex exampleof a makefile, see Complex Makefile Example.
A makefile may contain other text besides rules, but a simple makefileneed only contain rules. Rules may look somewhat more complicatedthan shown in this template, but all fit the pattern more or less.
A recipe may follow each line that contains a target andprerequisites. These recipes say how to update the target file. Atab character (or whatever character is specified by the.RECIPEPREFIX variable; see Other Special Variables) must come atthe beginning of every line in the recipe to distinguish recipes fromother lines in the makefile. (Bear in mind that make does notknow anything about how the recipes work. It is up to you to supplyrecipes that will update the target file properly. All makedoes is execute the recipe you have specified when the target fileneeds to be updated.)
Such duplication is error-prone; if a new object file is added to thesystem, we might add it to one list and forget the other. We can eliminatethe risk and simplify the makefile by using a variable. Variablesallow a text string to be defined once and substituted in multiple placeslater (see How to Use Variables).
It is standard practice for every makefile to have a variable namedobjects, OBJECTS, objs, OBJS, obj,or OBJ which is a list of all object file names. We woulddefine such a variable objects with a line like this in themakefile:
When the objects of a makefile are created only by implicit rules, analternative style of makefile is possible. In this style of makefile,you group entries by their prerequisites instead of by their targets.Here is what one looks like:
A rule such as this should not be placed at the beginning of themakefile, because we do not want it to run by default! Thus, in theexample makefile, we want the rule for edit, which recompilesthe editor, to remain the default goal.
Normally you should call your makefile either makefile orMakefile. (We recommend Makefile because it appearsprominently near the beginning of a directory listing, right near otherimportant files such as README.) The first name checked,GNUmakefile, is not recommended for most makefiles. You shoulduse this name if you have a makefile that is specific to GNUmake, and will not be understood by other versions ofmake. Other make programs look for makefile andMakefile, but not GNUmakefile.
 38c6e68cf9