Managing Projects with GNU Make (Nutshell Handbooks)

3.8 Standard make Variables

In addition to automatic variables, make maintains variables revealing bits and pieces of its own state as well as variables for customizing built-in rules:

MAKE_VERSION

This is the version number of GNU make . At the time of this writing, its value is 3.80 , and the value in the CVS repository is 3.81rc1 .

The previous version of make , 3.79.1, did not support the eval and value functions (among other changes) and it is still very common. So when I write makefile s that require these features, I use this variable to test the version of make I'm running. We'll see an example of that in Section 4.2.4 in Chapter 4.

CURDIR

This variable contains the current working directory (cwd) of the executing make process. This will be the same directory the make program was executed from (and it will be the same as the shell variable PWD ), unless the ”directory ( -C ) option is used. The ”directory option instructs make to change to a different directory before searching for any makefile . The complete form of the option is ”directory= directory- name or -C directory-name . If ”directory is used, CURDIR will contain the directory argument to ”include-dir .

I typically invoke make from emacs while coding. For instance, my current project is in Java and uses a single makefile in a top-level directory (not necessarily the directory containing the code). In this case, using the ”directory option allows me to invoke make from any directory in the source tree and still access the makefile . Within the makefile , all paths are relative to the makefile directory. Absolute paths are occasionally required and these are accessed using CURDIR .

MAKEFILE_LIST

This variable contains a list of each file make has read including the default makefile and makefile s specified on the command line or through include directives. Just before each file is read, the name is appended to the MAKEFILE_LIST variable. So a makefile can always determine its own name by examining the last word of the list.

MAKECMDGOALS

The MAKECMDGOALS variable contains a list of all the targets specified on the command line for the current execution of make . It does not include command-line options or variable assignments. For instance:

$ make -f- FOO=bar -k goal <<< 'goal:;# $(MAKECMDGOALS)' # goal

The example uses the "trick" of telling make to read the makefile from the stdin with the -f- (or ”file ) option. The stdin is redirected from a command-line string using bash 's here string , "<<<", syntax. ^[3] The makefile itself consists of the default goal goal , while the command script is given on the same line by separating the target from the command with a semicolon. The command script contains the single line:

^[3] For those of you who want to run this type of example in another shell, use:

# $(MAKECMDGOALS)

MAKECMDGOALS is typically used when a target requires special handling. The primary example is the "clean" target. When invoking "clean," make should not perform the usual dependency file generation triggered by include (discussed in Section 2.7 in Chapter 2). To prevent this use ifneq and MAKECMDGOALS :

ifneq "$(MAKECMDGOALS)" "clean" -include $(subst .xml,.d,$(xml_src)) endif

.VARIABLES

This contains a list of the names of all the variables defined in makefile s read so far, with the exception of target-specific variables. The variable is read-only and any assignment to it is ignored.

list: @echo "$(.VARIABLES)" tr ' ' '5' grep MAKEF $ make MAKEFLAGS MAKEFILE_LIST MAKEFILES

As you've seen, variables are also used to customize the implicit rules built in to make . The rules for C/C++ are typical of the form these variables take for all programming languages. Figure 3-1 shows the variables controlling translation from one file type to another.

The variables have the basic form: ACTION . suffix . The ACTION is COMPILE for creating an object file, LINK for creating an executable, or the "special" operations PREPROCESS , YACC , LEX for running the C preprocessor, yacc , or lex , respectively. The suffix indicates the source file type.

The standard " path " through these variables for, say, C++, uses two rules. First, compile C++ source files to object files. Then link the object files into an executable.

%.o: %.C $(COMPILE.C) $(OUTPUT_OPTION) $< %: %.o $(LINK.o) $^ $(LOADLIBES) $(LDLIBS) -o $@

The first rule uses these variable definitions:

COMPILE.C = $(COMPILE.cc) COMPILE.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c CXX = g++ OUTPUT_OPTION = -o $@

GNU make supports either of the suffixes .C or .cc for denoting C++ source files. The CXX variable indicates the C++ compiler to use and defaults to g++ . The variables CXXFLAGS , CPPFLAGS , and TARGET_ARCH have no default value. They are intended for use by end-users to customize the build process. The three variables hold the C++ compiler flags, C preprocessor flags, and architecture-specific compilation options, respectively. The OUTPUT_OPTION contains the output file option.

The linking rule is a bit simpler:

LINK.o = $(CC) $(LDFLAGS) $(TARGET_ARCH) CC = gcc

This rule uses the C compiler to combine object files into an executable. The default for the C compiler is gcc . LDFLAGS and TARGET_ARCH have no default value. The LDFLAGS variable holds options for linking such as -L flags. The LOADLIBES and LDLIBS variables contain lists of libraries to link against. Two variables are included mostly for portability.

This was a quick tour through the make variables. There are more, but this gives you the flavor of how variables are integrated with rules. Another group of variables deals with TEX and has its own set of rules. Recursive make is another feature supported by variables. We'll discuss this topic in Chapter 6.