Managing Projects with Make

Managing Projects with Make

by Andy Oram, Steve Talbott
3.0 1

Paperback(Second Edition)

$16.86 $19.95 Save 15% Current price is $16.86, Original price is $19.95. You Save 15%.

Temporarily Out of Stock Online

Eligible for FREE SHIPPING


Managing Projects with Make by 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 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.

Product Details

ISBN-13: 9780937175903
Publisher: O'Reilly Media, Incorporated
Publication date: 10/08/1991
Series: Nutshell Handbooks Series
Edition description: Second Edition
Pages: 168
Product dimensions: 5.94(w) x 9.16(h) x 0.41(d)

About 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.

Read an Excerpt

Chapter 3: Suffix Rules

Commands Supported by Default Suffix Rules

The 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.


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...

Table of Contents

The Value of make
Lessons from make
Scope of This Book
Getting Automated Tests

Chapter 1. How to Write a Simple Makefile
Dependency Checking
Minimizing Rebuilds
Invoking make
Basic Rules of Syntax

Chapter 2. Macros
Internally Defined Macros
Macro Definitions on the Command Line
Shell Variables
Priority of Macro Assignments
Macro String Substitution
Internal Macros for Prerequisites and Targets

Chapter 3. Suffix Rules
Command Options
Internal Macros
Commands Supported by Default Suffix Rules
Fortran and Pascal
Libraries (Archives)
Using Parentheses for Library Modules
A Library Example
Maintaining Libraries
The Double Colon
lex and yacc
The Null Suffix
How to Display Defaults
Generating the Display
What the Display Means
Writing Your Own Suffix Rules
A Sample Collection of Suffix Rules
Nullifying Rules
Conflicts With Default Suffixes

Chapter 4. Commands
Effects of Newlines on Commands
Errors and Exit Status
Which Shell?
Pathnames and Security

Chapter 5. Project Management
Recursive make on Directories
General Tips on Recursive make
Other Techniques for Multiple Directories
Directories in Internal Macros
Viewpath (VPATH Macro)
Compiler Options and #ifdef directives
Forcing Remakes
Maintaining Multiple Variants Through Explicit Targets
Maintaining Multiple Variants in Different Directories
Maintaining Variants Through Suffix Rules
Header Files
Global Definitions (include Statement)
Distributed Files and NFS Issues

Chapter 6. Command-line Usage and Special Targets
Status Information and Debugging
Errors and File Deletion
Miscellaneous Features Affecting Defaults

Chapter 7. Troubleshooting
Syntax Errors
Don't Know How to Make
Target Up to Date
Command Not Found, or Cannot Load
Syntax Errors in Multi-line Commands
Inconsistent Lines, or Too Many Lines
Unrecognized Macros
Default Rules Ignored

Appendix A. Quick Reference
Description File Lines
Internal Macros
Macro Modifiers
Macro String Substitution
Macros with Special Handling
Special Target Names

Appendix B. Popular Extensions
GNU make
Parallel and Distributed Implementations

Appendix C. Features That Differ Between Variants of make
List of Differences
Tests You Can Run
Macro String Substitution
File and Directory Macros
Parenthesis Syntax for Libraries
Single-suffix Rules and .sh Rules
Default Shell
include Statement

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews

Managing Projects with Make 3 out of 5 based on 0 ratings. 1 reviews.
Guest More than 1 year ago
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