Managing Projects with Makeby Andy Oram, Steve Talbott
make is one of UNIX's greatest contributions to software development, and this book is the clearest description of make ever written. Even the smallest software project typically involves a number of files that depend upon each other in various ways. If you modify one or more source files, you must relink the program after recompiling some, but not/i>/i>
make is one of UNIX's greatest contributions to software development, and this book is the clearest description of make ever written. Even the smallest software project typically involves a number of files that depend upon each other in various ways. If you modify one or more source files, you must relink the program after recompiling some, but not necessarily all, of the sources.make greatly simplifies this process. By recording the relationships between sets of files, make can automatically perform all the necessary updating.For large projects with teams of programmers and multiple releases, make becomes even more critical. But in order to avoid spending a major portion of your maintenance budget on maintaining the Makefiles, you need a system for handling directories, dependencies, and macro definitions. This book describes all the basic features of make and provides guidelines on meeting the needs of large, modern projects.Some of the issues addressed in the second edition include:
- Projects covering several directories.
- Maintaining consistency when building variants of a program.
- Automatic generation of header file dependencies.
- Forced rebuilds of existing files.
- A description of free products that contain major enhancements tomake.
- Listings of the features that vary between different versions of make and simple ways to test them.
- More detail and examples on common errors, use of the shell in make, formal rules of syntax in make, and support for various utilities.
Read an Excerpt
Chapter 3: Suffix Rules
Commands Supported by Default Suffix RulesThe rules built into make reflect the popular compilers and programming tools that were available on UNIX systems when make was developed. Luckily (for you as a novice make user, if not for the field of software engineering as a whole) the utilities and practices employed by C programmers have remained the same.
Thus, to build a o file, make starts by looking for a c file and, if one exists, runs it through the C compiler. Otherwise (focusing on just the C environment for a moment), make looks for a y file on which it can run yacc, and if that fails, a .1 file on which it can run lex.
When we look beyond C programming, the default rules have not stood up so well over time. That is why it's a good thing that you can redefine the rules, as described later in this chapter.
Fortran and Pascal
Fortran compilers have changed a great deal from the days of early UNIX systems. Some implementations have changed the default suffix rules to match the utilities on their systems, while others have not.
For instance, some implementations of make still look for fc as the compiler, instead of the modern f77. That is easy enough to fix by defining this in your shell environment or description file:
Most implementations still do not recognize the uppercase .F suffix (for Fortran files that pass through the C preprocessor). You can fix this by copying the .f rules, and adding .F to the .SUFFIXES list. (This procedure will be clear later, when we explain how to write your own suffix rules.)
$(FC) $(FFLAGS) -C $<
Meanwhile, the odds are good that your make recognizes r and e suffixes, which correspond to the obsolete Ratfor and EFL preprocessors that were used before the advent of Fortran 77. These rules do no harm, but they are strange relics, and it will be interesting to see when they finally disappear from released versions of make.
Pass options to the Fortran compiler through FFLAGS.
If your system offers a Pascal compiler, it almost certainly also offers the corresponding suffix rules in make. They probably look like this:
$ (PC) $ (PFLAGS) -c $<
Given, this rule, you can pass options to the Pascal compiler through PFLAGS.
SCCS and RCS
The most restrictive effects of outdated default rules can be found in make's limited support for SCCS (Source Code Control System). This utility keeps backup versions of source files to help project teams maintain multiple versions and recover from unwanted changes or accidental file corruption. While competing tools have emerged to perform this critical function, SCCS is still the most common on UNIX systems. RCS (Revision Control System, a free software product) is becoming a close contender.
In the view taken by make, a source control file is just another prerequisite in the chain of dependencies. For instance, if you are trying to build a o file and no source file exists, make tries to create a source file by searching for an SCCS file and then, if successful, executing a get command.
Support for SCCS had to be built into make in a different manner from other rules, because SCCS is unique in its naming conventions: it manages files by prefixes rather than suffixes. To maintain a backup version of a file, SCCS creates a new file consisting of the prefix s. followed by the filename. Thus, when you place a C language source file named filename.c under SCCS control, it creates a file with the name s.filename.c.
Unfortunately, two different interfaces to SCCS exist, one distributed by AT&T and one by U.C. Berkeley, but System V make works only with the older-and less popular-one. The AT&T interface is distinguished by keeping backup versions in the same directory as working source files. The Berkeley interface is a front-end to the AT&T one, and maintains the backup version of each working file in a subdirectory that has the name SCCS.
Do you want to mix source control and builds?
Nowadays, large team projects tend to keep source control separate from compilation and building. They find it easier to write separate tools invoking SCCS or RCS, and not to use the support within make at all. One reason is that source files are scattered among many directories, and the SCCS or RCS files reside on hub systems instead of with the programmers' working files. This makes it extremely hard for make to find the files during dependency checks.
A more fundamental reason for placing a wall between source control and the build process is that automatic updating may be undesirable. Imagine that you have gotten and changed some of your team's files in order to fix a bug. While editing and testing, you need a stable set of files; you do not want make to substitute a new version that someone else has placed into SCCS or RCS. The safe strategy is to prevent automatic updating by make, and to put the responsibility on the programmer for getting all the correct files before each build.
Certainly, you can create make entries to get and return files from the source control directories, just as you can use make for other general tasks. But when other people are sharing an SCCS or RCS tree with you, you should not let make update your source files automatically.
Automatic gets or check-outs can be very convenient if you are working on a project by yourself. So let us continue and see what make offers.
The tilde (~) convention
Suffix rules use tildes to identify SCCS files. For example, the default suffix rule,
.c~ .0 :
describes how to transform a C language source file under SCCS control into an object file. The first half (.c~) of the suffix pair represents a file of the form s.filename. c, from which make builds filename. c and filename. o. Thus, if we have a file s.filename.c in the current directory, the command
$ make filename.o results in the execution of these commands:
get -p s.filename.c > filename.c
cc -0 -c filename.c
rm -f filename.c
This special use of the tilde in make should not be confused with other conventional uses for a tilde, such as in backup versions of Emacs files or home...
Meet the Author
Andy Oram is an editor at O'Reilly & Associates, specializing in books on Linux and programming. Most recently, he edited Peer-to-Peer: Harnessing the Power of Disruptive Technologies.
Stephen L. Talbott went from Presidential Scholar to farmer, and from editing an interdisciplinary, scholarly journal about the catastrophist theories of Immanual Velikovsky, to fourteen years working in the computer industry. Mr. Talbott recently moved with his family from the Boston technology belt to rural New York, where his efforts to reach an accommodation with his computer continue.
Most Helpful Customer Reviews
See all customer reviews
It is not a bad book. Unfortunately many examples simply did not apply to any system I have access to. I did learn quite a bit but it is just out of date when compared to what is available