Let's start by looking at a sample makefile:
############################################################################## # # Sample Makefile for C++ applications # Works for single and multiple file programs. # written by Robert Duvall # modified by Owen Astrachan # and by Garrett Mitchener # ############################################################################## ############################################################################## # Application-specific variables # EXEC is the name of the executable file # SRC_FILES is a list of all source code files that must be linked # to create the executable ############################################################################## EXEC = usepix SRC_FILES = application.cc displaycommand.cc filelister.cc menu.cc \ menuitem.cc pixmap.cc quitcommand.cc readcommand.cc \ usepix.cc ############################################################################## # Where to find course related files # COURSE_DIR is where various header files (.h) and library files (.so and .a) # are found. LIB_DIR is where other libraries not specific to the course # are kept. # for CS machines # COURSE_DIR = /usr/project/courses/cps108/lib # LIB_DIR = /usr/local/lib # for acpub machines COURSE_DIR = /afs/acpub/users/o/l/ola/cps108/lib LIB_DIR = /afs/acpub/project/cps/lib ############################################################################## # Compiler specifications # These match the variable names given in /usr/share/lib/make/make.rules # so that make's generic rules work to compile our files. # gmake prefers CXX and CXXFLAGS for c++ programs ############################################################################## # Which compiler should be used CXX = g++ CC = $(CXX) # What flags should be passed to the compiler DEBUG_LEVEL = -g EXTRA_CCFLAGS = -Wall CXXFLAGS = $(DEBUG_LEVEL) $(EXTRA_CCFLAGS) CCFLAGS = $(CXXFLAGS) # What flags should be passed to the C pre-processor # In other words, where should we look for files to include - note, # you should never need to include compiler specific directories here # because each compiler already knows where to look for its system # files (unless you want to override the defaults) CPPFLAGS = -I. \ -I$(COURSE_DIR) # What flags should be passed to the linker # In other words, where should we look for libraries to link with - note, # you should never need to include compiler specific directories here # because each compiler already knows where to look for its system files. LDFLAGS = -L. \ -L$(COURSE_DIR) \ -R $(LIB_DIR):$(COURSE_DIR) # What libraries should be linked with. # For example, -lm links with libm.so, the math library. # If you make a library of your own, say, libscandir.a, you have to link it # in by adding -lscandir here. LDLIBS = -lscandir # All source files have associated object files. # This line sets `OFILES' to have the same value as `SRC_FILES' but # with all the .cc's changed into .o's. O_FILES = $(SRC_FILES:%.cc=%.o) ########################################################################### # Additional rules make should know about in order to compile our files ########################################################################### # all is the default rule all: $(EXEC) # exec depends on the object files # It is made automagically using the LDFLAGS and LOADLIBES variables. # The .o files are made automagically using the CXXFLAGS variable. $(EXEC): $(O_FILES) # to use `makedepend', the target is `depend' depend: -> makedepend -- $(CXXFLAGS) -- -Y $(SRC_FILES) # clean up after you're done clean: -> $(RM) $(O_FILES) core *.rpo very-clean: clean -> $(RM) $(EXEC)
Note that the arrows ->
represent places where you should
put tab characters, not eights spaces. It hath been decreed that this
shalt be a tab character. Emacs and XEmacs have a makefile mode,
which you can get into by typing M-x makefile-mode
if it doesn't
come up automatically. In makefile mode, pressing the tab
key
inserts a real tab. Alternatively, the keystrokes C-q C-i
or
C-q tab
will enter a tab character in any mode. (C-q
is
emacs for quote next key unprocessed.)
You should name your makefile `Makefile' with that capitalization.
Make looks for that file automatically. If you don't name it that,
you'll have to tell make specifically which file to use (as in
gmake -f somethingelse ...
).
The short answer of how to use that makefile is this: Change the line
that says SRC_FILES =
so that the right-hand side of the equals
sign is a list of all the .cc
files in your project. Change the
line that says EXEC =
so that the right-hand side of the equals
sign is the name of your executable.
The first time you use make, add a .cc
file, or any time you
change whether a .cc
file includes a particular .h
file, run
the command:
gmake depend
To build your executable in general, run the command gmake
. To
clean up your directory and get rid of files you don't need, run
gmake clean
.
These short directions will be enough to get you through the first assignment or two, but after that, you'll probably need to start changing more stuff further down in the makefile, and to know what to do, you'll have to understand how make works. So, without further ado...
Any line which begins with a sharp sign (#) is ignored by the makefile as a comment. Comment lines can be used to leave instructions for whoever has to use your makefile (including yourself). They are also useful for allowing someone to select between alternative definitions of macros. For example, several lines of the makefile have been commented out here:
The idea is that you should un-comment exactly one definition for# for CS machines # COURSE_DIR = /usr/project/courses/cps108/lib # LIB_DIR = /usr/local/lib # for acpub machines COURSE_DIR = /afs/acpub/users/o/l/ola/cps108/lib LIB_DIR = /afs/acpub/project/cps/lib
COURSE_DIR
and LIB_DIR
, depending on which computer system
you're using. By keeping these alternatives in the file with all but
one hidden, you make it easier on yourself to move your project from
one network to another.
Continuing long lines is easy, just put a backslash at the end of the line. Make pretends the following long command is all on one line:
Make replaces the backslashes with a space when it combines the lines, so just don't break a line in the middle of a word.SRC_FILES = application.cc displaycommand.cc filelister.cc menu.cc \ menuitem.cc pixmap.cc quitcommand.cc readcommand.cc \ usepix.cc
In a makefile, it is very easy to define a macro, or text-substitution. These are similar to environment variables in the shell or string variables in most programming languages:
COURSE_DIR = /afs/acpub/users/o/l/ola/cps108/lib
Whenever make sees $(COURSE_DIR)
in the makefile, it will
substitute in the text contained in the macro COURSE_DIR
.
Remember, use the dollar sign and parentheses only when you want to
reference the macro. Just use its name to assign it a value.
One really useful thing about macros is that they can reference other macros:
CXXFLAGS = $(DEBUG_LEVEL) $(EXTRA_CCFLAGS)
The trick is that make doesn't substitute for DEBUG_LEVEL
immediately when you define CXXFLAGS
. Instead, when you
reference CXXFLAGS
, it expands into
$(DEBUG_LEVEL) $(EXTRA_CCFLAGS)
.
Since that still has
$
's in it, make expands it again into -g -Wall
.
Therefore, you can define macros in any order, as long as they are
defined before they are actually expanded.
$
commands
One line of the sample makefile illustrates a special command that
make provides through the $
symbol:
O_FILES = $(SRC_FILES:%.cc=%.o)
This particular line sets O_FILES
to be the same as SRC_FILES
but with all the .cc
suffixes replaced with .o
. This is
useful because you can easily add a new class to your project by
adding its .cc
filename to the definition of SRC_FILES
. Its
object file will automatically be added to O_FILES
. This means
that adding a file to your project requires changing only one line in
your makefile. Furthermore, having a list of all source and object
files is quite useful, as you'll soon see.
Dependency rules are statements that make uses to determine which files need to be brought up to date. They consist of a line declaring what target file depends on which dependencies, followed by zero or more command lines which tell it what to do to bring the target up to date. For example (from another makefile):
OBJ = menu.o application.o pixmap.o CXX = g++ CXXFLAGS = -g -Wall usepix: $(OBJ) -> $(CXX) $(CXXFLAGS) -o usepix $(OBJ) -lm
The executable usepix
is the target and all those .o
files
are the dependencies. The $(CXX)
line turns into a command to
g++
when all those macros are expanded.
Again I must say, it hath been declared that command lines shalt begin with a tab character and end with a new-line character. If the last line of your makefile is not doing anything, it may be that you forgot to push enter at the end of that line.
The dependency line states that the file usepix
depends upon the
files in the macro OBJ
, which in this case expands to
application.o
, menu.o
, etc. If you ask make to update
usepix
by entering the command gmake usepix
on the shell
command line, it will find this dependency line and look at all the
.o
files usepix depends upon. If one of them is determined to be
out of date, it is updated. If after all that one of those .o
files is newer than usepix
, or if usepix
doesn't exist, make
will execute the compilation command underneath the dependency line
and build an up-to-date version of usepix
. You may have as many
command lines as you want, as long as they all begin with tab
characters. You may also have zero command lines, which is useful for
pseudo-targets and implicit rules, which I will explain later. All
those macros are fully expanded before make looks at any dependencies.
The first dependency is magic. When you execute make, it expects
you to give it the name of a target to update on the command line,
ie.gmake usepix
. If you don't give a target, it simply
updates the first target it comes to. In the first sample makefile,
it's all
, and in the smaller second example, it's usepix
,
but in a larger project, there might be several test programs,
libraries, and so on. It's therefore common to have a first target
called `all' which depends on the files you want to update most
frequently. No file named `all' ever really exists because it is a
pseudo-target. Which brings us to the next item...
Pseudo-targets are really useful. A pseudo-target is a file which never really exists. It has a dependency section in the makefile, and if you tell make to update that target, it will do its normal stuff and update all the dependencies, then run any commands underneath the dependency line.
Here's an example that uses a pseudo-target to effectively combine two other targets so that you can update them with one command:
testsuite: test1 test2 test1: test1.o foo.o bar.o -> ... test2: test2.o foo.o bar.o -> ...
Issuing the command gmake testsuite
causes make to update
test1
and test2
.
Another way to use pseudo-targets is to have a target which has no dependencies but has a few commands listed under it. In the sample makefile, `clean' is just such a pseudo-target:
clean: -> $(RM) $(O_FILES) core *.rpo
Targets which have no dependencies are always considered out of date
and any commands listed under them are always executed. If you were
to issue the command gmake clean
using the sample makefile,
make would remove all those .o
files from the current directory.
Having a `cleanup' target or two is quite useful: You're not likely to
mistype gmake clean
and even if you did, it wouldn't be a
disaster. But notice how easy it is to mistype rm -f *.o
(remove
all your .o
files) as rm -f *>o
(remove everything
and re-direct any output into a file called o
). Holding down the
shift key a moment too long can wipe out weeks of work, and make can
easily prevent such goofs.
Here are some sample pseudo-targets that are useful for lots of different things. Note that some macros are used that you'll have to define for yourself elsewhere:
all: usepix testpix toast pancake clean: -> rm -f $(OBJ) # More about this one in the section on makedepend... depend: -> makedepend $(CXXFLAGS) -Y $(SRC) # This is a neat way to make a compressed archive file for # saving or submitting your project. # Note that several commands go with this target; all will be # executed if you run gmake archive. archive: -> rm -rf project project.tar.gz -> mkdir project -> cp $(SUBMISSIONS) project -> tar -cf project.tar project -> gzip project.tar # This next one makes a printout of all your source code. # The $? means all dependencies newer than the target. # See the section on special macros PRINTCMD = enscript -2rG -pprintout.ps print: $(SOURCE) $(HEADERS) -> echo spooling $? to printer using $(PRINTCMD) -> $(PRINTCMD) $? -> print printout.ps -> rm printout.ps
Now all those $@
thingees that appear in the example above
and elsewhere in the makefile are clearly not plain old macros, since
they're never defined and yet this makefile works quite well, I
promise. The reason is that there are a number of special macros with
one character names that are only useable as part of a dependency
rule:
$@
The file name of the target.
$<
The name of the first dependency.
$*
The part of a filename which matched a suffix rule.
$?
The names of all the dependencies newer than the target separated by spaces.
$^
The names of all the dependencies separated by spaces, but with duplicate names removed.
$+
The names of all the dependencies separated by spaces with duplicate names included and in the same order as in the rule.
Some of these are only useful as part of suffix rules which are described in section Suffix rules.
Most of the commands you use to update files are similar; to build
most C++ programs, you call g++ with similar flags and really just
change the name of the file you're compiling. Make allows you to
define suffix rules so that you don't have to put command lines
underneath all your dependencies. For example, here is the built-in
suffix rule that gmake uses to compile a .cc
file into a .o
file:
COMPILE.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c OUTPUT_OPTION = -o $@ %.o: %.cc -> $(COMPILE.cc) $< $(OUTPUT_OPTION)
With suffix rules, you can leave out the command part of a dependency rule, for example:
usepix.o: usepix.cc usepix.h pixmap.h
If make decides to update usepix.o
, it sees from this line that
it depends on usepix.cc
, and it sees from the %.cc: %.o
rule
that to update it, it should run g++ using the flags defined in
CXXFLAGS
and to compile usepix.cc
.
Make has a number of built in suffix rules, which are roughly as follows:
COMPILE.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c COMPILE.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c LINK.o = $(CC) $(LDFLAGS) $(TARGET_ARCH) OUTPUT_OPTION = -o $@ %: %.o -> $(LINK.o) $^ $(LOADLIBES) $(LDLIBS) -o $@ %.o: %.c -> $(COMPILE.c) $< $(OUTPUT_OPTION) %.o: %.cc -> $(COMPILE.cc) $< $(OUTPUT_OPTION)
You can get the full list from the command gmake -p -f/dev/null/
.