13636 lines
467 KiB
HTML
13636 lines
467 KiB
HTML
<HTML>
|
|
<HEAD>
|
|
<!-- This HTML file has been created by texi2html 1.54
|
|
from ../texi/make.texinfo on 19 July 2000 -->
|
|
|
|
<TITLE>GNU make</TITLE>
|
|
|
|
</HEAD>
|
|
<BODY>
|
|
<H1>GNU Make</H1>
|
|
<H2>A Program for Directing Recompilation</H2>
|
|
<H2>GNU <CODE>make</CODE> Version 3.79</H2>
|
|
<H2>April 2000</H2>
|
|
<ADDRESS>Richard M. Stallman and Roland McGrath</ADDRESS>
|
|
<P>
|
|
<P><HR><P>
|
|
<H1>Table of Contents</H1>
|
|
<UL>
|
|
<LI><A NAME="TOC1" HREF="make.html#SEC1">Overview of <CODE>make</CODE></A>
|
|
<UL>
|
|
<LI><A NAME="TOC2" HREF="make.html#SEC2">How to Read This Manual</A>
|
|
<LI><A NAME="TOC3" HREF="make.html#SEC3">Problems and Bugs</A>
|
|
</UL>
|
|
<LI><A NAME="TOC4" HREF="make.html#SEC4">An Introduction to Makefiles</A>
|
|
<UL>
|
|
<LI><A NAME="TOC5" HREF="make.html#SEC5">What a Rule Looks Like</A>
|
|
<LI><A NAME="TOC6" HREF="make.html#SEC6">A Simple Makefile</A>
|
|
<LI><A NAME="TOC7" HREF="make.html#SEC7">How <CODE>make</CODE> Processes a Makefile</A>
|
|
<LI><A NAME="TOC8" HREF="make.html#SEC8">Variables Make Makefiles Simpler</A>
|
|
<LI><A NAME="TOC9" HREF="make.html#SEC9">Letting <CODE>make</CODE> Deduce the Commands</A>
|
|
<LI><A NAME="TOC10" HREF="make.html#SEC10">Another Style of Makefile</A>
|
|
<LI><A NAME="TOC11" HREF="make.html#SEC11">Rules for Cleaning the Directory</A>
|
|
</UL>
|
|
<LI><A NAME="TOC12" HREF="make.html#SEC12">Writing Makefiles</A>
|
|
<UL>
|
|
<LI><A NAME="TOC13" HREF="make.html#SEC13">What Makefiles Contain</A>
|
|
<LI><A NAME="TOC14" HREF="make.html#SEC14">What Name to Give Your Makefile</A>
|
|
<LI><A NAME="TOC15" HREF="make.html#SEC15">Including Other Makefiles</A>
|
|
<LI><A NAME="TOC16" HREF="make.html#SEC16">The Variable <CODE>MAKEFILES</CODE></A>
|
|
<LI><A NAME="TOC17" HREF="make.html#SEC17">How Makefiles Are Remade</A>
|
|
<LI><A NAME="TOC18" HREF="make.html#SEC18">Overriding Part of Another Makefile</A>
|
|
<LI><A NAME="TOC19" HREF="make.html#SEC19">How <CODE>make</CODE> Reads a Makefile</A>
|
|
</UL>
|
|
<LI><A NAME="TOC20" HREF="make.html#SEC20">Writing Rules</A>
|
|
<UL>
|
|
<LI><A NAME="TOC21" HREF="make.html#SEC21">Rule Syntax</A>
|
|
<LI><A NAME="TOC22" HREF="make.html#SEC22">Using Wildcard Characters in File Names</A>
|
|
<UL>
|
|
<LI><A NAME="TOC23" HREF="make.html#SEC23">Wildcard Examples</A>
|
|
<LI><A NAME="TOC24" HREF="make.html#SEC24">Pitfalls of Using Wildcards</A>
|
|
<LI><A NAME="TOC25" HREF="make.html#SEC25">The Function <CODE>wildcard</CODE></A>
|
|
</UL>
|
|
<LI><A NAME="TOC26" HREF="make.html#SEC26">Searching Directories for Prerequisites</A>
|
|
<UL>
|
|
<LI><A NAME="TOC27" HREF="make.html#SEC27"><CODE>VPATH</CODE>: Search Path for All Prerequisites</A>
|
|
<LI><A NAME="TOC28" HREF="make.html#SEC28">The <CODE>vpath</CODE> Directive</A>
|
|
<LI><A NAME="TOC29" HREF="make.html#SEC29">How Directory Searches are Performed</A>
|
|
<LI><A NAME="TOC30" HREF="make.html#SEC30">Writing Shell Commands with Directory Search</A>
|
|
<LI><A NAME="TOC31" HREF="make.html#SEC31">Directory Search and Implicit Rules</A>
|
|
<LI><A NAME="TOC32" HREF="make.html#SEC32">Directory Search for Link Libraries</A>
|
|
</UL>
|
|
<LI><A NAME="TOC33" HREF="make.html#SEC33">Phony Targets</A>
|
|
<LI><A NAME="TOC34" HREF="make.html#SEC34">Rules without Commands or Prerequisites</A>
|
|
<LI><A NAME="TOC35" HREF="make.html#SEC35">Empty Target Files to Record Events</A>
|
|
<LI><A NAME="TOC36" HREF="make.html#SEC36">Special Built-in Target Names</A>
|
|
<LI><A NAME="TOC37" HREF="make.html#SEC37">Multiple Targets in a Rule</A>
|
|
<LI><A NAME="TOC38" HREF="make.html#SEC38">Multiple Rules for One Target</A>
|
|
<LI><A NAME="TOC39" HREF="make.html#SEC39">Static Pattern Rules</A>
|
|
<UL>
|
|
<LI><A NAME="TOC40" HREF="make.html#SEC40">Syntax of Static Pattern Rules</A>
|
|
<LI><A NAME="TOC41" HREF="make.html#SEC41">Static Pattern Rules versus Implicit Rules</A>
|
|
</UL>
|
|
<LI><A NAME="TOC42" HREF="make.html#SEC42">Double-Colon Rules</A>
|
|
<LI><A NAME="TOC43" HREF="make.html#SEC43">Generating Prerequisites Automatically</A>
|
|
</UL>
|
|
<LI><A NAME="TOC44" HREF="make.html#SEC44">Writing the Commands in Rules</A>
|
|
<UL>
|
|
<LI><A NAME="TOC45" HREF="make.html#SEC45">Command Echoing</A>
|
|
<LI><A NAME="TOC46" HREF="make.html#SEC46">Command Execution</A>
|
|
<LI><A NAME="TOC47" HREF="make.html#SEC47">Parallel Execution</A>
|
|
<LI><A NAME="TOC48" HREF="make.html#SEC48">Errors in Commands</A>
|
|
<LI><A NAME="TOC49" HREF="make.html#SEC49">Interrupting or Killing <CODE>make</CODE></A>
|
|
<LI><A NAME="TOC50" HREF="make.html#SEC50">Recursive Use of <CODE>make</CODE></A>
|
|
<UL>
|
|
<LI><A NAME="TOC51" HREF="make.html#SEC51">How the <CODE>MAKE</CODE> Variable Works</A>
|
|
<LI><A NAME="TOC52" HREF="make.html#SEC52">Communicating Variables to a Sub-<CODE>make</CODE></A>
|
|
<LI><A NAME="TOC53" HREF="make.html#SEC53">Communicating Options to a Sub-<CODE>make</CODE></A>
|
|
<LI><A NAME="TOC54" HREF="make.html#SEC54">The <SAMP>`--print-directory'</SAMP> Option</A>
|
|
</UL>
|
|
<LI><A NAME="TOC55" HREF="make.html#SEC55">Defining Canned Command Sequences</A>
|
|
<LI><A NAME="TOC56" HREF="make.html#SEC56">Using Empty Commands</A>
|
|
</UL>
|
|
<LI><A NAME="TOC57" HREF="make.html#SEC57">How to Use Variables</A>
|
|
<UL>
|
|
<LI><A NAME="TOC58" HREF="make.html#SEC58">Basics of Variable References</A>
|
|
<LI><A NAME="TOC59" HREF="make.html#SEC59">The Two Flavors of Variables</A>
|
|
<LI><A NAME="TOC60" HREF="make.html#SEC60">Advanced Features for Reference to Variables</A>
|
|
<UL>
|
|
<LI><A NAME="TOC61" HREF="make.html#SEC61">Substitution References</A>
|
|
<LI><A NAME="TOC62" HREF="make.html#SEC62">Computed Variable Names</A>
|
|
</UL>
|
|
<LI><A NAME="TOC63" HREF="make.html#SEC63">How Variables Get Their Values</A>
|
|
<LI><A NAME="TOC64" HREF="make.html#SEC64">Setting Variables</A>
|
|
<LI><A NAME="TOC65" HREF="make.html#SEC65">Appending More Text to Variables</A>
|
|
<LI><A NAME="TOC66" HREF="make.html#SEC66">The <CODE>override</CODE> Directive</A>
|
|
<LI><A NAME="TOC67" HREF="make.html#SEC67">Defining Variables Verbatim</A>
|
|
<LI><A NAME="TOC68" HREF="make.html#SEC68">Variables from the Environment</A>
|
|
<LI><A NAME="TOC69" HREF="make.html#SEC69">Target-specific Variable Values</A>
|
|
<LI><A NAME="TOC70" HREF="make.html#SEC70">Pattern-specific Variable Values</A>
|
|
</UL>
|
|
<LI><A NAME="TOC71" HREF="make.html#SEC71">Conditional Parts of Makefiles</A>
|
|
<UL>
|
|
<LI><A NAME="TOC72" HREF="make.html#SEC72">Example of a Conditional</A>
|
|
<LI><A NAME="TOC73" HREF="make.html#SEC73">Syntax of Conditionals</A>
|
|
<LI><A NAME="TOC74" HREF="make.html#SEC74">Conditionals that Test Flags</A>
|
|
</UL>
|
|
<LI><A NAME="TOC75" HREF="make.html#SEC75">Functions for Transforming Text</A>
|
|
<UL>
|
|
<LI><A NAME="TOC76" HREF="make.html#SEC76">Function Call Syntax</A>
|
|
<LI><A NAME="TOC77" HREF="make.html#SEC77">Functions for String Substitution and Analysis</A>
|
|
<LI><A NAME="TOC78" HREF="make.html#SEC78">Functions for File Names</A>
|
|
<LI><A NAME="TOC79" HREF="make.html#SEC79">The <CODE>foreach</CODE> Function</A>
|
|
<LI><A NAME="TOC80" HREF="make.html#SEC80">The <CODE>if</CODE> Function</A>
|
|
<LI><A NAME="TOC81" HREF="make.html#SEC81">The <CODE>call</CODE> Function</A>
|
|
<LI><A NAME="TOC82" HREF="make.html#SEC82">The <CODE>origin</CODE> Function</A>
|
|
<LI><A NAME="TOC83" HREF="make.html#SEC83">The <CODE>shell</CODE> Function</A>
|
|
<LI><A NAME="TOC84" HREF="make.html#SEC84">Functions That Control Make</A>
|
|
</UL>
|
|
<LI><A NAME="TOC85" HREF="make.html#SEC85">How to Run <CODE>make</CODE></A>
|
|
<UL>
|
|
<LI><A NAME="TOC86" HREF="make.html#SEC86">Arguments to Specify the Makefile</A>
|
|
<LI><A NAME="TOC87" HREF="make.html#SEC87">Arguments to Specify the Goals</A>
|
|
<LI><A NAME="TOC88" HREF="make.html#SEC88">Instead of Executing the Commands</A>
|
|
<LI><A NAME="TOC89" HREF="make.html#SEC89">Avoiding Recompilation of Some Files</A>
|
|
<LI><A NAME="TOC90" HREF="make.html#SEC90">Overriding Variables</A>
|
|
<LI><A NAME="TOC91" HREF="make.html#SEC91">Testing the Compilation of a Program</A>
|
|
<LI><A NAME="TOC92" HREF="make.html#SEC92">Summary of Options</A>
|
|
</UL>
|
|
<LI><A NAME="TOC93" HREF="make.html#SEC93">Using Implicit Rules</A>
|
|
<UL>
|
|
<LI><A NAME="TOC94" HREF="make.html#SEC94">Using Implicit Rules</A>
|
|
<LI><A NAME="TOC95" HREF="make.html#SEC95">Catalogue of Implicit Rules</A>
|
|
<LI><A NAME="TOC96" HREF="make.html#SEC96">Variables Used by Implicit Rules</A>
|
|
<LI><A NAME="TOC97" HREF="make.html#SEC97">Chains of Implicit Rules</A>
|
|
<LI><A NAME="TOC98" HREF="make.html#SEC98">Defining and Redefining Pattern Rules</A>
|
|
<UL>
|
|
<LI><A NAME="TOC99" HREF="make.html#SEC99">Introduction to Pattern Rules</A>
|
|
<LI><A NAME="TOC100" HREF="make.html#SEC100">Pattern Rule Examples</A>
|
|
<LI><A NAME="TOC101" HREF="make.html#SEC101">Automatic Variables</A>
|
|
<LI><A NAME="TOC102" HREF="make.html#SEC102">How Patterns Match</A>
|
|
<LI><A NAME="TOC103" HREF="make.html#SEC103">Match-Anything Pattern Rules</A>
|
|
<LI><A NAME="TOC104" HREF="make.html#SEC104">Canceling Implicit Rules</A>
|
|
</UL>
|
|
<LI><A NAME="TOC105" HREF="make.html#SEC105">Defining Last-Resort Default Rules</A>
|
|
<LI><A NAME="TOC106" HREF="make.html#SEC106">Old-Fashioned Suffix Rules</A>
|
|
<LI><A NAME="TOC107" HREF="make.html#SEC107">Implicit Rule Search Algorithm</A>
|
|
</UL>
|
|
<LI><A NAME="TOC108" HREF="make.html#SEC108">Using <CODE>make</CODE> to Update Archive Files</A>
|
|
<UL>
|
|
<LI><A NAME="TOC109" HREF="make.html#SEC109">Archive Members as Targets</A>
|
|
<LI><A NAME="TOC110" HREF="make.html#SEC110">Implicit Rule for Archive Member Targets</A>
|
|
<UL>
|
|
<LI><A NAME="TOC111" HREF="make.html#SEC111">Updating Archive Symbol Directories</A>
|
|
</UL>
|
|
<LI><A NAME="TOC112" HREF="make.html#SEC112">Dangers When Using Archives</A>
|
|
<LI><A NAME="TOC113" HREF="make.html#SEC113">Suffix Rules for Archive Files</A>
|
|
</UL>
|
|
<LI><A NAME="TOC114" HREF="make.html#SEC114">Features of GNU <CODE>make</CODE></A>
|
|
<LI><A NAME="TOC115" HREF="make.html#SEC115">Incompatibilities and Missing Features</A>
|
|
<LI><A NAME="TOC116" HREF="make.html#SEC116">Makefile Conventions</A>
|
|
<UL>
|
|
<LI><A NAME="TOC117" HREF="make.html#SEC117">General Conventions for Makefiles</A>
|
|
<LI><A NAME="TOC118" HREF="make.html#SEC118">Utilities in Makefiles</A>
|
|
<LI><A NAME="TOC119" HREF="make.html#SEC119">Variables for Specifying Commands</A>
|
|
<LI><A NAME="TOC120" HREF="make.html#SEC120">Variables for Installation Directories</A>
|
|
<LI><A NAME="TOC121" HREF="make.html#SEC121">Standard Targets for Users</A>
|
|
<LI><A NAME="TOC122" HREF="make.html#SEC122">Install Command Categories</A>
|
|
</UL>
|
|
<LI><A NAME="TOC123" HREF="make.html#SEC123">Quick Reference</A>
|
|
<LI><A NAME="TOC124" HREF="make.html#SEC124">Errors Generated by Make</A>
|
|
<LI><A NAME="TOC125" HREF="make.html#SEC125">Complex Makefile Example</A>
|
|
<LI><A NAME="TOC126" HREF="make.html#SEC126">Index of Concepts</A>
|
|
<LI><A NAME="TOC127" HREF="make.html#SEC127">Index of Functions, Variables, & Directives</A>
|
|
</UL>
|
|
<P><HR><P>
|
|
|
|
|
|
<H1><A NAME="SEC1" HREF="make.html#TOC1">Overview of <CODE>make</CODE></A></H1>
|
|
|
|
<P>
|
|
The <CODE>make</CODE> utility automatically determines which pieces of a large
|
|
program need to be recompiled, and issues commands to recompile them.
|
|
This manual describes GNU <CODE>make</CODE>, which was implemented by Richard
|
|
Stallman and Roland McGrath. Development since Version 3.76 has been
|
|
handled by Paul D. Smith.
|
|
|
|
</P>
|
|
<P>
|
|
GNU <CODE>make</CODE> conforms to section 6.2 of <CITE>IEEE Standard
|
|
1003.2-1992</CITE> (POSIX.2).
|
|
<A NAME="IDX1"></A>
|
|
<A NAME="IDX2"></A>
|
|
<A NAME="IDX3"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Our examples show C programs, since they are most common, but you can use
|
|
<CODE>make</CODE> with any programming language whose compiler can be run with a
|
|
shell command. Indeed, <CODE>make</CODE> is not limited to programs. You can
|
|
use it to describe any task where some files must be updated automatically
|
|
from others whenever the others change.
|
|
|
|
</P>
|
|
|
|
<P>
|
|
To prepare to use <CODE>make</CODE>, you must write a file called
|
|
the <STRONG>makefile</STRONG> that describes the relationships among files
|
|
in your program and provides commands for updating each file.
|
|
In a program, typically, the executable file is updated from object
|
|
files, which are in turn made by compiling source files.
|
|
</P>
|
|
<P>
|
|
Once a suitable makefile exists, each time you change some source files,
|
|
this simple shell command:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
make
|
|
</PRE>
|
|
|
|
<P>
|
|
suffices to perform all necessary recompilations. The <CODE>make</CODE> program
|
|
uses the makefile data base and the last-modification times of the files to
|
|
decide which of the files need to be updated. For each of those files, it
|
|
issues the commands recorded in the data base.
|
|
|
|
</P>
|
|
<P>
|
|
You can provide command line arguments to <CODE>make</CODE> to control which
|
|
files should be recompiled, or how. See section <A HREF="make.html#SEC85">How to Run <CODE>make</CODE></A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC2" HREF="make.html#TOC2">How to Read This Manual</A></H2>
|
|
|
|
<P>
|
|
If you are new to <CODE>make</CODE>, or are looking for a general
|
|
introduction, read the first few sections of each chapter, skipping the
|
|
later sections. In each chapter, the first few sections contain
|
|
introductory or general information and the later sections contain
|
|
specialized or technical information.
|
|
The exception is section <A HREF="make.html#SEC4">An Introduction to Makefiles</A>,
|
|
all of which is introductory.
|
|
|
|
</P>
|
|
<P>
|
|
If you are familiar with other <CODE>make</CODE> programs, see section <A HREF="make.html#SEC114">Features of GNU <CODE>make</CODE></A>, which lists the enhancements GNU
|
|
<CODE>make</CODE> has, and section <A HREF="make.html#SEC115">Incompatibilities and Missing Features</A>, which explains the few things GNU <CODE>make</CODE> lacks that
|
|
others have.
|
|
|
|
</P>
|
|
<P>
|
|
For a quick summary, see section <A HREF="make.html#SEC92">Summary of Options</A>, section <A HREF="make.html#SEC123">Quick Reference</A>,
|
|
and section <A HREF="make.html#SEC36">Special Built-in Target Names</A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC3" HREF="make.html#TOC3">Problems and Bugs</A></H2>
|
|
<P>
|
|
<A NAME="IDX4"></A>
|
|
<A NAME="IDX5"></A>
|
|
<A NAME="IDX6"></A>
|
|
|
|
</P>
|
|
<P>
|
|
If you have problems with GNU <CODE>make</CODE> or think you've found a bug,
|
|
please report it to the developers; we cannot promise to do anything but
|
|
we might well want to fix it.
|
|
|
|
</P>
|
|
<P>
|
|
Before reporting a bug, make sure you've actually found a real bug.
|
|
Carefully reread the documentation and see if it really says you can do
|
|
what you're trying to do. If it's not clear whether you should be able
|
|
to do something or not, report that too; it's a bug in the
|
|
documentation!
|
|
|
|
</P>
|
|
<P>
|
|
Before reporting a bug or trying to fix it yourself, try to isolate it
|
|
to the smallest possible makefile that reproduces the problem. Then
|
|
send us the makefile and the exact results <CODE>make</CODE> gave you. Also
|
|
say what you expected to occur; this will help us decide whether the
|
|
problem was really in the documentation.
|
|
|
|
</P>
|
|
<P>
|
|
Once you've got a precise problem, please send electronic mail to:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
bug-make@gnu.org
|
|
</PRE>
|
|
|
|
<P>
|
|
Please include the version number of <CODE>make</CODE> you are using. You can
|
|
get this information with the command <SAMP>`make --version'</SAMP>.
|
|
Be sure also to include the type of machine and operating system you are
|
|
using. If possible, include the contents of the file <TT>`config.h'</TT>
|
|
that is generated by the configuration process.
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC4" HREF="make.html#TOC4">An Introduction to Makefiles</A></H1>
|
|
|
|
<P>
|
|
You need a file called a <STRONG>makefile</STRONG> to tell <CODE>make</CODE> what to do.
|
|
Most often, the makefile tells <CODE>make</CODE> how to compile and link a
|
|
program.
|
|
<A NAME="IDX7"></A>
|
|
|
|
</P>
|
|
<P>
|
|
In this chapter, we will discuss a simple makefile that describes how to
|
|
compile and link a text editor which consists of eight C source files
|
|
and three header files. The makefile can also tell <CODE>make</CODE> how to
|
|
run miscellaneous commands when explicitly asked (for example, to remove
|
|
certain files as a clean-up operation). To see a more complex example
|
|
of a makefile, see section <A HREF="make.html#SEC125">Complex Makefile Example</A>.
|
|
|
|
</P>
|
|
<P>
|
|
When <CODE>make</CODE> recompiles the editor, each changed C source file
|
|
must be recompiled. If a header file has changed, each C source file
|
|
that includes the header file must be recompiled to be safe. Each
|
|
compilation produces an object file corresponding to the source file.
|
|
Finally, if any source file has been recompiled, all the object files,
|
|
whether newly made or saved from previous compilations, must be linked
|
|
together to produce the new executable editor.
|
|
<A NAME="IDX8"></A>
|
|
<A NAME="IDX9"></A>
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC5" HREF="make.html#TOC5">What a Rule Looks Like</A></H2>
|
|
<P>
|
|
<A NAME="IDX10"></A>
|
|
<A NAME="IDX11"></A>
|
|
<A NAME="IDX12"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A simple makefile consists of "rules" with the following shape:
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX13"></A>
|
|
<A NAME="IDX14"></A>
|
|
<A NAME="IDX15"></A>
|
|
|
|
<PRE>
|
|
<VAR>target</VAR> ... : <VAR>prerequisites</VAR> ...
|
|
<VAR>command</VAR>
|
|
...
|
|
...
|
|
</PRE>
|
|
|
|
<P>
|
|
A <STRONG>target</STRONG> is usually the name of a file that is generated by a
|
|
program; examples of targets are executable or object files. A target
|
|
can also be the name of an action to carry out, such as <SAMP>`clean'</SAMP>
|
|
(see section <A HREF="make.html#SEC33">Phony Targets</A>).
|
|
|
|
</P>
|
|
<P>
|
|
A <STRONG>prerequisite</STRONG> is a file that is used as input to create the
|
|
target. A target often depends on several files.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX16"></A>
|
|
A <STRONG>command</STRONG> is an action that <CODE>make</CODE> carries out.
|
|
A rule may have more than one command, each on its own line.
|
|
<STRONG>Please note:</STRONG> you need to put a tab character at the beginning of
|
|
every command line! This is an obscurity that catches the unwary.
|
|
|
|
</P>
|
|
<P>
|
|
Usually a command is in a rule with prerequisites and serves to create a
|
|
target file if any of the prerequisites change. However, the rule that
|
|
specifies commands for the target need not have prerequisites. For
|
|
example, the rule containing the delete command associated with the
|
|
target <SAMP>`clean'</SAMP> does not have prerequisites.
|
|
|
|
</P>
|
|
<P>
|
|
A <STRONG>rule</STRONG>, then, explains how and when to remake certain files
|
|
which are the targets of the particular rule. <CODE>make</CODE> carries out
|
|
the commands on the prerequisites to create or update the target. A
|
|
rule can also explain how and when to carry out an action.
|
|
See section <A HREF="make.html#SEC20">Writing Rules</A>.
|
|
|
|
</P>
|
|
<P>
|
|
A makefile may contain other text besides rules, but a simple makefile
|
|
need only contain rules. Rules may look somewhat more complicated
|
|
than shown in this template, but all fit the pattern more or less.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC6" HREF="make.html#TOC6">A Simple Makefile</A></H2>
|
|
<P>
|
|
<A NAME="IDX17"></A>
|
|
<A NAME="IDX18"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Here is a straightforward makefile that describes the way an
|
|
executable file called <CODE>edit</CODE> depends on eight object files
|
|
which, in turn, depend on eight C source and three header files.
|
|
|
|
</P>
|
|
<P>
|
|
In this example, all the C files include <TT>`defs.h'</TT>, but only those
|
|
defining editing commands include <TT>`command.h'</TT>, and only low
|
|
level files that change the editor buffer include <TT>`buffer.h'</TT>.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
edit : main.o kbd.o command.o display.o \
|
|
insert.o search.o files.o utils.o
|
|
cc -o edit main.o kbd.o command.o display.o \
|
|
insert.o search.o files.o utils.o
|
|
|
|
main.o : main.c defs.h
|
|
cc -c main.c
|
|
kbd.o : kbd.c defs.h command.h
|
|
cc -c kbd.c
|
|
command.o : command.c defs.h command.h
|
|
cc -c command.c
|
|
display.o : display.c defs.h buffer.h
|
|
cc -c display.c
|
|
insert.o : insert.c defs.h buffer.h
|
|
cc -c insert.c
|
|
search.o : search.c defs.h buffer.h
|
|
cc -c search.c
|
|
files.o : files.c defs.h buffer.h command.h
|
|
cc -c files.c
|
|
utils.o : utils.c defs.h
|
|
cc -c utils.c
|
|
clean :
|
|
rm edit main.o kbd.o command.o display.o \
|
|
insert.o search.o files.o utils.o
|
|
</PRE>
|
|
|
|
<P>
|
|
We split each long line into two lines using backslash-newline; this is
|
|
like using one long line, but is easier to read.
|
|
<A NAME="IDX19"></A>
|
|
<A NAME="IDX20"></A>
|
|
<A NAME="IDX21"></A>
|
|
<A NAME="IDX22"></A>
|
|
<A NAME="IDX23"></A>
|
|
|
|
</P>
|
|
<P>
|
|
To use this makefile to create the executable file called <TT>`edit'</TT>,
|
|
type:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
make
|
|
</PRE>
|
|
|
|
<P>
|
|
To use this makefile to delete the executable file and all the object
|
|
files from the directory, type:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
make clean
|
|
</PRE>
|
|
|
|
<P>
|
|
In the example makefile, the targets include the executable file
|
|
<SAMP>`edit'</SAMP>, and the object files <SAMP>`main.o'</SAMP> and <SAMP>`kbd.o'</SAMP>. The
|
|
prerequisites are files such as <SAMP>`main.c'</SAMP> and <SAMP>`defs.h'</SAMP>.
|
|
In fact, each <SAMP>`.o'</SAMP> file is both a target and a prerequisite.
|
|
Commands include <SAMP>`cc -c main.c'</SAMP> and <SAMP>`cc -c kbd.c'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
When a target is a file, it needs to be recompiled or relinked if any
|
|
of its prerequisites change. In addition, any prerequisites that are
|
|
themselves automatically generated should be updated first. In this
|
|
example, <TT>`edit'</TT> depends on each of the eight object files; the
|
|
object file <TT>`main.o'</TT> depends on the source file <TT>`main.c'</TT> and
|
|
on the header file <TT>`defs.h'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
A shell command follows each line that contains a target and
|
|
prerequisites. These shell commands say how to update the target file.
|
|
A tab character must come at the beginning of every command line to
|
|
distinguish commands lines from other lines in the makefile. (Bear in
|
|
mind that <CODE>make</CODE> does not know anything about how the commands
|
|
work. It is up to you to supply commands that will update the target
|
|
file properly. All <CODE>make</CODE> does is execute the commands in the rule
|
|
you have specified when the target file needs to be updated.)
|
|
<A NAME="IDX24"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The target <SAMP>`clean'</SAMP> is not a file, but merely the name of an
|
|
action. Since you
|
|
normally
|
|
do not want to carry out the actions in this rule, <SAMP>`clean'</SAMP> is not a prerequisite of any other rule.
|
|
Consequently, <CODE>make</CODE> never does anything with it unless you tell
|
|
it specifically. Note that this rule not only is not a prerequisite, it
|
|
also does not have any prerequisites, so the only purpose of the rule
|
|
is to run the specified commands. Targets that do not refer to files
|
|
but are just actions are called <STRONG>phony targets</STRONG>. See section <A HREF="make.html#SEC33">Phony Targets</A>, for information about this kind of target. See section <A HREF="make.html#SEC48">Errors in Commands</A>, to see how to cause <CODE>make</CODE> to ignore errors
|
|
from <CODE>rm</CODE> or any other command.
|
|
<A NAME="IDX25"></A>
|
|
<A NAME="IDX26"></A>
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC7" HREF="make.html#TOC7">How <CODE>make</CODE> Processes a Makefile</A></H2>
|
|
<P>
|
|
<A NAME="IDX27"></A>
|
|
<A NAME="IDX28"></A>
|
|
|
|
</P>
|
|
<P>
|
|
By default, <CODE>make</CODE> starts with the first target (not targets whose
|
|
names start with <SAMP>`.'</SAMP>). This is called the <STRONG>default goal</STRONG>.
|
|
(<STRONG>Goals</STRONG> are the targets that <CODE>make</CODE> strives ultimately to
|
|
update. See section <A HREF="make.html#SEC87">Arguments to Specify the Goals</A>.)
|
|
<A NAME="IDX29"></A>
|
|
<A NAME="IDX30"></A>
|
|
<A NAME="IDX31"></A>
|
|
|
|
</P>
|
|
<P>
|
|
In the simple example of the previous section, the default goal is to
|
|
update the executable program <TT>`edit'</TT>; therefore, we put that rule
|
|
first.
|
|
|
|
</P>
|
|
<P>
|
|
Thus, when you give the command:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
make
|
|
</PRE>
|
|
|
|
<P>
|
|
<CODE>make</CODE> reads the makefile in the current directory and begins by
|
|
processing the first rule. In the example, this rule is for relinking
|
|
<TT>`edit'</TT>; but before <CODE>make</CODE> can fully process this rule, it
|
|
must process the rules for the files that <TT>`edit'</TT> depends on,
|
|
which in this case are the object files. Each of these files is
|
|
processed according to its own rule. These rules say to update each
|
|
<SAMP>`.o'</SAMP> file by compiling its source file. The recompilation must
|
|
be done if the source file, or any of the header files named as
|
|
prerequisites, is more recent than the object file, or if the object
|
|
file does not exist.
|
|
|
|
</P>
|
|
<P>
|
|
The other rules are processed because their targets appear as
|
|
prerequisites of the goal. If some other rule is not depended on by the
|
|
goal (or anything it depends on, etc.), that rule is not processed,
|
|
unless you tell <CODE>make</CODE> to do so (with a command such as
|
|
<CODE>make clean</CODE>).
|
|
|
|
</P>
|
|
<P>
|
|
Before recompiling an object file, <CODE>make</CODE> considers updating its
|
|
prerequisites, the source file and header files. This makefile does not
|
|
specify anything to be done for them--the <SAMP>`.c'</SAMP> and <SAMP>`.h'</SAMP> files
|
|
are not the targets of any rules--so <CODE>make</CODE> does nothing for these
|
|
files. But <CODE>make</CODE> would update automatically generated C programs,
|
|
such as those made by Bison or Yacc, by their own rules at this time.
|
|
|
|
</P>
|
|
<P>
|
|
After recompiling whichever object files need it, <CODE>make</CODE> decides
|
|
whether to relink <TT>`edit'</TT>. This must be done if the file
|
|
<TT>`edit'</TT> does not exist, or if any of the object files are newer than
|
|
it. If an object file was just recompiled, it is now newer than
|
|
<TT>`edit'</TT>, so <TT>`edit'</TT> is relinked.
|
|
<A NAME="IDX32"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Thus, if we change the file <TT>`insert.c'</TT> and run <CODE>make</CODE>,
|
|
<CODE>make</CODE> will compile that file to update <TT>`insert.o'</TT>, and then
|
|
link <TT>`edit'</TT>. If we change the file <TT>`command.h'</TT> and run
|
|
<CODE>make</CODE>, <CODE>make</CODE> will recompile the object files <TT>`kbd.o'</TT>,
|
|
<TT>`command.o'</TT> and <TT>`files.o'</TT> and then link the file <TT>`edit'</TT>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC8" HREF="make.html#TOC8">Variables Make Makefiles Simpler</A></H2>
|
|
<P>
|
|
<A NAME="IDX33"></A>
|
|
<A NAME="IDX34"></A>
|
|
|
|
</P>
|
|
<P>
|
|
In our example, we had to list all the object files twice in the rule for
|
|
<TT>`edit'</TT> (repeated here):
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
edit : main.o kbd.o command.o display.o \
|
|
insert.o search.o files.o utils.o
|
|
cc -o edit main.o kbd.o command.o display.o \
|
|
insert.o search.o files.o utils.o
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX35"></A>
|
|
Such duplication is error-prone; if a new object file is added to the
|
|
system, we might add it to one list and forget the other. We can eliminate
|
|
the risk and simplify the makefile by using a variable. <STRONG>Variables</STRONG>
|
|
allow a text string to be defined once and substituted in multiple places
|
|
later (see section <A HREF="make.html#SEC57">How to Use Variables</A>).
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX36"></A>
|
|
<A NAME="IDX37"></A>
|
|
<A NAME="IDX38"></A>
|
|
<A NAME="IDX39"></A>
|
|
<A NAME="IDX40"></A>
|
|
It is standard practice for every makefile to have a variable named
|
|
<CODE>objects</CODE>, <CODE>OBJECTS</CODE>, <CODE>objs</CODE>, <CODE>OBJS</CODE>, <CODE>obj</CODE>,
|
|
or <CODE>OBJ</CODE> which is a list of all object file names. We would
|
|
define such a variable <CODE>objects</CODE> with a line like this in the
|
|
makefile:
|
|
</P>
|
|
|
|
<PRE>
|
|
objects = main.o kbd.o command.o display.o \
|
|
insert.o search.o files.o utils.o
|
|
</PRE>
|
|
|
|
<P>
|
|
Then, each place we want to put a list of the object file names, we can
|
|
substitute the variable's value by writing <SAMP>`$(objects)'</SAMP>
|
|
(see section <A HREF="make.html#SEC57">How to Use Variables</A>).
|
|
|
|
</P>
|
|
<P>
|
|
Here is how the complete simple makefile looks when you use a variable
|
|
for the object files:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects = main.o kbd.o command.o display.o \
|
|
insert.o search.o files.o utils.o
|
|
|
|
edit : $(objects)
|
|
cc -o edit $(objects)
|
|
main.o : main.c defs.h
|
|
cc -c main.c
|
|
kbd.o : kbd.c defs.h command.h
|
|
cc -c kbd.c
|
|
command.o : command.c defs.h command.h
|
|
cc -c command.c
|
|
display.o : display.c defs.h buffer.h
|
|
cc -c display.c
|
|
insert.o : insert.c defs.h buffer.h
|
|
cc -c insert.c
|
|
search.o : search.c defs.h buffer.h
|
|
cc -c search.c
|
|
files.o : files.c defs.h buffer.h command.h
|
|
cc -c files.c
|
|
utils.o : utils.c defs.h
|
|
cc -c utils.c
|
|
clean :
|
|
rm edit $(objects)
|
|
</PRE>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC9" HREF="make.html#TOC9">Letting <CODE>make</CODE> Deduce the Commands</A></H2>
|
|
<P>
|
|
<A NAME="IDX41"></A>
|
|
<A NAME="IDX42"></A>
|
|
<A NAME="IDX43"></A>
|
|
|
|
</P>
|
|
<P>
|
|
It is not necessary to spell out the commands for compiling the individual
|
|
C source files, because <CODE>make</CODE> can figure them out: it has an
|
|
<STRONG>implicit rule</STRONG> for updating a <SAMP>`.o'</SAMP> file from a correspondingly
|
|
named <SAMP>`.c'</SAMP> file using a <SAMP>`cc -c'</SAMP> command. For example, it will
|
|
use the command <SAMP>`cc -c main.c -o main.o'</SAMP> to compile <TT>`main.c'</TT> into
|
|
<TT>`main.o'</TT>. We can therefore omit the commands from the rules for the
|
|
object files. See section <A HREF="make.html#SEC93">Using Implicit Rules</A>.
|
|
</P>
|
|
<P>
|
|
When a <SAMP>`.c'</SAMP> file is used automatically in this way, it is also
|
|
automatically added to the list of prerequisites. We can therefore omit
|
|
the <SAMP>`.c'</SAMP> files from the prerequisites, provided we omit the commands.
|
|
|
|
</P>
|
|
<P>
|
|
Here is the entire example, with both of these changes, and a variable
|
|
<CODE>objects</CODE> as suggested above:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects = main.o kbd.o command.o display.o \
|
|
insert.o search.o files.o utils.o
|
|
|
|
edit : $(objects)
|
|
cc -o edit $(objects)
|
|
|
|
main.o : defs.h
|
|
kbd.o : defs.h command.h
|
|
command.o : defs.h command.h
|
|
display.o : defs.h buffer.h
|
|
insert.o : defs.h buffer.h
|
|
search.o : defs.h buffer.h
|
|
files.o : defs.h buffer.h command.h
|
|
utils.o : defs.h
|
|
|
|
.PHONY : clean
|
|
clean :
|
|
-rm edit $(objects)
|
|
</PRE>
|
|
|
|
<P>
|
|
This is how we would write the makefile in actual practice. (The
|
|
complications associated with <SAMP>`clean'</SAMP> are described elsewhere.
|
|
See section <A HREF="make.html#SEC33">Phony Targets</A>, and section <A HREF="make.html#SEC48">Errors in Commands</A>.)
|
|
|
|
</P>
|
|
<P>
|
|
Because implicit rules are so convenient, they are important. You
|
|
will see them used frequently.
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC10" HREF="make.html#TOC10">Another Style of Makefile</A></H2>
|
|
<P>
|
|
<A NAME="IDX44"></A>
|
|
|
|
</P>
|
|
<P>
|
|
When the objects of a makefile are created only by implicit rules, an
|
|
alternative 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:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects = main.o kbd.o command.o display.o \
|
|
insert.o search.o files.o utils.o
|
|
|
|
edit : $(objects)
|
|
cc -o edit $(objects)
|
|
|
|
$(objects) : defs.h
|
|
kbd.o command.o files.o : command.h
|
|
display.o insert.o search.o files.o : buffer.h
|
|
</PRE>
|
|
|
|
<P>
|
|
Here <TT>`defs.h'</TT> is given as a prerequisite of all the object files;
|
|
<TT>`command.h'</TT> and <TT>`buffer.h'</TT> are prerequisites of the specific
|
|
object files listed for them.
|
|
|
|
</P>
|
|
<P>
|
|
Whether this is better is a matter of taste: it is more compact, but some
|
|
people dislike it because they find it clearer to put all the information
|
|
about each target in one place.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC11" HREF="make.html#TOC11">Rules for Cleaning the Directory</A></H2>
|
|
<P>
|
|
<A NAME="IDX45"></A>
|
|
<A NAME="IDX46"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Compiling a program is not the only thing you might want to write rules
|
|
for. Makefiles commonly tell how to do a few other things besides
|
|
compiling a program: for example, how to delete all the object files
|
|
and executables so that the directory is <SAMP>`clean'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX47"></A>
|
|
Here is how we
|
|
could write a <CODE>make</CODE> rule for cleaning our example editor:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
clean:
|
|
rm edit $(objects)
|
|
</PRE>
|
|
|
|
<P>
|
|
In practice, we might want to write the rule in a somewhat more
|
|
complicated manner to handle unanticipated situations. We would do this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
.PHONY : clean
|
|
clean :
|
|
-rm edit $(objects)
|
|
</PRE>
|
|
|
|
<P>
|
|
This prevents <CODE>make</CODE> from getting confused by an actual file
|
|
called <TT>`clean'</TT> and causes it to continue in spite of errors from
|
|
<CODE>rm</CODE>. (See section <A HREF="make.html#SEC33">Phony Targets</A>, and section <A HREF="make.html#SEC48">Errors in Commands</A>.)
|
|
|
|
</P>
|
|
<P>
|
|
A rule such as this should not be placed at the beginning of the
|
|
makefile, because we do not want it to run by default! Thus, in the
|
|
example makefile, we want the rule for <CODE>edit</CODE>, which recompiles
|
|
the editor, to remain the default goal.
|
|
|
|
</P>
|
|
<P>
|
|
Since <CODE>clean</CODE> is not a prerequisite of <CODE>edit</CODE>, this rule will not
|
|
run at all if we give the command <SAMP>`make'</SAMP> with no arguments. In
|
|
order to make the rule run, we have to type <SAMP>`make clean'</SAMP>.
|
|
See section <A HREF="make.html#SEC85">How to Run <CODE>make</CODE></A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC12" HREF="make.html#TOC12">Writing Makefiles</A></H1>
|
|
|
|
<P>
|
|
<A NAME="IDX48"></A>
|
|
The information that tells <CODE>make</CODE> how to recompile a system comes from
|
|
reading a data base called the <STRONG>makefile</STRONG>.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC13" HREF="make.html#TOC13">What Makefiles Contain</A></H2>
|
|
|
|
<P>
|
|
Makefiles contain five kinds of things: <STRONG>explicit rules</STRONG>,
|
|
<STRONG>implicit rules</STRONG>, <STRONG>variable definitions</STRONG>, <STRONG>directives</STRONG>,
|
|
and <STRONG>comments</STRONG>. Rules, variables, and directives are described at
|
|
length in later chapters.
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
<A NAME="IDX49"></A>
|
|
<A NAME="IDX50"></A>
|
|
|
|
An <STRONG>explicit rule</STRONG> says when and how to remake one or more files,
|
|
called the rule's targets. It lists the other files that the targets
|
|
depend on, call the <STRONG>prerequisites</STRONG> of the target, and may also give
|
|
commands to use to create or update the targets. See section <A HREF="make.html#SEC20">Writing Rules</A>.
|
|
|
|
<A NAME="IDX51"></A>
|
|
<A NAME="IDX52"></A>
|
|
<LI>
|
|
|
|
An <STRONG>implicit rule</STRONG> says when and how to remake a class of files
|
|
based on their names. It describes how a target may depend on a file
|
|
with a name similar to the target and gives commands to create or
|
|
update such a target. See section <A HREF="make.html#SEC93">Using Implicit Rules</A>.
|
|
|
|
<A NAME="IDX53"></A>
|
|
<LI>
|
|
|
|
A <STRONG>variable definition</STRONG> is a line that specifies a text string
|
|
value for a variable that can be substituted into the text later. The
|
|
simple makefile example shows a variable definition for <CODE>objects</CODE>
|
|
as a list of all object files (see section <A HREF="make.html#SEC8">Variables Make Makefiles Simpler</A>).
|
|
|
|
<A NAME="IDX54"></A>
|
|
<LI>
|
|
|
|
A <STRONG>directive</STRONG> is a command for <CODE>make</CODE> to do something special while
|
|
reading the makefile. These include:
|
|
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
Reading another makefile (see section <A HREF="make.html#SEC15">Including Other Makefiles</A>).
|
|
|
|
<LI>
|
|
|
|
Deciding (based on the values of variables) whether to use or
|
|
ignore a part of the makefile (see section <A HREF="make.html#SEC71">Conditional Parts of Makefiles</A>).
|
|
|
|
<LI>
|
|
|
|
Defining a variable from a verbatim string containing multiple lines
|
|
(see section <A HREF="make.html#SEC67">Defining Variables Verbatim</A>).
|
|
</UL>
|
|
|
|
<A NAME="IDX55"></A>
|
|
<A NAME="IDX56"></A>
|
|
<LI>
|
|
|
|
<SAMP>`#'</SAMP> in a line of a makefile starts a <STRONG>comment</STRONG>. It and the rest of
|
|
the line are ignored, except that a trailing backslash not escaped by
|
|
another backslash will continue the comment across multiple lines.
|
|
Comments may appear on any of the lines in the makefile, except within a
|
|
<CODE>define</CODE> directive, and perhaps within commands (where the shell
|
|
decides what is a comment). A line containing just a comment (with
|
|
perhaps spaces before it) is effectively blank, and is ignored.</UL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC14" HREF="make.html#TOC14">What Name to Give Your Makefile</A></H2>
|
|
<P>
|
|
<A NAME="IDX57"></A>
|
|
<A NAME="IDX58"></A>
|
|
<A NAME="IDX59"></A>
|
|
<A NAME="IDX60"></A>
|
|
|
|
</P>
|
|
<P>
|
|
By default, when <CODE>make</CODE> looks for the makefile, it tries the
|
|
following names, in order: <TT>`GNUmakefile'</TT>, <TT>`makefile'</TT>
|
|
and <TT>`Makefile'</TT>.<A NAME="IDX61"></A>
|
|
<A NAME="IDX62"></A>
|
|
<A NAME="IDX63"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX64"></A>
|
|
Normally you should call your makefile either <TT>`makefile'</TT> or
|
|
<TT>`Makefile'</TT>. (We recommend <TT>`Makefile'</TT> because it appears
|
|
prominently near the beginning of a directory listing, right near other
|
|
important files such as <TT>`README'</TT>.) The first name checked,
|
|
<TT>`GNUmakefile'</TT>, is not recommended for most makefiles. You should
|
|
use this name if you have a makefile that is specific to GNU
|
|
<CODE>make</CODE>, and will not be understood by other versions of
|
|
<CODE>make</CODE>. Other <CODE>make</CODE> programs look for <TT>`makefile'</TT> and
|
|
<TT>`Makefile'</TT>, but not <TT>`GNUmakefile'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
If <CODE>make</CODE> finds none of these names, it does not use any makefile.
|
|
Then you must specify a goal with a command argument, and <CODE>make</CODE>
|
|
will attempt to figure out how to remake it using only its built-in
|
|
implicit rules. See section <A HREF="make.html#SEC93">Using Implicit Rules</A>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX65"></A>
|
|
<A NAME="IDX66"></A>
|
|
<A NAME="IDX67"></A>
|
|
If you want to use a nonstandard name for your makefile, you can specify
|
|
the makefile name with the <SAMP>`-f'</SAMP> or <SAMP>`--file'</SAMP> option. The
|
|
arguments <SAMP>`-f <VAR>name</VAR>'</SAMP> or <SAMP>`--file=<VAR>name</VAR>'</SAMP> tell
|
|
<CODE>make</CODE> to read the file <VAR>name</VAR> as the makefile. If you use
|
|
more than one <SAMP>`-f'</SAMP> or <SAMP>`--file'</SAMP> option, you can specify several
|
|
makefiles. All the makefiles are effectively concatenated in the order
|
|
specified. The default makefile names <TT>`GNUmakefile'</TT>,
|
|
<TT>`makefile'</TT> and <TT>`Makefile'</TT> are not checked automatically if you
|
|
specify <SAMP>`-f'</SAMP> or <SAMP>`--file'</SAMP>.<A NAME="IDX68"></A>
|
|
<A NAME="IDX69"></A>
|
|
<A NAME="IDX70"></A>
|
|
<A NAME="IDX71"></A>
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC15" HREF="make.html#TOC15">Including Other Makefiles</A></H2>
|
|
<P>
|
|
<A NAME="IDX72"></A>
|
|
<A NAME="IDX73"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX74"></A>
|
|
The <CODE>include</CODE> directive tells <CODE>make</CODE> to suspend reading the
|
|
current makefile and read one or more other makefiles before continuing.
|
|
The directive is a line in the makefile that looks like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
include <VAR>filenames</VAR>...
|
|
</PRE>
|
|
|
|
<P>
|
|
<VAR>filenames</VAR> can contain shell file name patterns.
|
|
<A NAME="IDX75"></A>
|
|
<A NAME="IDX76"></A>
|
|
<A NAME="IDX77"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Extra spaces are allowed and ignored at the beginning of the line, but
|
|
a tab is not allowed. (If the line begins with a tab, it will be
|
|
considered a command line.) Whitespace is required between
|
|
<CODE>include</CODE> and the file names, and between file names; extra
|
|
whitespace is ignored there and at the end of the directive. A
|
|
comment starting with <SAMP>`#'</SAMP> is allowed at the end of the line. If
|
|
the file names contain any variable or function references, they are
|
|
expanded. See section <A HREF="make.html#SEC57">How to Use Variables</A>.
|
|
|
|
</P>
|
|
<P>
|
|
For example, if you have three <TT>`.mk'</TT> files, <TT>`a.mk'</TT>,
|
|
<TT>`b.mk'</TT>, and <TT>`c.mk'</TT>, and <CODE>$(bar)</CODE> expands to
|
|
<CODE>bish bash</CODE>, then the following expression
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
include foo *.mk $(bar)
|
|
</PRE>
|
|
|
|
<P>
|
|
is equivalent to
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
include foo a.mk b.mk c.mk bish bash
|
|
</PRE>
|
|
|
|
<P>
|
|
When <CODE>make</CODE> processes an <CODE>include</CODE> directive, it suspends
|
|
reading of the containing makefile and reads from each listed file in
|
|
turn. When that is finished, <CODE>make</CODE> resumes reading the
|
|
makefile in which the directive appears.
|
|
|
|
</P>
|
|
<P>
|
|
One occasion for using <CODE>include</CODE> directives is when several programs,
|
|
handled by individual makefiles in various directories, need to use a
|
|
common set of variable definitions
|
|
(see section <A HREF="make.html#SEC64">Setting Variables</A>) or pattern rules
|
|
(see section <A HREF="make.html#SEC98">Defining and Redefining Pattern Rules</A>).
|
|
|
|
</P>
|
|
<P>
|
|
Another such occasion is when you want to generate prerequisites from
|
|
source files automatically; the prerequisites can be put in a file that
|
|
is included by the main makefile. This practice is generally cleaner
|
|
than that of somehow appending the prerequisites to the end of the main
|
|
makefile as has been traditionally done with other versions of
|
|
<CODE>make</CODE>. See section <A HREF="make.html#SEC43">Generating Prerequisites Automatically</A>.
|
|
<A NAME="IDX78"></A>
|
|
<A NAME="IDX79"></A>
|
|
<A NAME="IDX80"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX81"></A>
|
|
<A NAME="IDX82"></A>
|
|
<A NAME="IDX83"></A>
|
|
<A NAME="IDX84"></A>
|
|
<A NAME="IDX85"></A>
|
|
<A NAME="IDX86"></A>
|
|
<A NAME="IDX87"></A>
|
|
If the specified name does not start with a slash, and the file is not
|
|
found in the current directory, several other directories are searched.
|
|
First, any directories you have specified with the <SAMP>`-I'</SAMP> or
|
|
<SAMP>`--include-dir'</SAMP> option are searched
|
|
(see section <A HREF="make.html#SEC92">Summary of Options</A>).
|
|
Then the following directories (if they exist)
|
|
are searched, in this order:
|
|
<TT>`<VAR>prefix</VAR>/include'</TT> (normally <TT>`/usr/local/include'</TT>
|
|
<A NAME="DOCF1" HREF="make.html#FOOT1">(1)</A>)
|
|
<TT>`/usr/gnu/include'</TT>,
|
|
<TT>`/usr/local/include'</TT>, <TT>`/usr/include'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
If an included makefile cannot be found in any of these directories, a
|
|
warning message is generated, but it is not an immediately fatal error;
|
|
processing of the makefile containing the <CODE>include</CODE> continues.
|
|
Once it has finished reading makefiles, <CODE>make</CODE> will try to remake
|
|
any that are out of date or don't exist.
|
|
See section <A HREF="make.html#SEC17">How Makefiles Are Remade</A>.
|
|
Only after it has tried to find a way to remake a makefile and failed,
|
|
will <CODE>make</CODE> diagnose the missing makefile as a fatal error.
|
|
|
|
</P>
|
|
<P>
|
|
If you want <CODE>make</CODE> to simply ignore a makefile which does not exist
|
|
and cannot be remade, with no error message, use the <CODE>-include</CODE>
|
|
directive instead of <CODE>include</CODE>, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
-include <VAR>filenames</VAR>...
|
|
</PRE>
|
|
|
|
<P>
|
|
This is acts like <CODE>include</CODE> in every way except that there is no
|
|
error (not even a warning) if any of the <VAR>filenames</VAR> do not exist.
|
|
For compatibility with some other <CODE>make</CODE> implementations,
|
|
<CODE>sinclude</CODE> is another name for <CODE>-include</CODE>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC16" HREF="make.html#TOC16">The Variable <CODE>MAKEFILES</CODE></A></H2>
|
|
<P>
|
|
<A NAME="IDX88"></A>
|
|
<A NAME="IDX89"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX90"></A>
|
|
If the environment variable <CODE>MAKEFILES</CODE> is defined, <CODE>make</CODE>
|
|
considers its value as a list of names (separated by whitespace) of
|
|
additional makefiles to be read before the others. This works much like
|
|
the <CODE>include</CODE> directive: various directories are searched for those
|
|
files (see section <A HREF="make.html#SEC15">Including Other Makefiles</A>). In addition, the
|
|
default goal is never taken from one of these makefiles and it is not an
|
|
error if the files listed in <CODE>MAKEFILES</CODE> are not found.
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX91"></A>
|
|
The main use of <CODE>MAKEFILES</CODE> is in communication between recursive
|
|
invocations of <CODE>make</CODE> (see section <A HREF="make.html#SEC50">Recursive Use of <CODE>make</CODE></A>). It usually is not desirable to set the environment
|
|
variable before a top-level invocation of <CODE>make</CODE>, because it is
|
|
usually better not to mess with a makefile from outside. However, if
|
|
you are running <CODE>make</CODE> without a specific makefile, a makefile in
|
|
<CODE>MAKEFILES</CODE> can do useful things to help the built-in implicit
|
|
rules work better, such as defining search paths (see section <A HREF="make.html#SEC26">Searching Directories for Prerequisites</A>).
|
|
|
|
</P>
|
|
<P>
|
|
Some users are tempted to set <CODE>MAKEFILES</CODE> in the environment
|
|
automatically on login, and program makefiles to expect this to be done.
|
|
This is a very bad idea, because such makefiles will fail to work if run by
|
|
anyone else. It is much better to write explicit <CODE>include</CODE> directives
|
|
in the makefiles. See section <A HREF="make.html#SEC15">Including Other Makefiles</A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC17" HREF="make.html#TOC17">How Makefiles Are Remade</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX92"></A>
|
|
<A NAME="IDX93"></A>
|
|
<A NAME="IDX94"></A>
|
|
Sometimes makefiles can be remade from other files, such as RCS or SCCS
|
|
files. If a makefile can be remade from other files, you probably want
|
|
<CODE>make</CODE> to get an up-to-date version of the makefile to read in.
|
|
|
|
</P>
|
|
<P>
|
|
To this end, after reading in all makefiles, <CODE>make</CODE> will consider
|
|
each as a goal target and attempt to update it. If a makefile has a
|
|
rule which says how to update it (found either in that very makefile or
|
|
in another one) or if an implicit rule applies to it (see section <A HREF="make.html#SEC93">Using Implicit Rules</A>), it will be updated if necessary. After
|
|
all makefiles have been checked, if any have actually been changed,
|
|
<CODE>make</CODE> starts with a clean slate and reads all the makefiles over
|
|
again. (It will also attempt to update each of them over again, but
|
|
normally this will not change them again, since they are already up to
|
|
date.)
|
|
</P>
|
|
<P>
|
|
If you know that one or more of your makefiles cannot be remade and you
|
|
want to keep <CODE>make</CODE> from performing an implicit rule search on
|
|
them, perhaps for efficiency reasons, you can use any normal method of
|
|
preventing implicit rule lookup to do so. For example, you can write an
|
|
explicit rule with the makefile as the target, and an empty command
|
|
string (see section <A HREF="make.html#SEC56">Using Empty Commands</A>).
|
|
|
|
</P>
|
|
<P>
|
|
If the makefiles specify a double-colon rule to remake a file with
|
|
commands but no prerequisites, that file will always be remade
|
|
(see section <A HREF="make.html#SEC42">Double-Colon Rules</A>). In the case of makefiles, a makefile that has a
|
|
double-colon rule with commands but no prerequisites will be remade every
|
|
time <CODE>make</CODE> is run, and then again after <CODE>make</CODE> starts over
|
|
and reads the makefiles in again. This would cause an infinite loop:
|
|
<CODE>make</CODE> would constantly remake the makefile, and never do anything
|
|
else. So, to avoid this, <CODE>make</CODE> will <STRONG>not</STRONG> attempt to
|
|
remake makefiles which are specified as targets of a double-colon rule
|
|
with commands but no prerequisites.
|
|
</P>
|
|
<P>
|
|
If you do not specify any makefiles to be read with <SAMP>`-f'</SAMP> or
|
|
<SAMP>`--file'</SAMP> options, <CODE>make</CODE> will try the default makefile names;
|
|
see section <A HREF="make.html#SEC14">What Name to Give Your Makefile</A>. Unlike
|
|
makefiles explicitly requested with <SAMP>`-f'</SAMP> or <SAMP>`--file'</SAMP> options,
|
|
<CODE>make</CODE> is not certain that these makefiles should exist. However,
|
|
if a default makefile does not exist but can be created by running
|
|
<CODE>make</CODE> rules, you probably want the rules to be run so that the
|
|
makefile can be used.
|
|
|
|
</P>
|
|
<P>
|
|
Therefore, if none of the default makefiles exists, <CODE>make</CODE> will try
|
|
to make each of them in the same order in which they are searched for
|
|
(see section <A HREF="make.html#SEC14">What Name to Give Your Makefile</A>)
|
|
until it succeeds in making one, or it runs out of names to try. Note
|
|
that it is not an error if <CODE>make</CODE> cannot find or make any makefile;
|
|
a makefile is not always necessary.
|
|
</P>
|
|
<P>
|
|
When you use the <SAMP>`-t'</SAMP> or <SAMP>`--touch'</SAMP> option
|
|
(see section <A HREF="make.html#SEC88">Instead of Executing the Commands</A>),
|
|
you would not want to use an out-of-date makefile to decide which
|
|
targets to touch. So the <SAMP>`-t'</SAMP> option has no effect on updating
|
|
makefiles; they are really updated even if <SAMP>`-t'</SAMP> is specified.
|
|
Likewise, <SAMP>`-q'</SAMP> (or <SAMP>`--question'</SAMP>) and <SAMP>`-n'</SAMP> (or
|
|
<SAMP>`--just-print'</SAMP>) do not prevent updating of makefiles, because an
|
|
out-of-date makefile would result in the wrong output for other targets.
|
|
Thus, <SAMP>`make -f mfile -n foo'</SAMP> will update <TT>`mfile'</TT>, read it in,
|
|
and then print the commands to update <TT>`foo'</TT> and its prerequisites
|
|
without running them. The commands printed for <TT>`foo'</TT> will be those
|
|
specified in the updated contents of <TT>`mfile'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
However, on occasion you might actually wish to prevent updating of even
|
|
the makefiles. You can do this by specifying the makefiles as goals in
|
|
the command line as well as specifying them as makefiles. When the
|
|
makefile name is specified explicitly as a goal, the options <SAMP>`-t'</SAMP>
|
|
and so on do apply to them.
|
|
|
|
</P>
|
|
<P>
|
|
Thus, <SAMP>`make -f mfile -n mfile foo'</SAMP> would read the makefile
|
|
<TT>`mfile'</TT>, print the commands needed to update it without actually
|
|
running them, and then print the commands needed to update <TT>`foo'</TT>
|
|
without running them. The commands for <TT>`foo'</TT> will be those
|
|
specified by the existing contents of <TT>`mfile'</TT>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC18" HREF="make.html#TOC18">Overriding Part of Another Makefile</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX95"></A>
|
|
<A NAME="IDX96"></A>
|
|
Sometimes it is useful to have a makefile that is mostly just like
|
|
another makefile. You can often use the <SAMP>`include'</SAMP> directive to
|
|
include one in the other, and add more targets or variable definitions.
|
|
However, if the two makefiles give different commands for the same
|
|
target, <CODE>make</CODE> will not let you just do this. But there is another way.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX97"></A>
|
|
In the containing makefile (the one that wants to include the other),
|
|
you can use a match-anything pattern rule to say that to remake any
|
|
target that cannot be made from the information in the containing
|
|
makefile, <CODE>make</CODE> should look in another makefile.
|
|
See section <A HREF="make.html#SEC98">Defining and Redefining Pattern Rules</A>, for more information on pattern rules.
|
|
|
|
</P>
|
|
<P>
|
|
For example, if you have a makefile called <TT>`Makefile'</TT> that says how
|
|
to make the target <SAMP>`foo'</SAMP> (and other targets), you can write a
|
|
makefile called <TT>`GNUmakefile'</TT> that contains:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo:
|
|
frobnicate > foo
|
|
|
|
%: force
|
|
@$(MAKE) -f Makefile $@
|
|
force: ;
|
|
</PRE>
|
|
|
|
<P>
|
|
If you say <SAMP>`make foo'</SAMP>, <CODE>make</CODE> will find <TT>`GNUmakefile'</TT>,
|
|
read it, and see that to make <TT>`foo'</TT>, it needs to run the command
|
|
<SAMP>`frobnicate > foo'</SAMP>. If you say <SAMP>`make bar'</SAMP>, <CODE>make</CODE> will
|
|
find no way to make <TT>`bar'</TT> in <TT>`GNUmakefile'</TT>, so it will use the
|
|
commands from the pattern rule: <SAMP>`make -f Makefile bar'</SAMP>. If
|
|
<TT>`Makefile'</TT> provides a rule for updating <TT>`bar'</TT>, <CODE>make</CODE>
|
|
will apply the rule. And likewise for any other target that
|
|
<TT>`GNUmakefile'</TT> does not say how to make.
|
|
|
|
</P>
|
|
<P>
|
|
The way this works is that the pattern rule has a pattern of just
|
|
<SAMP>`%'</SAMP>, so it matches any target whatever. The rule specifies a
|
|
prerequisite <TT>`force'</TT>, to guarantee that the commands will be run even
|
|
if the target file already exists. We give <TT>`force'</TT> target empty
|
|
commands to prevent <CODE>make</CODE> from searching for an implicit rule to
|
|
build it--otherwise it would apply the same match-anything rule to
|
|
<TT>`force'</TT> itself and create a prerequisite loop!
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC19" HREF="make.html#TOC19">How <CODE>make</CODE> Reads a Makefile</A></H2>
|
|
<P>
|
|
<A NAME="IDX98"></A>
|
|
<A NAME="IDX99"></A>
|
|
|
|
</P>
|
|
<P>
|
|
GNU <CODE>make</CODE> does its work in two distinct phases. During the first
|
|
phase it reads all the makefiles, included makefiles, etc. and
|
|
internalizes all the variables and their values, implicit and explicit
|
|
rules, and constructs a dependency graph of all the targets and their
|
|
prerequisites. During the second phase, <CODE>make</CODE> uses these internal
|
|
structures to determine what targets will need to be rebuilt and to
|
|
invoke the rules necessary to do so.
|
|
|
|
</P>
|
|
<P>
|
|
It's important to understand this two-phase approach because it has a
|
|
direct impact on how variable and function expansion happens; this is
|
|
often a source of some confusion when writing makefiles. Here we will
|
|
present a summary of the phases in which expansion happens for different
|
|
constructs within the makefile. We say that expansion is
|
|
<STRONG>immediate</STRONG> if it happens during the first phase: in this case
|
|
<CODE>make</CODE> will expand any variables or functions in that section of a
|
|
construct as the makefile is parsed. We say that expansion is
|
|
<STRONG>deferred</STRONG> if expansion is not performed immediately. Expansion of
|
|
deferred construct is not performed until either the construct appears
|
|
later in an immediate context, or until the second phase.
|
|
|
|
</P>
|
|
<P>
|
|
You may not be familiar with some of these constructs yet. You can
|
|
reference this section as you become familiar with them, in later
|
|
chapters.
|
|
|
|
</P>
|
|
|
|
<H3>Variable Assignment</H3>
|
|
<P>
|
|
<A NAME="IDX100"></A>
|
|
<A NAME="IDX101"></A>
|
|
<A NAME="IDX102"></A>
|
|
<A NAME="IDX103"></A>
|
|
<A NAME="IDX104"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Variable definitions are parsed as follows:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>immediate</VAR> = <VAR>deferred</VAR>
|
|
<VAR>immediate</VAR> ?= <VAR>deferred</VAR>
|
|
<VAR>immediate</VAR> := <VAR>immediate</VAR>
|
|
<VAR>immediate</VAR> += <VAR>deferred</VAR> or <VAR>immediate</VAR>
|
|
|
|
define <VAR>immediate</VAR>
|
|
<VAR>deferred</VAR>
|
|
endef
|
|
</PRE>
|
|
|
|
<P>
|
|
For the append operator, <SAMP>`+='</SAMP>, the right-hand side is considered
|
|
immediate if the variable was previously set as a simple variable
|
|
(<SAMP>`:='</SAMP>), and deferred otherwise.
|
|
|
|
</P>
|
|
|
|
<H3>Conditional Syntax</H3>
|
|
<P>
|
|
<A NAME="IDX105"></A>
|
|
<A NAME="IDX106"></A>
|
|
<A NAME="IDX107"></A>
|
|
<A NAME="IDX108"></A>
|
|
|
|
</P>
|
|
<P>
|
|
All instances of conditional syntax are parsed immediately, in their
|
|
entirety; this includes the <CODE>ifdef</CODE>, <CODE>ifeq</CODE>, <CODE>ifndef</CODE>,
|
|
and <CODE>ifneq</CODE> forms.
|
|
|
|
</P>
|
|
|
|
<H3>Rule Definition</H3>
|
|
<P>
|
|
<A NAME="IDX109"></A>
|
|
<A NAME="IDX110"></A>
|
|
<A NAME="IDX111"></A>
|
|
<A NAME="IDX112"></A>
|
|
<A NAME="IDX113"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A rule is always expanded the same way, regardless of the form:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>immediate</VAR> : <VAR>immediate</VAR> ; <VAR>deferred</VAR>
|
|
<VAR>deferred</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
That is, the target and prerequisite sections are expanded immediately,
|
|
and the commands used to construct the target are always deferred. This
|
|
general rule is true for explicit rules, pattern rules, suffix rules,
|
|
static pattern rules, and simple prerequisite definitions.
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC20" HREF="make.html#TOC20">Writing Rules</A></H1>
|
|
<P>
|
|
<A NAME="IDX114"></A>
|
|
<A NAME="IDX115"></A>
|
|
<A NAME="IDX116"></A>
|
|
<A NAME="IDX117"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A <STRONG>rule</STRONG> appears in the makefile and says when and how to remake
|
|
certain files, called the rule's <STRONG>targets</STRONG> (most often only one per rule).
|
|
It lists the other files that are the <STRONG>prerequisites</STRONG> of the target, and
|
|
<STRONG>commands</STRONG> to use to create or update the target.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX118"></A>
|
|
<A NAME="IDX119"></A>
|
|
The order of rules is not significant, except for determining the
|
|
<STRONG>default goal</STRONG>: the target for <CODE>make</CODE> to consider, if you do
|
|
not otherwise specify one. The default goal is the target of the first
|
|
rule in the first makefile. If the first rule has multiple targets,
|
|
only the first target is taken as the default. There are two
|
|
exceptions: a target starting with a period is not a default unless it
|
|
contains one or more slashes, <SAMP>`/'</SAMP>, as well; and, a target that
|
|
defines a pattern rule has no effect on the default goal.
|
|
(See section <A HREF="make.html#SEC98">Defining and Redefining Pattern Rules</A>.)
|
|
|
|
</P>
|
|
<P>
|
|
Therefore, we usually write the makefile so that the first rule is the
|
|
one for compiling the entire program or all the programs described by
|
|
the makefile (often with a target called <SAMP>`all'</SAMP>).
|
|
See section <A HREF="make.html#SEC87">Arguments to Specify the Goals</A>.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC21" HREF="make.html#TOC21">Rule Syntax</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX120"></A>
|
|
<A NAME="IDX121"></A>
|
|
In general, a rule looks like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>targets</VAR> : <VAR>prerequisites</VAR>
|
|
<VAR>command</VAR>
|
|
...
|
|
</PRE>
|
|
|
|
<P>
|
|
or like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>targets</VAR> : <VAR>prerequisites</VAR> ; <VAR>command</VAR>
|
|
<VAR>command</VAR>
|
|
...
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX122"></A>
|
|
<A NAME="IDX123"></A>
|
|
The <VAR>targets</VAR> are file names, separated by spaces. Wildcard
|
|
characters may be used (see section <A HREF="make.html#SEC22">Using Wildcard Characters in File Names</A>) and a name of the form <TT>`<VAR>a</VAR>(<VAR>m</VAR>)'</TT>
|
|
represents member <VAR>m</VAR> in archive file <VAR>a</VAR>
|
|
(see section <A HREF="make.html#SEC109">Archive Members as Targets</A>).
|
|
Usually there is only one
|
|
target per rule, but occasionally there is a reason to have more
|
|
(see section <A HREF="make.html#SEC37">Multiple Targets in a Rule</A>).
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX124"></A>
|
|
<A NAME="IDX125"></A>
|
|
The <VAR>command</VAR> lines start with a tab character. The first command may
|
|
appear on the line after the prerequisites, with a tab character, or may
|
|
appear on the same line, with a semicolon. Either way, the effect is the
|
|
same. See section <A HREF="make.html#SEC44">Writing the Commands in Rules</A>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX126"></A>
|
|
<A NAME="IDX127"></A>
|
|
<A NAME="IDX128"></A>
|
|
Because dollar signs are used to start variable references, if you really
|
|
want a dollar sign in a rule you must write two of them, <SAMP>`$$'</SAMP>
|
|
(see section <A HREF="make.html#SEC57">How to Use Variables</A>).
|
|
You may split a long line by inserting a backslash
|
|
followed by a newline, but this is not required, as <CODE>make</CODE> places no
|
|
limit on the length of a line in a makefile.
|
|
|
|
</P>
|
|
<P>
|
|
A rule tells <CODE>make</CODE> two things: when the targets are out of date,
|
|
and how to update them when necessary.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX129"></A>
|
|
<A NAME="IDX130"></A>
|
|
The criterion for being out of date is specified in terms of the
|
|
<VAR>prerequisites</VAR>, which consist of file names separated by spaces.
|
|
(Wildcards and archive members (see section <A HREF="make.html#SEC108">Using <CODE>make</CODE> to Update Archive Files</A>) are allowed here too.)
|
|
A target is out of date if it does not exist or if it is older than any
|
|
of the prerequisites (by comparison of last-modification times). The
|
|
idea is that the contents of the target file are computed based on
|
|
information in the prerequisites, so if any of the prerequisites changes,
|
|
the contents of the existing target file are no longer necessarily
|
|
valid.
|
|
|
|
</P>
|
|
<P>
|
|
How to update is specified by <VAR>commands</VAR>. These are lines to be
|
|
executed by the shell (normally <SAMP>`sh'</SAMP>), but with some extra features
|
|
(see section <A HREF="make.html#SEC44">Writing the Commands in Rules</A>).
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC22" HREF="make.html#TOC22">Using Wildcard Characters in File Names</A></H2>
|
|
<P>
|
|
<A NAME="IDX131"></A>
|
|
<A NAME="IDX132"></A>
|
|
<A NAME="IDX133"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX134"></A>
|
|
<A NAME="IDX135"></A>
|
|
<A NAME="IDX136"></A>
|
|
A single file name can specify many files using <STRONG>wildcard characters</STRONG>.
|
|
The wildcard characters in <CODE>make</CODE> are <SAMP>`*'</SAMP>, <SAMP>`?'</SAMP> and
|
|
<SAMP>`[...]'</SAMP>, the same as in the Bourne shell. For example, <TT>`*.c'</TT>
|
|
specifies a list of all the files (in the working directory) whose names
|
|
end in <SAMP>`.c'</SAMP>.
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX137"></A>
|
|
<A NAME="IDX138"></A>
|
|
<A NAME="IDX139"></A>
|
|
The character <SAMP>`~'</SAMP> at the beginning of a file name also has special
|
|
significance. If alone, or followed by a slash, it represents your home
|
|
directory. For example <TT>`~/bin'</TT> expands to <TT>`/home/you/bin'</TT>.
|
|
If the <SAMP>`~'</SAMP> is followed by a word, the string represents the home
|
|
directory of the user named by that word. For example <TT>`~john/bin'</TT>
|
|
expands to <TT>`/home/john/bin'</TT>. On systems which don't have a home
|
|
directory for each user (such as MS-DOS or MS-Windows), this
|
|
functionality can be simulated by setting the environment variable
|
|
<VAR>HOME</VAR>.
|
|
</P>
|
|
<P>
|
|
Wildcard expansion happens automatically in targets, in prerequisites,
|
|
and in commands (where the shell does the expansion). In other
|
|
contexts, wildcard expansion happens only if you request it explicitly
|
|
with the <CODE>wildcard</CODE> function.
|
|
|
|
</P>
|
|
<P>
|
|
The special significance of a wildcard character can be turned off by
|
|
preceding it with a backslash. Thus, <TT>`foo\*bar'</TT> would refer to a
|
|
specific file whose name consists of <SAMP>`foo'</SAMP>, an asterisk, and
|
|
<SAMP>`bar'</SAMP>.
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC23" HREF="make.html#TOC23">Wildcard Examples</A></H3>
|
|
|
|
<P>
|
|
Wildcards can be used in the commands of a rule, where they are expanded
|
|
by the shell. For example, here is a rule to delete all the object files:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
clean:
|
|
rm -f *.o
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX140"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Wildcards are also useful in the prerequisites of a rule. With the
|
|
following rule in the makefile, <SAMP>`make print'</SAMP> will print all the
|
|
<SAMP>`.c'</SAMP> files that have changed since the last time you printed them:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
print: *.c
|
|
lpr -p $?
|
|
touch print
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX141"></A>
|
|
<A NAME="IDX142"></A>
|
|
<A NAME="IDX143"></A>
|
|
This rule uses <TT>`print'</TT> as an empty target file; see section <A HREF="make.html#SEC35">Empty Target Files to Record Events</A>. (The automatic variable
|
|
<SAMP>`$?'</SAMP> is used to print only those files that have changed; see
|
|
section <A HREF="make.html#SEC101">Automatic Variables</A>.)
|
|
</P>
|
|
<P>
|
|
Wildcard expansion does not happen when you define a variable. Thus, if
|
|
you write this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects = *.o
|
|
</PRE>
|
|
|
|
<P>
|
|
then the value of the variable <CODE>objects</CODE> is the actual string
|
|
<SAMP>`*.o'</SAMP>. However, if you use the value of <CODE>objects</CODE> in a target,
|
|
prerequisite or command, wildcard expansion will take place at that time.
|
|
To set <CODE>objects</CODE> to the expansion, instead use:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects := $(wildcard *.o)
|
|
</PRE>
|
|
|
|
<P>
|
|
See section <A HREF="make.html#SEC25">The Function <CODE>wildcard</CODE></A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC24" HREF="make.html#TOC24">Pitfalls of Using Wildcards</A></H3>
|
|
<P>
|
|
<A NAME="IDX144"></A>
|
|
<A NAME="IDX145"></A>
|
|
<A NAME="IDX146"></A>
|
|
<A NAME="IDX147"></A>
|
|
<A NAME="IDX148"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Now here is an example of a naive way of using wildcard expansion, that
|
|
does not do what you would intend. Suppose you would like to say that the
|
|
executable file <TT>`foo'</TT> is made from all the object files in the
|
|
directory, and you write this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects = *.o
|
|
|
|
foo : $(objects)
|
|
cc -o foo $(CFLAGS) $(objects)
|
|
</PRE>
|
|
|
|
<P>
|
|
The value of <CODE>objects</CODE> is the actual string <SAMP>`*.o'</SAMP>. Wildcard
|
|
expansion happens in the rule for <TT>`foo'</TT>, so that each <EM>existing</EM>
|
|
<SAMP>`.o'</SAMP> file becomes a prerequisite of <TT>`foo'</TT> and will be recompiled if
|
|
necessary.
|
|
|
|
</P>
|
|
<P>
|
|
But what if you delete all the <SAMP>`.o'</SAMP> files? When a wildcard matches
|
|
no files, it is left as it is, so then <TT>`foo'</TT> will depend on the
|
|
oddly-named file <TT>`*.o'</TT>. Since no such file is likely to exist,
|
|
<CODE>make</CODE> will give you an error saying it cannot figure out how to
|
|
make <TT>`*.o'</TT>. This is not what you want!
|
|
|
|
</P>
|
|
<P>
|
|
Actually it is possible to obtain the desired result with wildcard
|
|
expansion, but you need more sophisticated techniques, including the
|
|
<CODE>wildcard</CODE> function and string substitution.
|
|
These are described in the following section.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX149"></A>
|
|
<A NAME="IDX150"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Microsoft operating systems (MS-DOS and MS-Windows) use backslashes to
|
|
separate directories in pathnames, like so:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
c:\foo\bar\baz.c
|
|
</PRE>
|
|
|
|
<P>
|
|
This is equivalent to the Unix-style <TT>`c:/foo/bar/baz.c'</TT> (the
|
|
<TT>`c:'</TT> part is the so-called drive letter). When <CODE>make</CODE> runs on
|
|
these systems, it supports backslashes as well as the Unix-style forward
|
|
slashes in pathnames. However, this support does <EM>not</EM> include the
|
|
wildcard expansion, where backslash is a quote character. Therefore,
|
|
you <EM>must</EM> use Unix-style slashes in these cases.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC25" HREF="make.html#TOC25">The Function <CODE>wildcard</CODE></A></H3>
|
|
<P>
|
|
<A NAME="IDX151"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Wildcard expansion happens automatically in rules. But wildcard expansion
|
|
does not normally take place when a variable is set, or inside the
|
|
arguments of a function. If you want to do wildcard expansion in such
|
|
places, you need to use the <CODE>wildcard</CODE> function, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$(wildcard <VAR>pattern</VAR>...)
|
|
</PRE>
|
|
|
|
<P>
|
|
This string, used anywhere in a makefile, is replaced by a
|
|
space-separated list of names of existing files that match one of the
|
|
given file name patterns. If no existing file name matches a pattern,
|
|
then that pattern is omitted from the output of the <CODE>wildcard</CODE>
|
|
function. Note that this is different from how unmatched wildcards
|
|
behave in rules, where they are used verbatim rather than ignored
|
|
(see section <A HREF="make.html#SEC24">Pitfalls of Using Wildcards</A>).
|
|
|
|
</P>
|
|
<P>
|
|
One use of the <CODE>wildcard</CODE> function is to get a list of all the C source
|
|
files in a directory, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$(wildcard *.c)
|
|
</PRE>
|
|
|
|
<P>
|
|
We can change the list of C source files into a list of object files by
|
|
replacing the <SAMP>`.c'</SAMP> suffix with <SAMP>`.o'</SAMP> in the result, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$(patsubst %.c,%.o,$(wildcard *.c))
|
|
</PRE>
|
|
|
|
<P>
|
|
(Here we have used another function, <CODE>patsubst</CODE>.
|
|
See section <A HREF="make.html#SEC77">Functions for String Substitution and Analysis</A>.)
|
|
</P>
|
|
<P>
|
|
Thus, a makefile to compile all C source files in the directory and then
|
|
link them together could be written as follows:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects := $(patsubst %.c,%.o,$(wildcard *.c))
|
|
|
|
foo : $(objects)
|
|
cc -o foo $(objects)
|
|
</PRE>
|
|
|
|
<P>
|
|
(This takes advantage of the implicit rule for compiling C programs, so
|
|
there is no need to write explicit rules for compiling the files.
|
|
See section <A HREF="make.html#SEC59">The Two Flavors of Variables</A>, for an explanation of
|
|
<SAMP>`:='</SAMP>, which is a variant of <SAMP>`='</SAMP>.)
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC26" HREF="make.html#TOC26">Searching Directories for Prerequisites</A></H2>
|
|
<P>
|
|
<A NAME="IDX152"></A>
|
|
<A NAME="IDX153"></A>
|
|
<A NAME="IDX154"></A>
|
|
<A NAME="IDX155"></A>
|
|
<A NAME="IDX156"></A>
|
|
|
|
</P>
|
|
<P>
|
|
For large systems, it is often desirable to put sources in a separate
|
|
directory from the binaries. The <STRONG>directory search</STRONG> features of
|
|
<CODE>make</CODE> facilitate this by searching several directories
|
|
automatically to find a prerequisite. When you redistribute the files
|
|
among directories, you do not need to change the individual rules,
|
|
just the search paths.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC27" HREF="make.html#TOC27"><CODE>VPATH</CODE>: Search Path for All Prerequisites</A></H3>
|
|
<P>
|
|
<A NAME="IDX157"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The value of the <CODE>make</CODE> variable <CODE>VPATH</CODE> specifies a list of
|
|
directories that <CODE>make</CODE> should search. Most often, the
|
|
directories are expected to contain prerequisite files that are not in the
|
|
current directory; however, <CODE>VPATH</CODE> specifies a search list that
|
|
<CODE>make</CODE> applies for all files, including files which are targets of
|
|
rules.
|
|
|
|
</P>
|
|
<P>
|
|
Thus, if a file that is listed as a target or prerequisite does not exist
|
|
in the current directory, <CODE>make</CODE> searches the directories listed in
|
|
<CODE>VPATH</CODE> for a file with that name. If a file is found in one of
|
|
them, that file may become the prerequisite (see below). Rules may then
|
|
specify the names of files in the prerequisite list as if they all
|
|
existed in the current directory. See section <A HREF="make.html#SEC30">Writing Shell Commands with Directory Search</A>.
|
|
|
|
</P>
|
|
<P>
|
|
In the <CODE>VPATH</CODE> variable, directory names are separated by colons or
|
|
blanks. The order in which directories are listed is the order followed
|
|
by <CODE>make</CODE> in its search. (On MS-DOS and MS-Windows, semi-colons
|
|
are used as separators of directory names in <CODE>VPATH</CODE>, since the
|
|
colon can be used in the pathname itself, after the drive letter.)
|
|
|
|
</P>
|
|
<P>
|
|
For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
VPATH = src:../headers
|
|
</PRE>
|
|
|
|
<P>
|
|
specifies a path containing two directories, <TT>`src'</TT> and
|
|
<TT>`../headers'</TT>, which <CODE>make</CODE> searches in that order.
|
|
|
|
</P>
|
|
<P>
|
|
With this value of <CODE>VPATH</CODE>, the following rule,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo.o : foo.c
|
|
</PRE>
|
|
|
|
<P>
|
|
is interpreted as if it were written like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo.o : src/foo.c
|
|
</PRE>
|
|
|
|
<P>
|
|
assuming the file <TT>`foo.c'</TT> does not exist in the current directory but
|
|
is found in the directory <TT>`src'</TT>.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC28" HREF="make.html#TOC28">The <CODE>vpath</CODE> Directive</A></H3>
|
|
<P>
|
|
<A NAME="IDX158"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Similar to the <CODE>VPATH</CODE> variable, but more selective, is the
|
|
<CODE>vpath</CODE> directive (note lower case), which allows you to specify a
|
|
search path for a particular class of file names: those that match a
|
|
particular pattern. Thus you can supply certain search directories for
|
|
one class of file names and other directories (or none) for other file
|
|
names.
|
|
|
|
</P>
|
|
<P>
|
|
There are three forms of the <CODE>vpath</CODE> directive:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>vpath <VAR>pattern</VAR> <VAR>directories</VAR></CODE>
|
|
<DD>
|
|
Specify the search path <VAR>directories</VAR> for file names that match
|
|
<VAR>pattern</VAR>.
|
|
|
|
The search path, <VAR>directories</VAR>, is a list of directories to be
|
|
searched, separated by colons (semi-colons on MS-DOS and MS-Windows) or
|
|
blanks, just like the search path used in the <CODE>VPATH</CODE> variable.
|
|
|
|
<DT><CODE>vpath <VAR>pattern</VAR></CODE>
|
|
<DD>
|
|
Clear out the search path associated with <VAR>pattern</VAR>.
|
|
|
|
<DT><CODE>vpath</CODE>
|
|
<DD>
|
|
Clear all search paths previously specified with <CODE>vpath</CODE> directives.
|
|
</DL>
|
|
|
|
<P>
|
|
A <CODE>vpath</CODE> pattern is a string containing a <SAMP>`%'</SAMP> character. The
|
|
string must match the file name of a prerequisite that is being searched
|
|
for, the <SAMP>`%'</SAMP> character matching any sequence of zero or more
|
|
characters (as in pattern rules; see section <A HREF="make.html#SEC98">Defining and Redefining Pattern Rules</A>). For example, <CODE>%.h</CODE> matches files that
|
|
end in <CODE>.h</CODE>. (If there is no <SAMP>`%'</SAMP>, the pattern must match the
|
|
prerequisite exactly, which is not useful very often.)
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX159"></A>
|
|
<A NAME="IDX160"></A>
|
|
<A NAME="IDX161"></A>
|
|
<A NAME="IDX162"></A>
|
|
<A NAME="IDX163"></A>
|
|
<SAMP>`%'</SAMP> characters in a <CODE>vpath</CODE> directive's pattern can be quoted
|
|
with preceding backslashes (<SAMP>`\'</SAMP>). Backslashes that would otherwise
|
|
quote <SAMP>`%'</SAMP> characters can be quoted with more backslashes.
|
|
Backslashes that quote <SAMP>`%'</SAMP> characters or other backslashes are
|
|
removed from the pattern before it is compared to file names. Backslashes
|
|
that are not in danger of quoting <SAMP>`%'</SAMP> characters go unmolested.
|
|
</P>
|
|
<P>
|
|
When a prerequisite fails to exist in the current directory, if the
|
|
<VAR>pattern</VAR> in a <CODE>vpath</CODE> directive matches the name of the
|
|
prerequisite file, then the <VAR>directories</VAR> in that directive are searched
|
|
just like (and before) the directories in the <CODE>VPATH</CODE> variable.
|
|
|
|
</P>
|
|
<P>
|
|
For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
vpath %.h ../headers
|
|
</PRE>
|
|
|
|
<P>
|
|
tells <CODE>make</CODE> to look for any prerequisite whose name ends in <TT>`.h'</TT>
|
|
in the directory <TT>`../headers'</TT> if the file is not found in the current
|
|
directory.
|
|
|
|
</P>
|
|
<P>
|
|
If several <CODE>vpath</CODE> patterns match the prerequisite file's name, then
|
|
<CODE>make</CODE> processes each matching <CODE>vpath</CODE> directive one by one,
|
|
searching all the directories mentioned in each directive. <CODE>make</CODE>
|
|
handles multiple <CODE>vpath</CODE> directives in the order in which they
|
|
appear in the makefile; multiple directives with the same pattern are
|
|
independent of each other.
|
|
|
|
</P>
|
|
<P>
|
|
Thus,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
vpath %.c foo
|
|
vpath % blish
|
|
vpath %.c bar
|
|
</PRE>
|
|
|
|
<P>
|
|
will look for a file ending in <SAMP>`.c'</SAMP> in <TT>`foo'</TT>, then
|
|
<TT>`blish'</TT>, then <TT>`bar'</TT>, while
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
vpath %.c foo:bar
|
|
vpath % blish
|
|
</PRE>
|
|
|
|
<P>
|
|
will look for a file ending in <SAMP>`.c'</SAMP> in <TT>`foo'</TT>, then
|
|
<TT>`bar'</TT>, then <TT>`blish'</TT>.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC29" HREF="make.html#TOC29">How Directory Searches are Performed</A></H3>
|
|
<P>
|
|
<A NAME="IDX164"></A>
|
|
<A NAME="IDX165"></A>
|
|
|
|
</P>
|
|
<P>
|
|
When a prerequisite is found through directory search, regardless of type
|
|
(general or selective), the pathname located may not be the one that
|
|
<CODE>make</CODE> actually provides you in the prerequisite list. Sometimes
|
|
the path discovered through directory search is thrown away.
|
|
|
|
</P>
|
|
<P>
|
|
The algorithm <CODE>make</CODE> uses to decide whether to keep or abandon a
|
|
path found via directory search is as follows:
|
|
|
|
</P>
|
|
|
|
<OL>
|
|
<LI>
|
|
|
|
If a target file does not exist at the path specified in the makefile,
|
|
directory search is performed.
|
|
|
|
<LI>
|
|
|
|
If the directory search is successful, that path is kept and this file
|
|
is tentatively stored as the target.
|
|
|
|
<LI>
|
|
|
|
All prerequisites of this target are examined using this same method.
|
|
|
|
<LI>
|
|
|
|
After processing the prerequisites, the target may or may not need to be
|
|
rebuilt:
|
|
|
|
|
|
<OL>
|
|
<LI>
|
|
|
|
If the target does <EM>not</EM> need to be rebuilt, the path to the file
|
|
found during directory search is used for any prerequisite lists which
|
|
contain this target. In short, if <CODE>make</CODE> doesn't need to rebuild
|
|
the target then you use the path found via directory search.
|
|
|
|
<LI>
|
|
|
|
If the target <EM>does</EM> need to be rebuilt (is out-of-date), the
|
|
pathname found during directory search is <EM>thrown away</EM>, and the
|
|
target is rebuilt using the file name specified in the makefile. In
|
|
short, if <CODE>make</CODE> must rebuild, then the target is rebuilt locally,
|
|
not in the directory found via directory search.
|
|
</OL>
|
|
|
|
</OL>
|
|
|
|
<P>
|
|
This algorithm may seem complex, but in practice it is quite often
|
|
exactly what you want.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX166"></A>
|
|
<A NAME="IDX167"></A>
|
|
Other versions of <CODE>make</CODE> use a simpler algorithm: if the file does
|
|
not exist, and it is found via directory search, then that pathname is
|
|
always used whether or not the target needs to be built. Thus, if the
|
|
target is rebuilt it is created at the pathname discovered during
|
|
directory search.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX168"></A>
|
|
If, in fact, this is the behavior you want for some or all of your
|
|
directories, you can use the <CODE>GPATH</CODE> variable to indicate this to
|
|
<CODE>make</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
<CODE>GPATH</CODE> has the same syntax and format as <CODE>VPATH</CODE> (that is, a
|
|
space- or colon-delimited list of pathnames). If an out-of-date target
|
|
is found by directory search in a directory that also appears in
|
|
<CODE>GPATH</CODE>, then that pathname is not thrown away. The target is
|
|
rebuilt using the expanded path.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC30" HREF="make.html#TOC30">Writing Shell Commands with Directory Search</A></H3>
|
|
<P>
|
|
<A NAME="IDX169"></A>
|
|
<A NAME="IDX170"></A>
|
|
|
|
</P>
|
|
<P>
|
|
When a prerequisite is found in another directory through directory search,
|
|
this cannot change the commands of the rule; they will execute as written.
|
|
Therefore, you must write the commands with care so that they will look for
|
|
the prerequisite in the directory where <CODE>make</CODE> finds it.
|
|
|
|
</P>
|
|
<P>
|
|
This is done with the <STRONG>automatic variables</STRONG> such as <SAMP>`$^'</SAMP>
|
|
(see section <A HREF="make.html#SEC101">Automatic Variables</A>).
|
|
For instance, the value of <SAMP>`$^'</SAMP> is a
|
|
list of all the prerequisites of the rule, including the names of
|
|
the directories in which they were found, and the value of
|
|
<SAMP>`$@'</SAMP> is the target. Thus:
|
|
</P>
|
|
|
|
<PRE>
|
|
foo.o : foo.c
|
|
cc -c $(CFLAGS) $^ -o $@
|
|
</PRE>
|
|
|
|
<P>
|
|
(The variable <CODE>CFLAGS</CODE> exists so you can specify flags for C
|
|
compilation by implicit rules; we use it here for consistency so it will
|
|
affect all C compilations uniformly;
|
|
see section <A HREF="make.html#SEC96">Variables Used by Implicit Rules</A>.)
|
|
|
|
</P>
|
|
<P>
|
|
Often the prerequisites include header files as well, which you do not
|
|
want to mention in the commands. The automatic variable <SAMP>`$<'</SAMP> is
|
|
just the first prerequisite:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
VPATH = src:../headers
|
|
foo.o : foo.c defs.h hack.h
|
|
cc -c $(CFLAGS) $< -o $@
|
|
</PRE>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC31" HREF="make.html#TOC31">Directory Search and Implicit Rules</A></H3>
|
|
<P>
|
|
<A NAME="IDX171"></A>
|
|
<A NAME="IDX172"></A>
|
|
<A NAME="IDX173"></A>
|
|
<A NAME="IDX174"></A>
|
|
<A NAME="IDX175"></A>
|
|
<A NAME="IDX176"></A>
|
|
<A NAME="IDX177"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The search through the directories specified in <CODE>VPATH</CODE> or with
|
|
<CODE>vpath</CODE> also happens during consideration of implicit rules
|
|
(see section <A HREF="make.html#SEC93">Using Implicit Rules</A>).
|
|
|
|
</P>
|
|
<P>
|
|
For example, when a file <TT>`foo.o'</TT> has no explicit rule, <CODE>make</CODE>
|
|
considers implicit rules, such as the built-in rule to compile
|
|
<TT>`foo.c'</TT> if that file exists. If such a file is lacking in the
|
|
current directory, the appropriate directories are searched for it. If
|
|
<TT>`foo.c'</TT> exists (or is mentioned in the makefile) in any of the
|
|
directories, the implicit rule for C compilation is applied.
|
|
|
|
</P>
|
|
<P>
|
|
The commands of implicit rules normally use automatic variables as a
|
|
matter of necessity; consequently they will use the file names found by
|
|
directory search with no extra effort.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC32" HREF="make.html#TOC32">Directory Search for Link Libraries</A></H3>
|
|
<P>
|
|
<A NAME="IDX178"></A>
|
|
<A NAME="IDX179"></A>
|
|
<A NAME="IDX180"></A>
|
|
<A NAME="IDX181"></A>
|
|
<A NAME="IDX182"></A>
|
|
<A NAME="IDX183"></A>
|
|
<A NAME="IDX184"></A>
|
|
<A NAME="IDX185"></A>
|
|
<A NAME="IDX186"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Directory search applies in a special way to libraries used with the
|
|
linker. This special feature comes into play when you write a prerequisite
|
|
whose name is of the form <SAMP>`-l<VAR>name</VAR>'</SAMP>. (You can tell something
|
|
strange is going on here because the prerequisite is normally the name of a
|
|
file, and the <EM>file name</EM> of a library generally looks like
|
|
<TT>`lib<VAR>name</VAR>.a'</TT>, not like <SAMP>`-l<VAR>name</VAR>'</SAMP>.)
|
|
</P>
|
|
<P>
|
|
When a prerequisite's name has the form <SAMP>`-l<VAR>name</VAR>'</SAMP>, <CODE>make</CODE>
|
|
handles it specially by searching for the file <TT>`lib<VAR>name</VAR>.so'</TT> in
|
|
the current directory, in directories specified by matching <CODE>vpath</CODE>
|
|
search paths and the <CODE>VPATH</CODE> search path, and then in the
|
|
directories <TT>`/lib'</TT>, <TT>`/usr/lib'</TT>, and <TT>`<VAR>prefix</VAR>/lib'</TT>
|
|
(normally <TT>`/usr/local/lib'</TT>, but MS-DOS/MS-Windows versions of
|
|
<CODE>make</CODE> behave as if <VAR>prefix</VAR> is defined to be the root of the
|
|
DJGPP installation tree).
|
|
|
|
</P>
|
|
<P>
|
|
If that file is not found, then the file <TT>`lib<VAR>name</VAR>.a'</TT> is
|
|
searched for, in the same directories as above.
|
|
|
|
</P>
|
|
<P>
|
|
For example, if there is a <TT>`/usr/lib/libcurses.a'</TT> library on your
|
|
system (and no <TT>`/usr/lib/libcurses.so'</TT> file), then
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo : foo.c -lcurses
|
|
cc $^ -o $@
|
|
</PRE>
|
|
|
|
<P>
|
|
would cause the command <SAMP>`cc foo.c /usr/lib/libcurses.a -o foo'</SAMP> to
|
|
be executed when <TT>`foo'</TT> is older than <TT>`foo.c'</TT> or than
|
|
<TT>`/usr/lib/libcurses.a'</TT>.
|
|
</P>
|
|
<P>
|
|
Although the default set of files to be searched for is
|
|
<TT>`lib<VAR>name</VAR>.so'</TT> and <TT>`lib<VAR>name</VAR>.a'</TT>, this is customizable
|
|
via the <CODE>.LIBPATTERNS</CODE> variable. Each word in the value of this
|
|
variable is a pattern string. When a prerequisite like
|
|
<SAMP>`-l<VAR>name</VAR>'</SAMP> is seen, <CODE>make</CODE> will replace the percent in
|
|
each pattern in the list with <VAR>name</VAR> and perform the above directory
|
|
searches using that library filename. If no library is found, the next
|
|
word in the list will be used.
|
|
|
|
</P>
|
|
<P>
|
|
The default value for <CODE>.LIBPATTERNS</CODE> is "<SAMP>`lib%.so lib%.a'</SAMP>",
|
|
which provides the default behavior described above.
|
|
|
|
</P>
|
|
<P>
|
|
You can turn off link library expansion completely by setting this
|
|
variable to an empty value.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC33" HREF="make.html#TOC33">Phony Targets</A></H2>
|
|
<P>
|
|
<A NAME="IDX187"></A>
|
|
<A NAME="IDX188"></A>
|
|
<A NAME="IDX189"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A phony target is one that is not really the name of a file. It is just a
|
|
name for some commands to be executed when you make an explicit request.
|
|
There are two reasons to use a phony target: to avoid a conflict with
|
|
a file of the same name, and to improve performance.
|
|
|
|
</P>
|
|
<P>
|
|
If you write a rule whose commands will not create the target file, the
|
|
commands will be executed every time the target comes up for remaking.
|
|
Here is an example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
clean:
|
|
rm *.o temp
|
|
</PRE>
|
|
|
|
<P>
|
|
Because the <CODE>rm</CODE> command does not create a file named <TT>`clean'</TT>,
|
|
probably no such file will ever exist. Therefore, the <CODE>rm</CODE> command
|
|
will be executed every time you say <SAMP>`make clean'</SAMP>.
|
|
<A NAME="IDX190"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX191"></A>
|
|
The phony target will cease to work if anything ever does create a file
|
|
named <TT>`clean'</TT> in this directory. Since it has no prerequisites, the
|
|
file <TT>`clean'</TT> would inevitably be considered up to date, and its
|
|
commands would not be executed. To avoid this problem, you can explicitly
|
|
declare the target to be phony, using the special target <CODE>.PHONY</CODE>
|
|
(see section <A HREF="make.html#SEC36">Special Built-in Target Names</A>) as follows:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
.PHONY : clean
|
|
</PRE>
|
|
|
|
<P>
|
|
Once this is done, <SAMP>`make clean'</SAMP> will run the commands regardless of
|
|
whether there is a file named <TT>`clean'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
Since it knows that phony targets do not name actual files that could be
|
|
remade from other files, <CODE>make</CODE> skips the implicit rule search for
|
|
phony targets (see section <A HREF="make.html#SEC93">Using Implicit Rules</A>). This is why declaring a target
|
|
phony is good for performance, even if you are not worried about the
|
|
actual file existing.
|
|
|
|
</P>
|
|
<P>
|
|
Thus, you first write the line that states that <CODE>clean</CODE> is a
|
|
phony target, then you write the rule, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
.PHONY: clean
|
|
clean:
|
|
rm *.o temp
|
|
</PRE>
|
|
|
|
<P>
|
|
Another example of the usefulness of phony targets is in conjunction
|
|
with recursive invocations of <CODE>make</CODE>. In this case the makefile
|
|
will often contain a variable which lists a number of subdirectories to
|
|
be built. One way to handle this is with one rule whose command is a
|
|
shell loop over the subdirectories, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
SUBDIRS = foo bar baz
|
|
|
|
subdirs:
|
|
for dir in $(SUBDIRS); do \
|
|
$(MAKE) -C $$dir; \
|
|
done
|
|
</PRE>
|
|
|
|
<P>
|
|
There are a few of problems with this method, however. First, any error
|
|
detected in a submake is not noted by this rule, so it will continue to
|
|
build the rest of the directories even when one fails. This can be
|
|
overcome by adding shell commands to note the error and exit, but then
|
|
it will do so even if <CODE>make</CODE> is invoked with the <CODE>-k</CODE> option,
|
|
which is unfortunate. Second, and perhaps more importantly, you cannot
|
|
take advantage of the parallel build capabilities of make using this
|
|
method, since there is only one rule.
|
|
|
|
</P>
|
|
<P>
|
|
By declaring the subdirectories as phony targets (you must do this as
|
|
the subdirectory obviously always exists; otherwise it won't be built)
|
|
you can remove these problems:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
SUBDIRS = foo bar baz
|
|
|
|
.PHONY: subdirs $(SUBDIRS)
|
|
|
|
subdirs: $(SUBDIRS)
|
|
|
|
$(SUBDIRS):
|
|
$(MAKE) -C $
|
|
|
|
foo: baz
|
|
</PRE>
|
|
|
|
<P>
|
|
Here we've also declared that the <TT>`foo'</TT> subdirectory cannot be
|
|
built until after the <TT>`baz'</TT> subdirectory is complete; this kind of
|
|
relationship declaration is particularly important when attempting
|
|
parallel builds.
|
|
|
|
</P>
|
|
<P>
|
|
A phony target should not be a prerequisite of a real target file; if it
|
|
is, its commands are run every time <CODE>make</CODE> goes to update that
|
|
file. As long as a phony target is never a prerequisite of a real
|
|
target, the phony target commands will be executed only when the phony
|
|
target is a specified goal (see section <A HREF="make.html#SEC87">Arguments to Specify the Goals</A>).
|
|
|
|
</P>
|
|
<P>
|
|
Phony targets can have prerequisites. When one directory contains multiple
|
|
programs, it is most convenient to describe all of the programs in one
|
|
makefile <TT>`./Makefile'</TT>. Since the target remade by default will be the
|
|
first one in the makefile, it is common to make this a phony target named
|
|
<SAMP>`all'</SAMP> and give it, as prerequisites, all the individual programs. For
|
|
example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
all : prog1 prog2 prog3
|
|
.PHONY : all
|
|
|
|
prog1 : prog1.o utils.o
|
|
cc -o prog1 prog1.o utils.o
|
|
|
|
prog2 : prog2.o
|
|
cc -o prog2 prog2.o
|
|
|
|
prog3 : prog3.o sort.o utils.o
|
|
cc -o prog3 prog3.o sort.o utils.o
|
|
</PRE>
|
|
|
|
<P>
|
|
Now you can say just <SAMP>`make'</SAMP> to remake all three programs, or specify
|
|
as arguments the ones to remake (as in <SAMP>`make prog1 prog3'</SAMP>).
|
|
|
|
</P>
|
|
<P>
|
|
When one phony target is a prerequisite of another, it serves as a subroutine
|
|
of the other. For example, here <SAMP>`make cleanall'</SAMP> will delete the
|
|
object files, the difference files, and the file <TT>`program'</TT>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
.PHONY: cleanall cleanobj cleandiff
|
|
|
|
cleanall : cleanobj cleandiff
|
|
rm program
|
|
|
|
cleanobj :
|
|
rm *.o
|
|
|
|
cleandiff :
|
|
rm *.diff
|
|
</PRE>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC34" HREF="make.html#TOC34">Rules without Commands or Prerequisites</A></H2>
|
|
<P>
|
|
<A NAME="IDX192"></A>
|
|
<A NAME="IDX193"></A>
|
|
<A NAME="IDX194"></A>
|
|
<A NAME="IDX195"></A>
|
|
|
|
</P>
|
|
<P>
|
|
If a rule has no prerequisites or commands, and the target of the rule
|
|
is a nonexistent file, then <CODE>make</CODE> imagines this target to have
|
|
been updated whenever its rule is run. This implies that all targets
|
|
depending on this one will always have their commands run.
|
|
|
|
</P>
|
|
<P>
|
|
An example will illustrate this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
clean: FORCE
|
|
rm $(objects)
|
|
FORCE:
|
|
</PRE>
|
|
|
|
<P>
|
|
Here the target <SAMP>`FORCE'</SAMP> satisfies the special conditions, so the
|
|
target <TT>`clean'</TT> that depends on it is forced to run its commands.
|
|
There is nothing special about the name <SAMP>`FORCE'</SAMP>, but that is one name
|
|
commonly used this way.
|
|
|
|
</P>
|
|
<P>
|
|
As you can see, using <SAMP>`FORCE'</SAMP> this way has the same results as using
|
|
<SAMP>`.PHONY: clean'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
Using <SAMP>`.PHONY'</SAMP> is more explicit and more efficient. However,
|
|
other versions of <CODE>make</CODE> do not support <SAMP>`.PHONY'</SAMP>; thus
|
|
<SAMP>`FORCE'</SAMP> appears in many makefiles. See section <A HREF="make.html#SEC33">Phony Targets</A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC35" HREF="make.html#TOC35">Empty Target Files to Record Events</A></H2>
|
|
<P>
|
|
<A NAME="IDX196"></A>
|
|
<A NAME="IDX197"></A>
|
|
<A NAME="IDX198"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The <STRONG>empty target</STRONG> is a variant of the phony target; it is used to hold
|
|
commands for an action that you request explicitly from time to time.
|
|
Unlike a phony target, this target file can really exist; but the file's
|
|
contents do not matter, and usually are empty.
|
|
|
|
</P>
|
|
<P>
|
|
The purpose of the empty target file is to record, with its
|
|
last-modification time, when the rule's commands were last executed. It
|
|
does so because one of the commands is a <CODE>touch</CODE> command to update the
|
|
target file.
|
|
|
|
</P>
|
|
<P>
|
|
The empty target file should have some prerequisites (otherwise it
|
|
doesn't make sense). When you ask to remake the empty target, the
|
|
commands are executed if any prerequisite is more recent than the target;
|
|
in other words, if a prerequisite has changed since the last time you
|
|
remade the target. Here is an example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
print: foo.c bar.c
|
|
lpr -p $?
|
|
touch print
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX199"></A>
|
|
<A NAME="IDX200"></A>
|
|
<A NAME="IDX201"></A>
|
|
|
|
</P>
|
|
<P>
|
|
With this rule, <SAMP>`make print'</SAMP> will execute the <CODE>lpr</CODE> command if
|
|
either source file has changed since the last <SAMP>`make print'</SAMP>. The
|
|
automatic variable <SAMP>`$?'</SAMP> is used to print only those files that have
|
|
changed (see section <A HREF="make.html#SEC101">Automatic Variables</A>).
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC36" HREF="make.html#TOC36">Special Built-in Target Names</A></H2>
|
|
<P>
|
|
<A NAME="IDX202"></A>
|
|
<A NAME="IDX203"></A>
|
|
<A NAME="IDX204"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Certain names have special meanings if they appear as targets.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>.PHONY</CODE>
|
|
<DD>
|
|
<A NAME="IDX205"></A>
|
|
|
|
|
|
The prerequisites of the special target <CODE>.PHONY</CODE> are considered to
|
|
be phony targets. When it is time to consider such a target,
|
|
<CODE>make</CODE> will run its commands unconditionally, regardless of
|
|
whether a file with that name exists or what its last-modification
|
|
time is. See section <A HREF="make.html#SEC33">Phony Targets</A>.
|
|
|
|
<A NAME="IDX206"></A>
|
|
<DT><CODE>.SUFFIXES</CODE>
|
|
<DD>
|
|
The prerequisites of the special target <CODE>.SUFFIXES</CODE> are the list
|
|
of suffixes to be used in checking for suffix rules.
|
|
See section <A HREF="make.html#SEC106">Old-Fashioned Suffix Rules</A>.
|
|
|
|
<A NAME="IDX207"></A>
|
|
<DT><CODE>.DEFAULT</CODE>
|
|
<DD>
|
|
The commands specified for <CODE>.DEFAULT</CODE> are used for any target for
|
|
which no rules are found (either explicit rules or implicit rules).
|
|
See section <A HREF="make.html#SEC105">Defining Last-Resort Default Rules</A>. If <CODE>.DEFAULT</CODE> commands are specified, every
|
|
file mentioned as a prerequisite, but not as a target in a rule, will have
|
|
these commands executed on its behalf. See section <A HREF="make.html#SEC107">Implicit Rule Search Algorithm</A>.
|
|
|
|
<A NAME="IDX208"></A>
|
|
<DT><CODE>.PRECIOUS</CODE>
|
|
<DD>
|
|
<A NAME="IDX209"></A>
|
|
<A NAME="IDX210"></A>
|
|
|
|
The targets which <CODE>.PRECIOUS</CODE> depends on are given the following
|
|
special treatment: if <CODE>make</CODE> is killed or interrupted during the
|
|
execution of their commands, the target is not deleted.
|
|
See section <A HREF="make.html#SEC49">Interrupting or Killing <CODE>make</CODE></A>. Also, if the
|
|
target is an intermediate file, it will not be deleted after it is no
|
|
longer needed, as is normally done. See section <A HREF="make.html#SEC97">Chains of Implicit Rules</A>. In this latter respect it overlaps with the
|
|
<CODE>.SECONDARY</CODE> special target.
|
|
|
|
You can also list the target pattern of an implicit rule (such as
|
|
<SAMP>`%.o'</SAMP>) as a prerequisite file of the special target <CODE>.PRECIOUS</CODE>
|
|
to preserve intermediate files created by rules whose target patterns
|
|
match that file's name.
|
|
|
|
<A NAME="IDX211"></A>
|
|
<DT><CODE>.INTERMEDIATE</CODE>
|
|
<DD>
|
|
<A NAME="IDX212"></A>
|
|
|
|
The targets which <CODE>.INTERMEDIATE</CODE> depends on are treated as
|
|
intermediate files. See section <A HREF="make.html#SEC97">Chains of Implicit Rules</A>.
|
|
<CODE>.INTERMEDIATE</CODE> with no prerequisites has no effect.
|
|
|
|
<A NAME="IDX213"></A>
|
|
<DT><CODE>.SECONDARY</CODE>
|
|
<DD>
|
|
<A NAME="IDX214"></A>
|
|
<A NAME="IDX215"></A>
|
|
|
|
The targets which <CODE>.SECONDARY</CODE> depends on are treated as
|
|
intermediate files, except that they are never automatically deleted.
|
|
See section <A HREF="make.html#SEC97">Chains of Implicit Rules</A>.
|
|
|
|
<CODE>.SECONDARY</CODE> with no prerequisites causes all targets to be treated
|
|
as secondary (i.e., no target is removed because it is considered
|
|
intermediate).
|
|
|
|
<A NAME="IDX216"></A>
|
|
<DT><CODE>.DELETE_ON_ERROR</CODE>
|
|
<DD>
|
|
<A NAME="IDX217"></A>
|
|
|
|
If <CODE>.DELETE_ON_ERROR</CODE> is mentioned as a target anywhere in the
|
|
makefile, then <CODE>make</CODE> will delete the target of a rule if it has
|
|
changed and its commands exit with a nonzero exit status, just as it
|
|
does when it receives a signal. See section <A HREF="make.html#SEC48">Errors in Commands</A>.
|
|
|
|
<A NAME="IDX218"></A>
|
|
<DT><CODE>.IGNORE</CODE>
|
|
<DD>
|
|
If you specify prerequisites for <CODE>.IGNORE</CODE>, then <CODE>make</CODE> will
|
|
ignore errors in execution of the commands run for those particular
|
|
files. The commands for <CODE>.IGNORE</CODE> are not meaningful.
|
|
|
|
If mentioned as a target with no prerequisites, <CODE>.IGNORE</CODE> says to
|
|
ignore errors in execution of commands for all files. This usage of
|
|
<SAMP>`.IGNORE'</SAMP> is supported only for historical compatibility. Since
|
|
this affects every command in the makefile, it is not very useful; we
|
|
recommend you use the more selective ways to ignore errors in specific
|
|
commands. See section <A HREF="make.html#SEC48">Errors in Commands</A>.
|
|
|
|
<A NAME="IDX219"></A>
|
|
<DT><CODE>.SILENT</CODE>
|
|
<DD>
|
|
If you specify prerequisites for <CODE>.SILENT</CODE>, then <CODE>make</CODE> will
|
|
not print the commands to remake those particular files before executing
|
|
them. The commands for <CODE>.SILENT</CODE> are not meaningful.
|
|
|
|
If mentioned as a target with no prerequisites, <CODE>.SILENT</CODE> says not
|
|
to print any commands before executing them. This usage of
|
|
<SAMP>`.SILENT'</SAMP> is supported only for historical compatibility. We
|
|
recommend you use the more selective ways to silence specific commands.
|
|
See section <A HREF="make.html#SEC45">Command Echoing</A>. If you want to silence all commands
|
|
for a particular run of <CODE>make</CODE>, use the <SAMP>`-s'</SAMP> or
|
|
<SAMP>`--silent'</SAMP> option (see section <A HREF="make.html#SEC92">Summary of Options</A>).
|
|
|
|
<A NAME="IDX220"></A>
|
|
<DT><CODE>.EXPORT_ALL_VARIABLES</CODE>
|
|
<DD>
|
|
Simply by being mentioned as a target, this tells <CODE>make</CODE> to
|
|
export all variables to child processes by default.
|
|
See section <A HREF="make.html#SEC52">Communicating Variables to a Sub-<CODE>make</CODE></A>.
|
|
|
|
<A NAME="IDX221"></A>
|
|
<DT><CODE>.NOTPARALLEL</CODE>
|
|
<DD>
|
|
<A NAME="IDX222"></A>
|
|
|
|
If <CODE>.NOTPARALLEL</CODE> is mentioned as a target, then this invocation of
|
|
<CODE>make</CODE> will be run serially, even if the <SAMP>`-j'</SAMP> option is
|
|
given. Any recursively invoked <CODE>make</CODE> command will still be run in
|
|
parallel (unless its makefile contains this target). Any prerequisites
|
|
on this target are ignored.
|
|
</DL>
|
|
|
|
<P>
|
|
Any defined implicit rule suffix also counts as a special target if it
|
|
appears as a target, and so does the concatenation of two suffixes, such
|
|
as <SAMP>`.c.o'</SAMP>. These targets are suffix rules, an obsolete way of
|
|
defining implicit rules (but a way still widely used). In principle, any
|
|
target name could be special in this way if you break it in two and add
|
|
both pieces to the suffix list. In practice, suffixes normally begin with
|
|
<SAMP>`.'</SAMP>, so these special target names also begin with <SAMP>`.'</SAMP>.
|
|
See section <A HREF="make.html#SEC106">Old-Fashioned Suffix Rules</A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC37" HREF="make.html#TOC37">Multiple Targets in a Rule</A></H2>
|
|
<P>
|
|
<A NAME="IDX223"></A>
|
|
<A NAME="IDX224"></A>
|
|
<A NAME="IDX225"></A>
|
|
<A NAME="IDX226"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A rule with multiple targets is equivalent to writing many rules, each with
|
|
one target, and all identical aside from that. The same commands apply to
|
|
all the targets, but their effects may vary because you can substitute the
|
|
actual target name into the command using <SAMP>`$@'</SAMP>. The rule contributes
|
|
the same prerequisites to all the targets also.
|
|
|
|
</P>
|
|
<P>
|
|
This is useful in two cases.
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
You want just prerequisites, no commands. For example:
|
|
|
|
|
|
<PRE>
|
|
kbd.o command.o files.o: command.h
|
|
</PRE>
|
|
|
|
gives an additional prerequisite to each of the three object files
|
|
mentioned.
|
|
|
|
<LI>
|
|
|
|
Similar commands work for all the targets. The commands do not need
|
|
to be absolutely identical, since the automatic variable <SAMP>`$@'</SAMP>
|
|
can be used to substitute the particular target to be remade into the
|
|
commands (see section <A HREF="make.html#SEC101">Automatic Variables</A>). For example:
|
|
|
|
|
|
<PRE>
|
|
bigoutput littleoutput : text.g
|
|
generate text.g -$(subst output,,$@) > $@
|
|
</PRE>
|
|
|
|
<A NAME="IDX227"></A>
|
|
|
|
is equivalent to
|
|
|
|
|
|
<PRE>
|
|
bigoutput : text.g
|
|
generate text.g -big > bigoutput
|
|
littleoutput : text.g
|
|
generate text.g -little > littleoutput
|
|
</PRE>
|
|
|
|
Here we assume the hypothetical program <CODE>generate</CODE> makes two
|
|
types of output, one if given <SAMP>`-big'</SAMP> and one if given
|
|
<SAMP>`-little'</SAMP>.
|
|
See section <A HREF="make.html#SEC77">Functions for String Substitution and Analysis</A>,
|
|
for an explanation of the <CODE>subst</CODE> function.
|
|
</UL>
|
|
|
|
<P>
|
|
Suppose you would like to vary the prerequisites according to the target,
|
|
much as the variable <SAMP>`$@'</SAMP> allows you to vary the commands.
|
|
You cannot do this with multiple targets in an ordinary rule, but you can
|
|
do it with a <STRONG>static pattern rule</STRONG>.
|
|
See section <A HREF="make.html#SEC39">Static Pattern Rules</A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC38" HREF="make.html#TOC38">Multiple Rules for One Target</A></H2>
|
|
<P>
|
|
<A NAME="IDX228"></A>
|
|
<A NAME="IDX229"></A>
|
|
<A NAME="IDX230"></A>
|
|
<A NAME="IDX231"></A>
|
|
|
|
</P>
|
|
<P>
|
|
One file can be the target of several rules. All the prerequisites
|
|
mentioned in all the rules are merged into one list of prerequisites for
|
|
the target. If the target is older than any prerequisite from any rule,
|
|
the commands are executed.
|
|
|
|
</P>
|
|
<P>
|
|
There can only be one set of commands to be executed for a file.
|
|
If more than one rule gives commands for the same file,
|
|
<CODE>make</CODE> uses the last set given and prints an error message.
|
|
(As a special case, if the file's name begins with a dot, no
|
|
error message is printed. This odd behavior is only for
|
|
compatibility with other implementations of <CODE>make</CODE>.)
|
|
There is no reason to
|
|
write your makefiles this way; that is why <CODE>make</CODE> gives you
|
|
an error message.
|
|
</P>
|
|
<P>
|
|
An extra rule with just prerequisites can be used to give a few extra
|
|
prerequisites to many files at once. For example, one usually has a
|
|
variable named <CODE>objects</CODE> containing a list of all the compiler output
|
|
files in the system being made. An easy way to say that all of them must
|
|
be recompiled if <TT>`config.h'</TT> changes is to write the following:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects = foo.o bar.o
|
|
foo.o : defs.h
|
|
bar.o : defs.h test.h
|
|
$(objects) : config.h
|
|
</PRE>
|
|
|
|
<P>
|
|
This could be inserted or taken out without changing the rules that really
|
|
specify how to make the object files, making it a convenient form to use if
|
|
you wish to add the additional prerequisite intermittently.
|
|
|
|
</P>
|
|
<P>
|
|
Another wrinkle is that the additional prerequisites could be specified with
|
|
a variable that you set with a command argument to <CODE>make</CODE>
|
|
(see section <A HREF="make.html#SEC90">Overriding Variables</A>). For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
extradeps=
|
|
$(objects) : $(extradeps)
|
|
</PRE>
|
|
|
|
<P>
|
|
means that the command <SAMP>`make extradeps=foo.h'</SAMP> will consider
|
|
<TT>`foo.h'</TT> as a prerequisite of each object file, but plain <SAMP>`make'</SAMP>
|
|
will not.
|
|
|
|
</P>
|
|
<P>
|
|
If none of the explicit rules for a target has commands, then <CODE>make</CODE>
|
|
searches for an applicable implicit rule to find some commands
|
|
see section <A HREF="make.html#SEC93">Using Implicit Rules</A>).
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC39" HREF="make.html#TOC39">Static Pattern Rules</A></H2>
|
|
<P>
|
|
<A NAME="IDX232"></A>
|
|
<A NAME="IDX233"></A>
|
|
<A NAME="IDX234"></A>
|
|
<A NAME="IDX235"></A>
|
|
<A NAME="IDX236"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<STRONG>Static pattern rules</STRONG> are rules which specify multiple targets and
|
|
construct the prerequisite names for each target based on the target name.
|
|
They are more general than ordinary rules with multiple targets because the
|
|
targets do not have to have identical prerequisites. Their prerequisites must
|
|
be <EM>analogous</EM>, but not necessarily <EM>identical</EM>.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC40" HREF="make.html#TOC40">Syntax of Static Pattern Rules</A></H3>
|
|
<P>
|
|
<A NAME="IDX237"></A>
|
|
<A NAME="IDX238"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Here is the syntax of a static pattern rule:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>targets</VAR> ...: <VAR>target-pattern</VAR>: <VAR>dep-patterns</VAR> ...
|
|
<VAR>commands</VAR>
|
|
...
|
|
</PRE>
|
|
|
|
<P>
|
|
The <VAR>targets</VAR> list specifies the targets that the rule applies to.
|
|
The targets can contain wildcard characters, just like the targets of
|
|
ordinary rules (see section <A HREF="make.html#SEC22">Using Wildcard Characters in File Names</A>).
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX239"></A>
|
|
<A NAME="IDX240"></A>
|
|
The <VAR>target-pattern</VAR> and <VAR>dep-patterns</VAR> say how to compute the
|
|
prerequisites of each target. Each target is matched against the
|
|
<VAR>target-pattern</VAR> to extract a part of the target name, called the
|
|
<STRONG>stem</STRONG>. This stem is substituted into each of the <VAR>dep-patterns</VAR>
|
|
to make the prerequisite names (one from each <VAR>dep-pattern</VAR>).
|
|
|
|
</P>
|
|
<P>
|
|
Each pattern normally contains the character <SAMP>`%'</SAMP> just once. When the
|
|
<VAR>target-pattern</VAR> matches a target, the <SAMP>`%'</SAMP> can match any part of
|
|
the target name; this part is called the <STRONG>stem</STRONG>. The rest of the
|
|
pattern must match exactly. For example, the target <TT>`foo.o'</TT> matches
|
|
the pattern <SAMP>`%.o'</SAMP>, with <SAMP>`foo'</SAMP> as the stem. The targets
|
|
<TT>`foo.c'</TT> and <TT>`foo.out'</TT> do not match that pattern.
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX241"></A>
|
|
The prerequisite names for each target are made by substituting the stem
|
|
for the <SAMP>`%'</SAMP> in each prerequisite pattern. For example, if one
|
|
prerequisite pattern is <TT>`%.c'</TT>, then substitution of the stem
|
|
<SAMP>`foo'</SAMP> gives the prerequisite name <TT>`foo.c'</TT>. It is legitimate
|
|
to write a prerequisite pattern that does not contain <SAMP>`%'</SAMP>; then this
|
|
prerequisite is the same for all targets.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX242"></A>
|
|
<A NAME="IDX243"></A>
|
|
<A NAME="IDX244"></A>
|
|
<A NAME="IDX245"></A>
|
|
<A NAME="IDX246"></A>
|
|
<SAMP>`%'</SAMP> characters in pattern rules can be quoted with preceding
|
|
backslashes (<SAMP>`\'</SAMP>). Backslashes that would otherwise quote <SAMP>`%'</SAMP>
|
|
characters can be quoted with more backslashes. Backslashes that quote
|
|
<SAMP>`%'</SAMP> characters or other backslashes are removed from the pattern
|
|
before it is compared to file names or has a stem substituted into it.
|
|
Backslashes that are not in danger of quoting <SAMP>`%'</SAMP> characters go
|
|
unmolested. For example, the pattern <TT>`the\%weird\\%pattern\\'</TT> has
|
|
<SAMP>`the%weird\'</SAMP> preceding the operative <SAMP>`%'</SAMP> character, and
|
|
<SAMP>`pattern\\'</SAMP> following it. The final two backslashes are left alone
|
|
because they cannot affect any <SAMP>`%'</SAMP> character.
|
|
</P>
|
|
<P>
|
|
Here is an example, which compiles each of <TT>`foo.o'</TT> and <TT>`bar.o'</TT>
|
|
from the corresponding <TT>`.c'</TT> file:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects = foo.o bar.o
|
|
|
|
all: $(objects)
|
|
|
|
$(objects): %.o: %.c
|
|
$(CC) -c $(CFLAGS) $< -o $@
|
|
</PRE>
|
|
|
|
<P>
|
|
Here <SAMP>`$<'</SAMP> is the automatic variable that holds the name of the
|
|
prerequisite and <SAMP>`$@'</SAMP> is the automatic variable that holds the name
|
|
of the target; see section <A HREF="make.html#SEC101">Automatic Variables</A>.
|
|
|
|
</P>
|
|
<P>
|
|
Each target specified must match the target pattern; a warning is issued
|
|
for each target that does not. If you have a list of files, only some of
|
|
which will match the pattern, you can use the <CODE>filter</CODE> function to
|
|
remove nonmatching file names (see section <A HREF="make.html#SEC77">Functions for String Substitution and Analysis</A>):
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
files = foo.elc bar.o lose.o
|
|
|
|
$(filter %.o,$(files)): %.o: %.c
|
|
$(CC) -c $(CFLAGS) $< -o $@
|
|
$(filter %.elc,$(files)): %.elc: %.el
|
|
emacs -f batch-byte-compile $<
|
|
</PRE>
|
|
|
|
<P>
|
|
In this example the result of <SAMP>`$(filter %.o,$(files))'</SAMP> is
|
|
<TT>`bar.o lose.o'</TT>, and the first static pattern rule causes each of
|
|
these object files to be updated by compiling the corresponding C source
|
|
file. The result of <SAMP>`$(filter %.elc,$(files))'</SAMP> is
|
|
<TT>`foo.elc'</TT>, so that file is made from <TT>`foo.el'</TT>.
|
|
</P>
|
|
<P>
|
|
Another example shows how to use <CODE>$*</CODE> in static pattern rules:
|
|
<A NAME="IDX247"></A>
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
bigoutput littleoutput : %output : text.g
|
|
generate text.g -$* > $@
|
|
</PRE>
|
|
|
|
<P>
|
|
When the <CODE>generate</CODE> command is run, <CODE>$*</CODE> will expand to the
|
|
stem, either <SAMP>`big'</SAMP> or <SAMP>`little'</SAMP>.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC41" HREF="make.html#TOC41">Static Pattern Rules versus Implicit Rules</A></H3>
|
|
<P>
|
|
<A NAME="IDX248"></A>
|
|
<A NAME="IDX249"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A static pattern rule has much in common with an implicit rule defined as a
|
|
pattern rule (see section <A HREF="make.html#SEC98">Defining and Redefining Pattern Rules</A>).
|
|
Both have a pattern for the target and patterns for constructing the
|
|
names of prerequisites. The difference is in how <CODE>make</CODE> decides
|
|
<EM>when</EM> the rule applies.
|
|
|
|
</P>
|
|
<P>
|
|
An implicit rule <EM>can</EM> apply to any target that matches its pattern,
|
|
but it <EM>does</EM> apply only when the target has no commands otherwise
|
|
specified, and only when the prerequisites can be found. If more than one
|
|
implicit rule appears applicable, only one applies; the choice depends on
|
|
the order of rules.
|
|
|
|
</P>
|
|
<P>
|
|
By contrast, a static pattern rule applies to the precise list of targets
|
|
that you specify in the rule. It cannot apply to any other target and it
|
|
invariably does apply to each of the targets specified. If two conflicting
|
|
rules apply, and both have commands, that's an error.
|
|
|
|
</P>
|
|
<P>
|
|
The static pattern rule can be better than an implicit rule for these
|
|
reasons:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
You may wish to override the usual implicit rule for a few
|
|
files whose names cannot be categorized syntactically but
|
|
can be given in an explicit list.
|
|
|
|
<LI>
|
|
|
|
If you cannot be sure of the precise contents of the directories
|
|
you are using, you may not be sure which other irrelevant files
|
|
might lead <CODE>make</CODE> to use the wrong implicit rule. The choice
|
|
might depend on the order in which the implicit rule search is done.
|
|
With static pattern rules, there is no uncertainty: each rule applies
|
|
to precisely the targets specified.
|
|
</UL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC42" HREF="make.html#TOC42">Double-Colon Rules</A></H2>
|
|
<P>
|
|
<A NAME="IDX250"></A>
|
|
<A NAME="IDX251"></A>
|
|
<A NAME="IDX252"></A>
|
|
<A NAME="IDX253"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<STRONG>Double-colon</STRONG> rules are rules written with <SAMP>`::'</SAMP> instead of
|
|
<SAMP>`:'</SAMP> after the target names. They are handled differently from
|
|
ordinary rules when the same target appears in more than one rule.
|
|
|
|
</P>
|
|
<P>
|
|
When a target appears in multiple rules, all the rules must be the same
|
|
type: all ordinary, or all double-colon. If they are double-colon, each of
|
|
them is independent of the others. Each double-colon rule's commands are
|
|
executed if the target is older than any prerequisites of that rule. This
|
|
can result in executing none, any, or all of the double-colon rules.
|
|
|
|
</P>
|
|
<P>
|
|
Double-colon rules with the same target are in fact completely separate
|
|
from one another. Each double-colon rule is processed individually, just
|
|
as rules with different targets are processed.
|
|
|
|
</P>
|
|
<P>
|
|
The double-colon rules for a target are executed in the order they appear
|
|
in the makefile. However, the cases where double-colon rules really make
|
|
sense are those where the order of executing the commands would not matter.
|
|
|
|
</P>
|
|
<P>
|
|
Double-colon rules are somewhat obscure and not often very useful; they
|
|
provide a mechanism for cases in which the method used to update a target
|
|
differs depending on which prerequisite files caused the update, and such
|
|
cases are rare.
|
|
|
|
</P>
|
|
<P>
|
|
Each double-colon rule should specify commands; if it does not, an
|
|
implicit rule will be used if one applies.
|
|
See section <A HREF="make.html#SEC93">Using Implicit Rules</A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC43" HREF="make.html#TOC43">Generating Prerequisites Automatically</A></H2>
|
|
<P>
|
|
<A NAME="IDX254"></A>
|
|
<A NAME="IDX255"></A>
|
|
<A NAME="IDX256"></A>
|
|
|
|
</P>
|
|
<P>
|
|
In the makefile for a program, many of the rules you need to write often
|
|
say only that some object file depends on some header
|
|
file. For example, if <TT>`main.c'</TT> uses <TT>`defs.h'</TT> via an
|
|
<CODE>#include</CODE>, you would write:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
main.o: defs.h
|
|
</PRE>
|
|
|
|
<P>
|
|
You need this rule so that <CODE>make</CODE> knows that it must remake
|
|
<TT>`main.o'</TT> whenever <TT>`defs.h'</TT> changes. You can see that for a
|
|
large program you would have to write dozens of such rules in your
|
|
makefile. And, you must always be very careful to update the makefile
|
|
every time you add or remove an <CODE>#include</CODE>.
|
|
<A NAME="IDX257"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX258"></A>
|
|
To avoid this hassle, most modern C compilers can write these rules for
|
|
you, by looking at the <CODE>#include</CODE> lines in the source files.
|
|
Usually this is done with the <SAMP>`-M'</SAMP> option to the compiler.
|
|
For example, the command:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
cc -M main.c
|
|
</PRE>
|
|
|
|
<P>
|
|
generates the output:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
main.o : main.c defs.h
|
|
</PRE>
|
|
|
|
<P>
|
|
Thus you no longer have to write all those rules yourself.
|
|
The compiler will do it for you.
|
|
|
|
</P>
|
|
<P>
|
|
Note that such a prerequisite constitutes mentioning <TT>`main.o'</TT> in a
|
|
makefile, so it can never be considered an intermediate file by implicit
|
|
rule search. This means that <CODE>make</CODE> won't ever remove the file
|
|
after using it; see section <A HREF="make.html#SEC97">Chains of Implicit Rules</A>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX259"></A>
|
|
With old <CODE>make</CODE> programs, it was traditional practice to use this
|
|
compiler feature to generate prerequisites on demand with a command like
|
|
<SAMP>`make depend'</SAMP>. That command would create a file <TT>`depend'</TT>
|
|
containing all the automatically-generated prerequisites; then the
|
|
makefile could use <CODE>include</CODE> to read them in (see section <A HREF="make.html#SEC15">Including Other Makefiles</A>).
|
|
|
|
</P>
|
|
<P>
|
|
In GNU <CODE>make</CODE>, the feature of remaking makefiles makes this
|
|
practice obsolete--you need never tell <CODE>make</CODE> explicitly to
|
|
regenerate the prerequisites, because it always regenerates any makefile
|
|
that is out of date. See section <A HREF="make.html#SEC17">How Makefiles Are Remade</A>.
|
|
|
|
</P>
|
|
<P>
|
|
The practice we recommend for automatic prerequisite generation is to have
|
|
one makefile corresponding to each source file. For each source file
|
|
<TT>`<VAR>name</VAR>.c'</TT> there is a makefile <TT>`<VAR>name</VAR>.d'</TT> which lists
|
|
what files the object file <TT>`<VAR>name</VAR>.o'</TT> depends on. That way
|
|
only the source files that have changed need to be rescanned to produce
|
|
the new prerequisites.
|
|
|
|
</P>
|
|
<P>
|
|
Here is the pattern rule to generate a file of prerequisites (i.e., a makefile)
|
|
called <TT>`<VAR>name</VAR>.d'</TT> from a C source file called <TT>`<VAR>name</VAR>.c'</TT>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
%.d: %.c
|
|
set -e; $(CC) -M $(CPPFLAGS) $< \
|
|
| sed 's/\($*\)\.o[ :]*/\1.o $@ : /g' > $@; \
|
|
[ -s $@ ] || rm -f $@
|
|
</PRE>
|
|
|
|
<P>
|
|
See section <A HREF="make.html#SEC98">Defining and Redefining Pattern Rules</A>, for information on defining pattern rules. The
|
|
<SAMP>`-e'</SAMP> flag to the shell makes it exit immediately if the
|
|
<CODE>$(CC)</CODE> command fails (exits with a nonzero status). Normally the
|
|
shell exits with the status of the last command in the pipeline
|
|
(<CODE>sed</CODE> in this case), so <CODE>make</CODE> would not notice a nonzero
|
|
status from the compiler.
|
|
<A NAME="IDX260"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX261"></A>
|
|
With the GNU C compiler, you may wish to use the <SAMP>`-MM'</SAMP> flag instead
|
|
of <SAMP>`-M'</SAMP>. This omits prerequisites on system header files.
|
|
See section `Options Controlling the Preprocessor' in <CITE>Using GNU CC</CITE>, for details.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX262"></A>
|
|
The purpose of the <CODE>sed</CODE> command is to translate (for example):
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
main.o : main.c defs.h
|
|
</PRE>
|
|
|
|
<P>
|
|
into:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
main.o main.d : main.c defs.h
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX263"></A>
|
|
This makes each <SAMP>`.d'</SAMP> file depend on all the source and header files
|
|
that the corresponding <SAMP>`.o'</SAMP> file depends on. <CODE>make</CODE> then
|
|
knows it must regenerate the prerequisites whenever any of the source or
|
|
header files changes.
|
|
|
|
</P>
|
|
<P>
|
|
Once you've defined the rule to remake the <SAMP>`.d'</SAMP> files,
|
|
you then use the <CODE>include</CODE> directive to read them all in.
|
|
See section <A HREF="make.html#SEC15">Including Other Makefiles</A>. For example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
sources = foo.c bar.c
|
|
|
|
include $(sources:.c=.d)
|
|
</PRE>
|
|
|
|
<P>
|
|
(This example uses a substitution variable reference to translate the
|
|
list of source files <SAMP>`foo.c bar.c'</SAMP> into a list of prerequisite
|
|
makefiles, <SAMP>`foo.d bar.d'</SAMP>. See section <A HREF="make.html#SEC61">Substitution References</A>, for full
|
|
information on substitution references.) Since the <SAMP>`.d'</SAMP> files are
|
|
makefiles like any others, <CODE>make</CODE> will remake them as necessary
|
|
with no further work from you. See section <A HREF="make.html#SEC17">How Makefiles Are Remade</A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC44" HREF="make.html#TOC44">Writing the Commands in Rules</A></H1>
|
|
<P>
|
|
<A NAME="IDX264"></A>
|
|
<A NAME="IDX265"></A>
|
|
<A NAME="IDX266"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The commands of a rule consist of shell command lines to be executed one
|
|
by one. Each command line must start with a tab, except that the first
|
|
command line may be attached to the target-and-prerequisites line with a
|
|
semicolon in between. Blank lines and lines of just comments may appear
|
|
among the command lines; they are ignored. (But beware, an apparently
|
|
"blank" line that begins with a tab is <EM>not</EM> blank! It is an
|
|
empty command; see section <A HREF="make.html#SEC56">Using Empty Commands</A>.)
|
|
|
|
</P>
|
|
<P>
|
|
Users use many different shell programs, but commands in makefiles are
|
|
always interpreted by <TT>`/bin/sh'</TT> unless the makefile specifies
|
|
otherwise. See section <A HREF="make.html#SEC46">Command Execution</A>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX267"></A>
|
|
<A NAME="IDX268"></A>
|
|
<A NAME="IDX269"></A>
|
|
The shell that is in use determines whether comments can be written on
|
|
command lines, and what syntax they use. When the shell is
|
|
<TT>`/bin/sh'</TT>, a <SAMP>`#'</SAMP> starts a comment that extends to the end of
|
|
the line. The <SAMP>`#'</SAMP> does not have to be at the beginning of a line.
|
|
Text on a line before a <SAMP>`#'</SAMP> is not part of the comment.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC45" HREF="make.html#TOC45">Command Echoing</A></H2>
|
|
<P>
|
|
<A NAME="IDX270"></A>
|
|
<A NAME="IDX271"></A>
|
|
<A NAME="IDX272"></A>
|
|
<A NAME="IDX273"></A>
|
|
<A NAME="IDX274"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Normally <CODE>make</CODE> prints each command line before it is executed.
|
|
We call this <STRONG>echoing</STRONG> because it gives the appearance that you
|
|
are typing the commands yourself.
|
|
|
|
</P>
|
|
<P>
|
|
When a line starts with <SAMP>`@'</SAMP>, the echoing of that line is suppressed.
|
|
The <SAMP>`@'</SAMP> is discarded before the command is passed to the shell.
|
|
Typically you would use this for a command whose only effect is to print
|
|
something, such as an <CODE>echo</CODE> command to indicate progress through
|
|
the makefile:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
@echo About to make distribution files
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX275"></A>
|
|
<A NAME="IDX276"></A>
|
|
<A NAME="IDX277"></A>
|
|
<A NAME="IDX278"></A>
|
|
When <CODE>make</CODE> is given the flag <SAMP>`-n'</SAMP> or <SAMP>`--just-print'</SAMP>
|
|
it only echoes commands, it won't execute them. See section <A HREF="make.html#SEC92">Summary of Options</A>. In this case and only this case, even the
|
|
commands starting with <SAMP>`@'</SAMP> are printed. This flag is useful for
|
|
finding out which commands <CODE>make</CODE> thinks are necessary without
|
|
actually doing them.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX279"></A>
|
|
<A NAME="IDX280"></A>
|
|
<A NAME="IDX281"></A>
|
|
<A NAME="IDX282"></A>
|
|
The <SAMP>`-s'</SAMP> or <SAMP>`--silent'</SAMP>
|
|
flag to <CODE>make</CODE> prevents all echoing, as if all commands
|
|
started with <SAMP>`@'</SAMP>. A rule in the makefile for the special target
|
|
<CODE>.SILENT</CODE> without prerequisites has the same effect
|
|
(see section <A HREF="make.html#SEC36">Special Built-in Target Names</A>).
|
|
<CODE>.SILENT</CODE> is essentially obsolete since <SAMP>`@'</SAMP> is more flexible.
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC46" HREF="make.html#TOC46">Command Execution</A></H2>
|
|
<P>
|
|
<A NAME="IDX283"></A>
|
|
<A NAME="IDX284"></A>
|
|
<A NAME="IDX285"></A>
|
|
<A NAME="IDX286"></A>
|
|
|
|
</P>
|
|
<P>
|
|
When it is time to execute commands to update a target, they are executed
|
|
by making a new subshell for each line. (In practice, <CODE>make</CODE> may
|
|
take shortcuts that do not affect the results.)
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX287"></A>
|
|
<STRONG>Please note:</STRONG> this implies that shell commands such as <CODE>cd</CODE>
|
|
that set variables local to each process will not affect the following
|
|
command lines. <A NAME="DOCF2" HREF="make.html#FOOT2">(2)</A> If you want to use <CODE>cd</CODE>
|
|
to affect the next command, put the two on a single line with a
|
|
semicolon between them. Then <CODE>make</CODE> will consider them a single
|
|
command and pass them, together, to a shell which will execute them in
|
|
sequence. For example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo : bar/lose
|
|
cd bar; gobble lose > ../foo
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX288"></A>
|
|
<A NAME="IDX289"></A>
|
|
<A NAME="IDX290"></A>
|
|
<A NAME="IDX291"></A>
|
|
<A NAME="IDX292"></A>
|
|
<A NAME="IDX293"></A>
|
|
If you would like to split a single shell command into multiple lines of
|
|
text, you must use a backslash at the end of all but the last subline.
|
|
Such a sequence of lines is combined into a single line, by deleting the
|
|
backslash-newline sequences, before passing it to the shell. Thus, the
|
|
following is equivalent to the preceding example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo : bar/lose
|
|
cd bar; \
|
|
gobble lose > ../foo
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX294"></A>
|
|
The program used as the shell is taken from the variable <CODE>SHELL</CODE>.
|
|
By default, the program <TT>`/bin/sh'</TT> is used.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX295"></A>
|
|
On MS-DOS, if <CODE>SHELL</CODE> is not set, the value of the variable
|
|
<CODE>COMSPEC</CODE> (which is always set) is used instead.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX296"></A>
|
|
The processing of lines that set the variable <CODE>SHELL</CODE> in Makefiles
|
|
is different on MS-DOS. The stock shell, <TT>`command.com'</TT>, is
|
|
ridiculously limited in its functionality and many users of <CODE>make</CODE>
|
|
tend to install a replacement shell. Therefore, on MS-DOS, <CODE>make</CODE>
|
|
examines the value of <CODE>SHELL</CODE>, and changes its behavior based on
|
|
whether it points to a Unix-style or DOS-style shell. This allows
|
|
reasonable functionality even if <CODE>SHELL</CODE> points to
|
|
<TT>`command.com'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
If <CODE>SHELL</CODE> points to a Unix-style shell, <CODE>make</CODE> on MS-DOS
|
|
additionally checks whether that shell can indeed be found; if not, it
|
|
ignores the line that sets <CODE>SHELL</CODE>. In MS-DOS, GNU <CODE>make</CODE>
|
|
searches for the shell in the following places:
|
|
|
|
</P>
|
|
|
|
<OL>
|
|
<LI>
|
|
|
|
In the precise place pointed to by the value of <CODE>SHELL</CODE>. For
|
|
example, if the makefile specifies <SAMP>`SHELL = /bin/sh'</SAMP>, <CODE>make</CODE>
|
|
will look in the directory <TT>`/bin'</TT> on the current drive.
|
|
|
|
<LI>
|
|
|
|
In the current directory.
|
|
|
|
<LI>
|
|
|
|
In each of the directories in the <CODE>PATH</CODE> variable, in order.
|
|
|
|
</OL>
|
|
|
|
<P>
|
|
In every directory it examines, <CODE>make</CODE> will first look for the
|
|
specific file (<TT>`sh'</TT> in the example above). If this is not found,
|
|
it will also look in that directory for that file with one of the known
|
|
extensions which identify executable files. For example <TT>`.exe'</TT>,
|
|
<TT>`.com'</TT>, <TT>`.bat'</TT>, <TT>`.btm'</TT>, <TT>`.sh'</TT>, and some others.
|
|
|
|
</P>
|
|
<P>
|
|
If any of these attempts is successful, the value of <CODE>SHELL</CODE> will
|
|
be set to the full pathname of the shell as found. However, if none of
|
|
these is found, the value of <CODE>SHELL</CODE> will not be changed, and thus
|
|
the line that sets it will be effectively ignored. This is so
|
|
<CODE>make</CODE> will only support features specific to a Unix-style shell if
|
|
such a shell is actually installed on the system where <CODE>make</CODE> runs.
|
|
|
|
</P>
|
|
<P>
|
|
Note that this extended search for the shell is limited to the cases
|
|
where <CODE>SHELL</CODE> is set from the Makefile; if it is set in the
|
|
environment or command line, you are expected to set it to the full
|
|
pathname of the shell, exactly as things are on Unix.
|
|
|
|
</P>
|
|
<P>
|
|
The effect of the above DOS-specific processing is that a Makefile that
|
|
says <SAMP>`SHELL = /bin/sh'</SAMP> (as many Unix makefiles do), will work
|
|
on MS-DOS unaltered if you have e.g. <TT>`sh.exe'</TT> installed in some
|
|
directory along your <CODE>PATH</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX297"></A>
|
|
Unlike most variables, the variable <CODE>SHELL</CODE> is never set from the
|
|
environment. This is because the <CODE>SHELL</CODE> environment variable is
|
|
used to specify your personal choice of shell program for interactive
|
|
use. It would be very bad for personal choices like this to affect the
|
|
functioning of makefiles. See section <A HREF="make.html#SEC68">Variables from the Environment</A>. However, on MS-DOS and MS-Windows the value of
|
|
<CODE>SHELL</CODE> in the environment <STRONG>is</STRONG> used, since on those systems
|
|
most users do not set this variable, and therefore it is most likely set
|
|
specifically to be used by <CODE>make</CODE>. On MS-DOS, if the setting of
|
|
<CODE>SHELL</CODE> is not suitable for <CODE>make</CODE>, you can set the variable
|
|
<CODE>MAKESHELL</CODE> to the shell that <CODE>make</CODE> should use; this will
|
|
override the value of <CODE>SHELL</CODE>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC47" HREF="make.html#TOC47">Parallel Execution</A></H2>
|
|
<P>
|
|
<A NAME="IDX298"></A>
|
|
<A NAME="IDX299"></A>
|
|
<A NAME="IDX300"></A>
|
|
<A NAME="IDX301"></A>
|
|
<A NAME="IDX302"></A>
|
|
<A NAME="IDX303"></A>
|
|
|
|
</P>
|
|
<P>
|
|
GNU <CODE>make</CODE> knows how to execute several commands at once.
|
|
Normally, <CODE>make</CODE> will execute only one command at a time, waiting
|
|
for it to finish before executing the next. However, the <SAMP>`-j'</SAMP> or
|
|
<SAMP>`--jobs'</SAMP> option tells <CODE>make</CODE> to execute many commands
|
|
simultaneously.
|
|
</P>
|
|
<P>
|
|
On MS-DOS, the <SAMP>`-j'</SAMP> option has no effect, since that system doesn't
|
|
support multi-processing.
|
|
|
|
</P>
|
|
<P>
|
|
If the <SAMP>`-j'</SAMP> option is followed by an integer, this is the number of
|
|
commands to execute at once; this is called the number of <STRONG>job slots</STRONG>.
|
|
If there is nothing looking like an integer after the <SAMP>`-j'</SAMP> option,
|
|
there is no limit on the number of job slots. The default number of job
|
|
slots is one, which means serial execution (one thing at a time).
|
|
|
|
</P>
|
|
<P>
|
|
One unpleasant consequence of running several commands simultaneously is
|
|
that output generated by the commands appears whenever each command
|
|
sends it, so messages from different commands may be interspersed.
|
|
|
|
</P>
|
|
<P>
|
|
Another problem is that two processes cannot both take input from the
|
|
same device; so to make sure that only one command tries to take input
|
|
from the terminal at once, <CODE>make</CODE> will invalidate the standard
|
|
input streams of all but one running command. This means that
|
|
attempting to read from standard input will usually be a fatal error (a
|
|
<SAMP>`Broken pipe'</SAMP> signal) for most child processes if there are
|
|
several.
|
|
<A NAME="IDX304"></A>
|
|
<A NAME="IDX305"></A>
|
|
|
|
</P>
|
|
<P>
|
|
It is unpredictable which command will have a valid standard input stream
|
|
(which will come from the terminal, or wherever you redirect the standard
|
|
input of <CODE>make</CODE>). The first command run will always get it first, and
|
|
the first command started after that one finishes will get it next, and so
|
|
on.
|
|
|
|
</P>
|
|
<P>
|
|
We will change how this aspect of <CODE>make</CODE> works if we find a better
|
|
alternative. In the mean time, you should not rely on any command using
|
|
standard input at all if you are using the parallel execution feature; but
|
|
if you are not using this feature, then standard input works normally in
|
|
all commands.
|
|
|
|
</P>
|
|
<P>
|
|
Finally, handling recursive <CODE>make</CODE> invocations raises issues. For
|
|
more information on this, see
|
|
section <A HREF="make.html#SEC53">Communicating Options to a Sub-<CODE>make</CODE></A>.
|
|
|
|
</P>
|
|
<P>
|
|
If a command fails (is killed by a signal or exits with a nonzero
|
|
status), and errors are not ignored for that command
|
|
(see section <A HREF="make.html#SEC48">Errors in Commands</A>),
|
|
the remaining command lines to remake the same target will not be run.
|
|
If a command fails and the <SAMP>`-k'</SAMP> or <SAMP>`--keep-going'</SAMP>
|
|
option was not given
|
|
(see section <A HREF="make.html#SEC92">Summary of Options</A>),
|
|
<CODE>make</CODE> aborts execution. If make
|
|
terminates for any reason (including a signal) with child processes
|
|
running, it waits for them to finish before actually exiting.
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX306"></A>
|
|
<A NAME="IDX307"></A>
|
|
<A NAME="IDX308"></A>
|
|
<A NAME="IDX309"></A>
|
|
<A NAME="IDX310"></A>
|
|
<A NAME="IDX311"></A>
|
|
When the system is heavily loaded, you will probably want to run fewer jobs
|
|
than when it is lightly loaded. You can use the <SAMP>`-l'</SAMP> option to tell
|
|
<CODE>make</CODE> to limit the number of jobs to run at once, based on the load
|
|
average. The <SAMP>`-l'</SAMP> or <SAMP>`--max-load'</SAMP>
|
|
option is followed by a floating-point number. For
|
|
example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
-l 2.5
|
|
</PRE>
|
|
|
|
<P>
|
|
will not let <CODE>make</CODE> start more than one job if the load average is
|
|
above 2.5. The <SAMP>`-l'</SAMP> option with no following number removes the
|
|
load limit, if one was given with a previous <SAMP>`-l'</SAMP> option.
|
|
</P>
|
|
<P>
|
|
More precisely, when <CODE>make</CODE> goes to start up a job, and it already has
|
|
at least one job running, it checks the current load average; if it is not
|
|
lower than the limit given with <SAMP>`-l'</SAMP>, <CODE>make</CODE> waits until the load
|
|
average goes below that limit, or until all the other jobs finish.
|
|
|
|
</P>
|
|
<P>
|
|
By default, there is no load limit.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC48" HREF="make.html#TOC48">Errors in Commands</A></H2>
|
|
<P>
|
|
<A NAME="IDX312"></A>
|
|
<A NAME="IDX313"></A>
|
|
<A NAME="IDX314"></A>
|
|
|
|
</P>
|
|
<P>
|
|
After each shell command returns, <CODE>make</CODE> looks at its exit status.
|
|
If the command completed successfully, the next command line is executed
|
|
in a new shell; after the last command line is finished, the rule is
|
|
finished.
|
|
|
|
</P>
|
|
<P>
|
|
If there is an error (the exit status is nonzero), <CODE>make</CODE> gives up on
|
|
the current rule, and perhaps on all rules.
|
|
|
|
</P>
|
|
<P>
|
|
Sometimes the failure of a certain command does not indicate a problem.
|
|
For example, you may use the <CODE>mkdir</CODE> command to ensure that a
|
|
directory exists. If the directory already exists, <CODE>mkdir</CODE> will
|
|
report an error, but you probably want <CODE>make</CODE> to continue regardless.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX315"></A>
|
|
To ignore errors in a command line, write a <SAMP>`-'</SAMP> at the beginning of
|
|
the line's text (after the initial tab). The <SAMP>`-'</SAMP> is discarded before
|
|
the command is passed to the shell for execution.
|
|
|
|
</P>
|
|
<P>
|
|
For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
clean:
|
|
-rm -f *.o
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX316"></A>
|
|
|
|
</P>
|
|
<P>
|
|
This causes <CODE>rm</CODE> to continue even if it is unable to remove a file.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX317"></A>
|
|
<A NAME="IDX318"></A>
|
|
<A NAME="IDX319"></A>
|
|
When you run <CODE>make</CODE> with the <SAMP>`-i'</SAMP> or <SAMP>`--ignore-errors'</SAMP>
|
|
flag, errors are ignored in all commands of all rules. A rule in the
|
|
makefile for the special target <CODE>.IGNORE</CODE> has the same effect, if
|
|
there are no prerequisites. These ways of ignoring errors are obsolete
|
|
because <SAMP>`-'</SAMP> is more flexible.
|
|
|
|
</P>
|
|
<P>
|
|
When errors are to be ignored, because of either a <SAMP>`-'</SAMP> or the
|
|
<SAMP>`-i'</SAMP> flag, <CODE>make</CODE> treats an error return just like success,
|
|
except that it prints out a message that tells you the status code
|
|
the command exited with, and says that the error has been ignored.
|
|
|
|
</P>
|
|
<P>
|
|
When an error happens that <CODE>make</CODE> has not been told to ignore,
|
|
it implies that the current target cannot be correctly remade, and neither
|
|
can any other that depends on it either directly or indirectly. No further
|
|
commands will be executed for these targets, since their preconditions
|
|
have not been achieved.
|
|
|
|
</P>
|
|
|
|
<P>
|
|
<A NAME="IDX320"></A>
|
|
<A NAME="IDX321"></A>
|
|
Normally <CODE>make</CODE> gives up immediately in this circumstance, returning a
|
|
nonzero status. However, if the <SAMP>`-k'</SAMP> or <SAMP>`--keep-going'</SAMP>
|
|
flag is specified, <CODE>make</CODE>
|
|
continues to consider the other prerequisites of the pending targets,
|
|
remaking them if necessary, before it gives up and returns nonzero status.
|
|
For example, after an error in compiling one object file, <SAMP>`make -k'</SAMP>
|
|
will continue compiling other object files even though it already knows
|
|
that linking them will be impossible. See section <A HREF="make.html#SEC92">Summary of Options</A>.
|
|
|
|
</P>
|
|
<P>
|
|
The usual behavior assumes that your purpose is to get the specified
|
|
targets up to date; once <CODE>make</CODE> learns that this is impossible, it
|
|
might as well report the failure immediately. The <SAMP>`-k'</SAMP> option says
|
|
that the real purpose is to test as many of the changes made in the
|
|
program as possible, perhaps to find several independent problems so
|
|
that you can correct them all before the next attempt to compile. This
|
|
is why Emacs' <CODE>compile</CODE> command passes the <SAMP>`-k'</SAMP> flag by
|
|
default.
|
|
<A NAME="IDX322"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX323"></A>
|
|
<A NAME="IDX324"></A>
|
|
<A NAME="IDX325"></A>
|
|
<A NAME="IDX326"></A>
|
|
Usually when a command fails, if it has changed the target file at all,
|
|
the file is corrupted and cannot be used--or at least it is not
|
|
completely updated. Yet the file's timestamp says that it is now up to
|
|
date, so the next time <CODE>make</CODE> runs, it will not try to update that
|
|
file. The situation is just the same as when the command is killed by a
|
|
signal; see section <A HREF="make.html#SEC49">Interrupting or Killing <CODE>make</CODE></A>. So generally the right thing to do is to
|
|
delete the target file if the command fails after beginning to change
|
|
the file. <CODE>make</CODE> will do this if <CODE>.DELETE_ON_ERROR</CODE> appears
|
|
as a target. This is almost always what you want <CODE>make</CODE> to do, but
|
|
it is not historical practice; so for compatibility, you must explicitly
|
|
request it.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC49" HREF="make.html#TOC49">Interrupting or Killing <CODE>make</CODE></A></H2>
|
|
<P>
|
|
<A NAME="IDX327"></A>
|
|
<A NAME="IDX328"></A>
|
|
<A NAME="IDX329"></A>
|
|
<A NAME="IDX330"></A>
|
|
<A NAME="IDX331"></A>
|
|
<A NAME="IDX332"></A>
|
|
|
|
</P>
|
|
<P>
|
|
If <CODE>make</CODE> gets a fatal signal while a command is executing, it may
|
|
delete the target file that the command was supposed to update. This is
|
|
done if the target file's last-modification time has changed since
|
|
<CODE>make</CODE> first checked it.
|
|
|
|
</P>
|
|
<P>
|
|
The purpose of deleting the target is to make sure that it is remade from
|
|
scratch when <CODE>make</CODE> is next run. Why is this? Suppose you type
|
|
<KBD>Ctrl-c</KBD> while a compiler is running, and it has begun to write an
|
|
object file <TT>`foo.o'</TT>. The <KBD>Ctrl-c</KBD> kills the compiler, resulting
|
|
in an incomplete file whose last-modification time is newer than the source
|
|
file <TT>`foo.c'</TT>. But <CODE>make</CODE> also receives the <KBD>Ctrl-c</KBD> signal
|
|
and deletes this incomplete file. If <CODE>make</CODE> did not do this, the next
|
|
invocation of <CODE>make</CODE> would think that <TT>`foo.o'</TT> did not require
|
|
updating--resulting in a strange error message from the linker when it
|
|
tries to link an object file half of which is missing.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX333"></A>
|
|
You can prevent the deletion of a target file in this way by making the
|
|
special target <CODE>.PRECIOUS</CODE> depend on it. Before remaking a target,
|
|
<CODE>make</CODE> checks to see whether it appears on the prerequisites of
|
|
<CODE>.PRECIOUS</CODE>, and thereby decides whether the target should be deleted
|
|
if a signal happens. Some reasons why you might do this are that the
|
|
target is updated in some atomic fashion, or exists only to record a
|
|
modification-time (its contents do not matter), or must exist at all
|
|
times to prevent other sorts of trouble.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC50" HREF="make.html#TOC50">Recursive Use of <CODE>make</CODE></A></H2>
|
|
<P>
|
|
<A NAME="IDX334"></A>
|
|
<A NAME="IDX335"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Recursive use of <CODE>make</CODE> means using <CODE>make</CODE> as a command in a
|
|
makefile. This technique is useful when you want separate makefiles for
|
|
various subsystems that compose a larger system. For example, suppose you
|
|
have a subdirectory <TT>`subdir'</TT> which has its own makefile, and you would
|
|
like the containing directory's makefile to run <CODE>make</CODE> on the
|
|
subdirectory. You can do it by writing this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
subsystem:
|
|
cd subdir && $(MAKE)
|
|
</PRE>
|
|
|
|
<P>
|
|
or, equivalently, this (see section <A HREF="make.html#SEC92">Summary of Options</A>):
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
subsystem:
|
|
$(MAKE) -C subdir
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX336"></A>
|
|
<A NAME="IDX337"></A>
|
|
|
|
</P>
|
|
<P>
|
|
You can write recursive <CODE>make</CODE> commands just by copying this example,
|
|
but there are many things to know about how they work and why, and about
|
|
how the sub-<CODE>make</CODE> relates to the top-level <CODE>make</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
For your convenience, GNU <CODE>make</CODE> sets the variable <CODE>CURDIR</CODE> to
|
|
the pathname of the current working directory for you. If <CODE>-C</CODE> is
|
|
in effect, it will contain the path of the new directory, not the
|
|
original. The value has the same precedence it would have if it were
|
|
set in the makefile (by default, an environment variable <CODE>CURDIR</CODE>
|
|
will not override this value). Note that setting this variable has no
|
|
effect on the operation of <CODE>make</CODE>
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC51" HREF="make.html#TOC51">How the <CODE>MAKE</CODE> Variable Works</A></H3>
|
|
<P>
|
|
<A NAME="IDX338"></A>
|
|
<A NAME="IDX339"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Recursive <CODE>make</CODE> commands should always use the variable <CODE>MAKE</CODE>,
|
|
not the explicit command name <SAMP>`make'</SAMP>, as shown here:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
subsystem:
|
|
cd subdir && $(MAKE)
|
|
</PRE>
|
|
|
|
<P>
|
|
The value of this variable is the file name with which <CODE>make</CODE> was
|
|
invoked. If this file name was <TT>`/bin/make'</TT>, then the command executed
|
|
is <SAMP>`cd subdir && /bin/make'</SAMP>. If you use a special version of
|
|
<CODE>make</CODE> to run the top-level makefile, the same special version will be
|
|
executed for recursive invocations.
|
|
<A NAME="IDX340"></A>
|
|
|
|
</P>
|
|
<P>
|
|
As a special feature, using the variable <CODE>MAKE</CODE> in the commands of
|
|
a rule alters the effects of the <SAMP>`-t'</SAMP> (<SAMP>`--touch'</SAMP>), <SAMP>`-n'</SAMP>
|
|
(<SAMP>`--just-print'</SAMP>), or <SAMP>`-q'</SAMP> (<SAMP>`--question'</SAMP>) option.
|
|
Using the <CODE>MAKE</CODE> variable has the same effect as using a <SAMP>`+'</SAMP>
|
|
character at the beginning of the command line. See section <A HREF="make.html#SEC88">Instead of Executing the Commands</A>.
|
|
</P>
|
|
<P>
|
|
Consider the command <SAMP>`make -t'</SAMP> in the above example. (The
|
|
<SAMP>`-t'</SAMP> option marks targets as up to date without actually running
|
|
any commands; see section <A HREF="make.html#SEC88">Instead of Executing the Commands</A>.) Following the usual
|
|
definition of <SAMP>`-t'</SAMP>, a <SAMP>`make -t'</SAMP> command in the example would
|
|
create a file named <TT>`subsystem'</TT> and do nothing else. What you
|
|
really want it to do is run <SAMP>`cd subdir && make -t'</SAMP>; but that would
|
|
require executing the command, and <SAMP>`-t'</SAMP> says not to execute
|
|
commands.<A NAME="IDX341"></A>
|
|
<A NAME="IDX342"></A>
|
|
<A NAME="IDX343"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The special feature makes this do what you want: whenever a command
|
|
line of a rule contains the variable <CODE>MAKE</CODE>, the flags <SAMP>`-t'</SAMP>,
|
|
<SAMP>`-n'</SAMP> and <SAMP>`-q'</SAMP> do not apply to that line. Command lines
|
|
containing <CODE>MAKE</CODE> are executed normally despite the presence of a
|
|
flag that causes most commands not to be run. The usual
|
|
<CODE>MAKEFLAGS</CODE> mechanism passes the flags to the sub-<CODE>make</CODE>
|
|
(see section <A HREF="make.html#SEC53">Communicating Options to a Sub-<CODE>make</CODE></A>), so your request to touch the files, or print the
|
|
commands, is propagated to the subsystem.
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC52" HREF="make.html#TOC52">Communicating Variables to a Sub-<CODE>make</CODE></A></H3>
|
|
<P>
|
|
<A NAME="IDX344"></A>
|
|
<A NAME="IDX345"></A>
|
|
<A NAME="IDX346"></A>
|
|
<A NAME="IDX347"></A>
|
|
<A NAME="IDX348"></A>
|
|
<A NAME="IDX349"></A>
|
|
<A NAME="IDX350"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Variable values of the top-level <CODE>make</CODE> can be passed to the
|
|
sub-<CODE>make</CODE> through the environment by explicit request. These
|
|
variables are defined in the sub-<CODE>make</CODE> as defaults, but do not
|
|
override what is specified in the makefile used by the sub-<CODE>make</CODE>
|
|
makefile unless you use the <SAMP>`-e'</SAMP> switch (see section <A HREF="make.html#SEC92">Summary of Options</A>).
|
|
</P>
|
|
<P>
|
|
To pass down, or <STRONG>export</STRONG>, a variable, <CODE>make</CODE> adds the variable
|
|
and its value to the environment for running each command. The
|
|
sub-<CODE>make</CODE>, in turn, uses the environment to initialize its table
|
|
of variable values. See section <A HREF="make.html#SEC68">Variables from the Environment</A>.
|
|
|
|
</P>
|
|
<P>
|
|
Except by explicit request, <CODE>make</CODE> exports a variable only if it
|
|
is either defined in the environment initially or set on the command
|
|
line, and if its name consists only of letters, numbers, and underscores.
|
|
Some shells cannot cope with environment variable names consisting of
|
|
characters other than letters, numbers, and underscores.
|
|
|
|
</P>
|
|
<P>
|
|
The special variables <CODE>SHELL</CODE> and <CODE>MAKEFLAGS</CODE> are always
|
|
exported (unless you unexport them).
|
|
<CODE>MAKEFILES</CODE> is exported if you set it to anything.
|
|
|
|
</P>
|
|
<P>
|
|
<CODE>make</CODE> automatically passes down variable values that were defined
|
|
on the command line, by putting them in the <CODE>MAKEFLAGS</CODE> variable.
|
|
See the next section.
|
|
|
|
</P>
|
|
<P>
|
|
Variables are <EM>not</EM> normally passed down if they were created by
|
|
default by <CODE>make</CODE> (see section <A HREF="make.html#SEC96">Variables Used by Implicit Rules</A>). The sub-<CODE>make</CODE> will define these for
|
|
itself.
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX351"></A>
|
|
If you want to export specific variables to a sub-<CODE>make</CODE>, use the
|
|
<CODE>export</CODE> directive, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
export <VAR>variable</VAR> ...
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX352"></A>
|
|
If you want to <EM>prevent</EM> a variable from being exported, use the
|
|
<CODE>unexport</CODE> directive, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
unexport <VAR>variable</VAR> ...
|
|
</PRE>
|
|
|
|
<P>
|
|
As a convenience, you can define a variable and export it at the same
|
|
time by doing:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
export <VAR>variable</VAR> = value
|
|
</PRE>
|
|
|
|
<P>
|
|
has the same result as:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>variable</VAR> = value
|
|
export <VAR>variable</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
and
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
export <VAR>variable</VAR> := value
|
|
</PRE>
|
|
|
|
<P>
|
|
has the same result as:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>variable</VAR> := value
|
|
export <VAR>variable</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
Likewise,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
export <VAR>variable</VAR> += value
|
|
</PRE>
|
|
|
|
<P>
|
|
is just like:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>variable</VAR> += value
|
|
export <VAR>variable</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
See section <A HREF="make.html#SEC65">Appending More Text to Variables</A>.
|
|
|
|
</P>
|
|
<P>
|
|
You may notice that the <CODE>export</CODE> and <CODE>unexport</CODE> directives
|
|
work in <CODE>make</CODE> in the same way they work in the shell, <CODE>sh</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
If you want all variables to be exported by default, you can use
|
|
<CODE>export</CODE> by itself:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
export
|
|
</PRE>
|
|
|
|
<P>
|
|
This tells <CODE>make</CODE> that variables which are not explicitly mentioned
|
|
in an <CODE>export</CODE> or <CODE>unexport</CODE> directive should be exported.
|
|
Any variable given in an <CODE>unexport</CODE> directive will still <EM>not</EM>
|
|
be exported. If you use <CODE>export</CODE> by itself to export variables by
|
|
default, variables whose names contain characters other than
|
|
alphanumerics and underscores will not be exported unless specifically
|
|
mentioned in an <CODE>export</CODE> directive.
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX353"></A>
|
|
The behavior elicited by an <CODE>export</CODE> directive by itself was the
|
|
default in older versions of GNU <CODE>make</CODE>. If your makefiles depend
|
|
on this behavior and you want to be compatible with old versions of
|
|
<CODE>make</CODE>, you can write a rule for the special target
|
|
<CODE>.EXPORT_ALL_VARIABLES</CODE> instead of using the <CODE>export</CODE> directive.
|
|
This will be ignored by old <CODE>make</CODE>s, while the <CODE>export</CODE>
|
|
directive will cause a syntax error.<A NAME="IDX354"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Likewise, you can use <CODE>unexport</CODE> by itself to tell <CODE>make</CODE>
|
|
<EM>not</EM> to export variables by default. Since this is the default
|
|
behavior, you would only need to do this if <CODE>export</CODE> had been used
|
|
by itself earlier (in an included makefile, perhaps). You
|
|
<STRONG>cannot</STRONG> use <CODE>export</CODE> and <CODE>unexport</CODE> by themselves to
|
|
have variables exported for some commands and not for others. The last
|
|
<CODE>export</CODE> or <CODE>unexport</CODE> directive that appears by itself
|
|
determines the behavior for the entire run of <CODE>make</CODE>.
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX355"></A>
|
|
<A NAME="IDX356"></A>
|
|
As a special feature, the variable <CODE>MAKELEVEL</CODE> is changed when it
|
|
is passed down from level to level. This variable's value is a string
|
|
which is the depth of the level as a decimal number. The value is
|
|
<SAMP>`0'</SAMP> for the top-level <CODE>make</CODE>; <SAMP>`1'</SAMP> for a sub-<CODE>make</CODE>,
|
|
<SAMP>`2'</SAMP> for a sub-sub-<CODE>make</CODE>, and so on. The incrementation
|
|
happens when <CODE>make</CODE> sets up the environment for a command.
|
|
</P>
|
|
<P>
|
|
The main use of <CODE>MAKELEVEL</CODE> is to test it in a conditional
|
|
directive (see section <A HREF="make.html#SEC71">Conditional Parts of Makefiles</A>); this
|
|
way you can write a makefile that behaves one way if run recursively and
|
|
another way if run directly by you.
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX357"></A>
|
|
You can use the variable <CODE>MAKEFILES</CODE> to cause all sub-<CODE>make</CODE>
|
|
commands to use additional makefiles. The value of <CODE>MAKEFILES</CODE> is
|
|
a whitespace-separated list of file names. This variable, if defined in
|
|
the outer-level makefile, is passed down through the environment; then
|
|
it serves as a list of extra makefiles for the sub-<CODE>make</CODE> to read
|
|
before the usual or specified ones. See section <A HREF="make.html#SEC16">The Variable <CODE>MAKEFILES</CODE></A>.
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC53" HREF="make.html#TOC53">Communicating Options to a Sub-<CODE>make</CODE></A></H3>
|
|
<P>
|
|
<A NAME="IDX358"></A>
|
|
<A NAME="IDX359"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX360"></A>
|
|
Flags such as <SAMP>`-s'</SAMP> and <SAMP>`-k'</SAMP> are passed automatically to the
|
|
sub-<CODE>make</CODE> through the variable <CODE>MAKEFLAGS</CODE>. This variable is
|
|
set up automatically by <CODE>make</CODE> to contain the flag letters that
|
|
<CODE>make</CODE> received. Thus, if you do <SAMP>`make -ks'</SAMP> then
|
|
<CODE>MAKEFLAGS</CODE> gets the value <SAMP>`ks'</SAMP>.
|
|
</P>
|
|
<P>
|
|
As a consequence, every sub-<CODE>make</CODE> gets a value for <CODE>MAKEFLAGS</CODE>
|
|
in its environment. In response, it takes the flags from that value and
|
|
processes them as if they had been given as arguments.
|
|
See section <A HREF="make.html#SEC92">Summary of Options</A>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX361"></A>
|
|
<A NAME="IDX362"></A>
|
|
<A NAME="IDX363"></A>
|
|
Likewise variables defined on the command line are passed to the
|
|
sub-<CODE>make</CODE> through <CODE>MAKEFLAGS</CODE>. Words in the value of
|
|
<CODE>MAKEFLAGS</CODE> that contain <SAMP>`='</SAMP>, <CODE>make</CODE> treats as variable
|
|
definitions just as if they appeared on the command line.
|
|
See section <A HREF="make.html#SEC90">Overriding Variables</A>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX364"></A>
|
|
<A NAME="IDX365"></A>
|
|
<A NAME="IDX366"></A>
|
|
<A NAME="IDX367"></A>
|
|
<A NAME="IDX368"></A>
|
|
<A NAME="IDX369"></A>
|
|
<A NAME="IDX370"></A>
|
|
<A NAME="IDX371"></A>
|
|
<A NAME="IDX372"></A>
|
|
<A NAME="IDX373"></A>
|
|
<A NAME="IDX374"></A>
|
|
<A NAME="IDX375"></A>
|
|
<A NAME="IDX376"></A>
|
|
<A NAME="IDX377"></A>
|
|
The options <SAMP>`-C'</SAMP>, <SAMP>`-f'</SAMP>, <SAMP>`-o'</SAMP>, and <SAMP>`-W'</SAMP> are not put
|
|
into <CODE>MAKEFLAGS</CODE>; these options are not passed down.
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX378"></A>
|
|
<A NAME="IDX379"></A>
|
|
<A NAME="IDX380"></A>
|
|
<A NAME="IDX381"></A>
|
|
The <SAMP>`-j'</SAMP> option is a special case (see section <A HREF="make.html#SEC47">Parallel Execution</A>).
|
|
If you set it to some numeric value <SAMP>`N'</SAMP> and your operating system
|
|
supports it (most any UNIX system will; others typically won't), the
|
|
parent <CODE>make</CODE> and all the sub-<CODE>make</CODE>s will communicate to
|
|
ensure that there are only <SAMP>`N'</SAMP> jobs running at the same time
|
|
between them all. Note that any job that is marked recursive
|
|
(see section <A HREF="make.html#SEC88">Instead of Executing the Commands</A>)
|
|
doesn't count against the total jobs (otherwise we could get <SAMP>`N'</SAMP>
|
|
sub-<CODE>make</CODE>s running and have no slots left over for any real work!)
|
|
|
|
</P>
|
|
<P>
|
|
If your operating system doesn't support the above communication, then
|
|
<SAMP>`-j 1'</SAMP> is always put into <CODE>MAKEFLAGS</CODE> instead of the value you
|
|
specified. This is because if the <SAMP>`-j'</SAMP> option were passed down
|
|
to sub-<CODE>make</CODE>s, you would get many more jobs running in parallel
|
|
than you asked for. If you give <SAMP>`-j'</SAMP> with no numeric argument,
|
|
meaning to run as many jobs as possible in parallel, this is passed
|
|
down, since multiple infinities are no more than one.
|
|
</P>
|
|
<P>
|
|
If you do not want to pass the other flags down, you must change the
|
|
value of <CODE>MAKEFLAGS</CODE>, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
subsystem:
|
|
cd subdir && $(MAKE) MAKEFLAGS=
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX382"></A>
|
|
The command line variable definitions really appear in the variable
|
|
<CODE>MAKEOVERRIDES</CODE>, and <CODE>MAKEFLAGS</CODE> contains a reference to this
|
|
variable. If you do want to pass flags down normally, but don't want to
|
|
pass down the command line variable definitions, you can reset
|
|
<CODE>MAKEOVERRIDES</CODE> to empty, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
MAKEOVERRIDES =
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX383"></A>
|
|
<A NAME="IDX384"></A>
|
|
This is not usually useful to do. However, some systems have a small
|
|
fixed limit on the size of the environment, and putting so much
|
|
information into the value of <CODE>MAKEFLAGS</CODE> can exceed it. If you
|
|
see the error message <SAMP>`Arg list too long'</SAMP>, this may be the problem.
|
|
<A NAME="IDX385"></A>
|
|
<A NAME="IDX386"></A>
|
|
(For strict compliance with POSIX.2, changing <CODE>MAKEOVERRIDES</CODE> does
|
|
not affect <CODE>MAKEFLAGS</CODE> if the special target <SAMP>`.POSIX'</SAMP> appears
|
|
in the makefile. You probably do not care about this.)
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX387"></A>
|
|
A similar variable <CODE>MFLAGS</CODE> exists also, for historical
|
|
compatibility. It has the same value as <CODE>MAKEFLAGS</CODE> except that it
|
|
does not contain the command line variable definitions, and it always
|
|
begins with a hyphen unless it is empty (<CODE>MAKEFLAGS</CODE> begins with a
|
|
hyphen only when it begins with an option that has no single-letter
|
|
version, such as <SAMP>`--warn-undefined-variables'</SAMP>). <CODE>MFLAGS</CODE> was
|
|
traditionally used explicitly in the recursive <CODE>make</CODE> command, like
|
|
this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
subsystem:
|
|
cd subdir && $(MAKE) $(MFLAGS)
|
|
</PRE>
|
|
|
|
<P>
|
|
but now <CODE>MAKEFLAGS</CODE> makes this usage redundant. If you want your
|
|
makefiles to be compatible with old <CODE>make</CODE> programs, use this
|
|
technique; it will work fine with more modern <CODE>make</CODE> versions too.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX388"></A>
|
|
<A NAME="IDX389"></A>
|
|
<A NAME="IDX390"></A>
|
|
<A NAME="IDX391"></A>
|
|
The <CODE>MAKEFLAGS</CODE> variable can also be useful if you want to have
|
|
certain options, such as <SAMP>`-k'</SAMP> (see section <A HREF="make.html#SEC92">Summary of Options</A>), set each time you run <CODE>make</CODE>. You simply put a value for
|
|
<CODE>MAKEFLAGS</CODE> in your environment. You can also set <CODE>MAKEFLAGS</CODE> in
|
|
a makefile, to specify additional flags that should also be in effect for
|
|
that makefile. (Note that you cannot use <CODE>MFLAGS</CODE> this way. That
|
|
variable is set only for compatibility; <CODE>make</CODE> does not interpret a
|
|
value you set for it in any way.)
|
|
|
|
</P>
|
|
<P>
|
|
When <CODE>make</CODE> interprets the value of <CODE>MAKEFLAGS</CODE> (either from the
|
|
environment or from a makefile), it first prepends a hyphen if the value
|
|
does not already begin with one. Then it chops the value into words
|
|
separated by blanks, and parses these words as if they were options given
|
|
on the command line (except that <SAMP>`-C'</SAMP>, <SAMP>`-f'</SAMP>, <SAMP>`-h'</SAMP>,
|
|
<SAMP>`-o'</SAMP>, <SAMP>`-W'</SAMP>, and their long-named versions are ignored; and there
|
|
is no error for an invalid option).
|
|
|
|
</P>
|
|
<P>
|
|
If you do put <CODE>MAKEFLAGS</CODE> in your environment, you should be sure not
|
|
to include any options that will drastically affect the actions of
|
|
<CODE>make</CODE> and undermine the purpose of makefiles and of <CODE>make</CODE>
|
|
itself. For instance, the <SAMP>`-t'</SAMP>, <SAMP>`-n'</SAMP>, and <SAMP>`-q'</SAMP> options, if
|
|
put in one of these variables, could have disastrous consequences and would
|
|
certainly have at least surprising and probably annoying effects.
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC54" HREF="make.html#TOC54">The <SAMP>`--print-directory'</SAMP> Option</A></H3>
|
|
<P>
|
|
<A NAME="IDX392"></A>
|
|
<A NAME="IDX393"></A>
|
|
<A NAME="IDX394"></A>
|
|
|
|
</P>
|
|
<P>
|
|
If you use several levels of recursive <CODE>make</CODE> invocations, the
|
|
<SAMP>`-w'</SAMP> or <SAMP>`--print-directory'</SAMP> option can make the output a
|
|
lot easier to understand by showing each directory as <CODE>make</CODE>
|
|
starts processing it and as <CODE>make</CODE> finishes processing it. For
|
|
example, if <SAMP>`make -w'</SAMP> is run in the directory <TT>`/u/gnu/make'</TT>,
|
|
<CODE>make</CODE> will print a line of the form:
|
|
</P>
|
|
|
|
<PRE>
|
|
make: Entering directory `/u/gnu/make'.
|
|
</PRE>
|
|
|
|
<P>
|
|
before doing anything else, and a line of the form:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
make: Leaving directory `/u/gnu/make'.
|
|
</PRE>
|
|
|
|
<P>
|
|
when processing is completed.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX395"></A>
|
|
<A NAME="IDX396"></A>
|
|
<A NAME="IDX397"></A>
|
|
<A NAME="IDX398"></A>
|
|
<A NAME="IDX399"></A>
|
|
<A NAME="IDX400"></A>
|
|
<A NAME="IDX401"></A>
|
|
<A NAME="IDX402"></A>
|
|
<A NAME="IDX403"></A>
|
|
<A NAME="IDX404"></A>
|
|
Normally, you do not need to specify this option because <SAMP>`make'</SAMP>
|
|
does it for you: <SAMP>`-w'</SAMP> is turned on automatically when you use the
|
|
<SAMP>`-C'</SAMP> option, and in sub-<CODE>make</CODE>s. <CODE>make</CODE> will not
|
|
automatically turn on <SAMP>`-w'</SAMP> if you also use <SAMP>`-s'</SAMP>, which says to
|
|
be silent, or if you use <SAMP>`--no-print-directory'</SAMP> to explicitly
|
|
disable it.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC55" HREF="make.html#TOC55">Defining Canned Command Sequences</A></H2>
|
|
<P>
|
|
<A NAME="IDX405"></A>
|
|
<A NAME="IDX406"></A>
|
|
|
|
</P>
|
|
<P>
|
|
When the same sequence of commands is useful in making various targets, you
|
|
can define it as a canned sequence with the <CODE>define</CODE> directive, and
|
|
refer to the canned sequence from the rules for those targets. The canned
|
|
sequence is actually a variable, so the name must not conflict with other
|
|
variable names.
|
|
|
|
</P>
|
|
<P>
|
|
Here is an example of defining a canned sequence of commands:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
define run-yacc
|
|
yacc $(firstword $^)
|
|
mv y.tab.c $@
|
|
endef
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX407"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Here <CODE>run-yacc</CODE> is the name of the variable being defined;
|
|
<CODE>endef</CODE> marks the end of the definition; the lines in between are the
|
|
commands. The <CODE>define</CODE> directive does not expand variable references
|
|
and function calls in the canned sequence; the <SAMP>`$'</SAMP> characters,
|
|
parentheses, variable names, and so on, all become part of the value of the
|
|
variable you are defining.
|
|
See section <A HREF="make.html#SEC67">Defining Variables Verbatim</A>,
|
|
for a complete explanation of <CODE>define</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
The first command in this example runs Yacc on the first prerequisite of
|
|
whichever rule uses the canned sequence. The output file from Yacc is
|
|
always named <TT>`y.tab.c'</TT>. The second command moves the output to the
|
|
rule's target file name.
|
|
|
|
</P>
|
|
<P>
|
|
To use the canned sequence, substitute the variable into the commands of a
|
|
rule. You can substitute it like any other variable
|
|
(see section <A HREF="make.html#SEC58">Basics of Variable References</A>).
|
|
Because variables defined by <CODE>define</CODE> are recursively expanded
|
|
variables, all the variable references you wrote inside the <CODE>define</CODE>
|
|
are expanded now. For example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo.c : foo.y
|
|
$(run-yacc)
|
|
</PRE>
|
|
|
|
<P>
|
|
<SAMP>`foo.y'</SAMP> will be substituted for the variable <SAMP>`$^'</SAMP> when it occurs in
|
|
<CODE>run-yacc</CODE>'s value, and <SAMP>`foo.c'</SAMP> for <SAMP>`$@'</SAMP>.
|
|
</P>
|
|
<P>
|
|
This is a realistic example, but this particular one is not needed in
|
|
practice because <CODE>make</CODE> has an implicit rule to figure out these
|
|
commands based on the file names involved
|
|
(see section <A HREF="make.html#SEC93">Using Implicit Rules</A>).
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX408"></A>
|
|
<A NAME="IDX409"></A>
|
|
<A NAME="IDX410"></A>
|
|
In command execution, each line of a canned sequence is treated just as
|
|
if the line appeared on its own in the rule, preceded by a tab. In
|
|
particular, <CODE>make</CODE> invokes a separate subshell for each line. You
|
|
can use the special prefix characters that affect command lines
|
|
(<SAMP>`@'</SAMP>, <SAMP>`-'</SAMP>, and <SAMP>`+'</SAMP>) on each line of a canned sequence.
|
|
See section <A HREF="make.html#SEC44">Writing the Commands in Rules</A>.
|
|
For example, using this canned sequence:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
define frobnicate
|
|
@echo "frobnicating target $@"
|
|
frob-step-1 $< -o $@-step-1
|
|
frob-step-2 $@-step-1 -o $@
|
|
endef
|
|
</PRE>
|
|
|
|
<P>
|
|
<CODE>make</CODE> will not echo the first line, the <CODE>echo</CODE> command.
|
|
But it <EM>will</EM> echo the following two command lines.
|
|
|
|
</P>
|
|
<P>
|
|
On the other hand, prefix characters on the command line that refers to
|
|
a canned sequence apply to every line in the sequence. So the rule:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
frob.out: frob.in
|
|
@$(frobnicate)
|
|
</PRE>
|
|
|
|
<P>
|
|
does not echo <EM>any</EM> commands.
|
|
(See section <A HREF="make.html#SEC45">Command Echoing</A>, for a full explanation of <SAMP>`@'</SAMP>.)
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC56" HREF="make.html#TOC56">Using Empty Commands</A></H2>
|
|
<P>
|
|
<A NAME="IDX411"></A>
|
|
<A NAME="IDX412"></A>
|
|
|
|
</P>
|
|
<P>
|
|
It is sometimes useful to define commands which do nothing. This is done
|
|
simply by giving a command that consists of nothing but whitespace. For
|
|
example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
target: ;
|
|
</PRE>
|
|
|
|
<P>
|
|
defines an empty command string for <TT>`target'</TT>. You could also use a
|
|
line beginning with a tab character to define an empty command string,
|
|
but this would be confusing because such a line looks empty.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX413"></A>
|
|
You may be wondering why you would want to define a command string that
|
|
does nothing. The only reason this is useful is to prevent a target
|
|
from getting implicit commands (from implicit rules or the
|
|
<CODE>.DEFAULT</CODE> special target; see section <A HREF="make.html#SEC93">Using Implicit Rules</A> and
|
|
see section <A HREF="make.html#SEC105">Defining Last-Resort Default Rules</A>).
|
|
</P>
|
|
|
|
<P>
|
|
You may be inclined to define empty command strings for targets that are
|
|
not actual files, but only exist so that their prerequisites can be
|
|
remade. However, this is not the best way to do that, because the
|
|
prerequisites may not be remade properly if the target file actually does exist.
|
|
See section <A HREF="make.html#SEC33">Phony Targets</A>, for a better way to do this.
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC57" HREF="make.html#TOC57">How to Use Variables</A></H1>
|
|
<P>
|
|
<A NAME="IDX414"></A>
|
|
<A NAME="IDX415"></A>
|
|
<A NAME="IDX416"></A>
|
|
<A NAME="IDX417"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A <STRONG>variable</STRONG> is a name defined in a makefile to represent a string
|
|
of text, called the variable's <STRONG>value</STRONG>. These values are
|
|
substituted by explicit request into targets, prerequisites, commands,
|
|
and other parts of the makefile. (In some other versions of <CODE>make</CODE>,
|
|
variables are called <STRONG>macros</STRONG>.)
|
|
<A NAME="IDX418"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Variables and functions in all parts of a makefile are expanded when
|
|
read, except for the shell commands in rules, the right-hand sides of
|
|
variable definitions using <SAMP>`='</SAMP>, and the bodies of variable
|
|
definitions using the <CODE>define</CODE> directive.
|
|
</P>
|
|
<P>
|
|
Variables can represent lists of file names, options to pass to compilers,
|
|
programs to run, directories to look in for source files, directories to
|
|
write output in, or anything else you can imagine.
|
|
|
|
</P>
|
|
<P>
|
|
A variable name may be any sequence of characters not containing <SAMP>`:'</SAMP>,
|
|
<SAMP>`#'</SAMP>, <SAMP>`='</SAMP>, or leading or trailing whitespace. However,
|
|
variable names containing characters other than letters, numbers, and
|
|
underscores should be avoided, as they may be given special meanings in the
|
|
future, and with some shells they cannot be passed through the environment to a
|
|
sub-<CODE>make</CODE>
|
|
(see section <A HREF="make.html#SEC52">Communicating Variables to a Sub-<CODE>make</CODE></A>).
|
|
|
|
</P>
|
|
<P>
|
|
Variable names are case-sensitive. The names <SAMP>`foo'</SAMP>, <SAMP>`FOO'</SAMP>,
|
|
and <SAMP>`Foo'</SAMP> all refer to different variables.
|
|
|
|
</P>
|
|
<P>
|
|
It is traditional to use upper case letters in variable names, but we
|
|
recommend using lower case letters for variable names that serve internal
|
|
purposes in the makefile, and reserving upper case for parameters that
|
|
control implicit rules or for parameters that the user should override with
|
|
command options (see section <A HREF="make.html#SEC90">Overriding Variables</A>).
|
|
|
|
</P>
|
|
<P>
|
|
A few variables have names that are a single punctuation character or
|
|
just a few characters. These are the <STRONG>automatic variables</STRONG>, and
|
|
they have particular specialized uses. See section <A HREF="make.html#SEC101">Automatic Variables</A>.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC58" HREF="make.html#TOC58">Basics of Variable References</A></H2>
|
|
<P>
|
|
<A NAME="IDX419"></A>
|
|
<A NAME="IDX420"></A>
|
|
<A NAME="IDX421"></A>
|
|
<A NAME="IDX422"></A>
|
|
|
|
</P>
|
|
<P>
|
|
To substitute a variable's value, write a dollar sign followed by the name
|
|
of the variable in parentheses or braces: either <SAMP>`$(foo)'</SAMP> or
|
|
<SAMP>`${foo}'</SAMP> is a valid reference to the variable <CODE>foo</CODE>. This
|
|
special significance of <SAMP>`$'</SAMP> is why you must write <SAMP>`$$'</SAMP> to have
|
|
the effect of a single dollar sign in a file name or command.
|
|
|
|
</P>
|
|
<P>
|
|
Variable references can be used in any context: targets, prerequisites,
|
|
commands, most directives, and new variable values. Here is an
|
|
example of a common case, where a variable holds the names of all the
|
|
object files in a program:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects = program.o foo.o utils.o
|
|
program : $(objects)
|
|
cc -o program $(objects)
|
|
|
|
$(objects) : defs.h
|
|
</PRE>
|
|
|
|
<P>
|
|
Variable references work by strict textual substitution. Thus, the rule
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo = c
|
|
prog.o : prog.$(foo)
|
|
$(foo)$(foo) -$(foo) prog.$(foo)
|
|
</PRE>
|
|
|
|
<P>
|
|
could be used to compile a C program <TT>`prog.c'</TT>. Since spaces before
|
|
the variable value are ignored in variable assignments, the value of
|
|
<CODE>foo</CODE> is precisely <SAMP>`c'</SAMP>. (Don't actually write your makefiles
|
|
this way!)
|
|
|
|
</P>
|
|
<P>
|
|
A dollar sign followed by a character other than a dollar sign,
|
|
open-parenthesis or open-brace treats that single character as the
|
|
variable name. Thus, you could reference the variable <CODE>x</CODE> with
|
|
<SAMP>`$x'</SAMP>. However, this practice is strongly discouraged, except in
|
|
the case of the automatic variables (see section <A HREF="make.html#SEC101">Automatic Variables</A>).
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC59" HREF="make.html#TOC59">The Two Flavors of Variables</A></H2>
|
|
<P>
|
|
<A NAME="IDX423"></A>
|
|
<A NAME="IDX424"></A>
|
|
<A NAME="IDX425"></A>
|
|
<A NAME="IDX426"></A>
|
|
<A NAME="IDX427"></A>
|
|
|
|
</P>
|
|
<P>
|
|
There are two ways that a variable in GNU <CODE>make</CODE> can have a value;
|
|
we call them the two <STRONG>flavors</STRONG> of variables. The two flavors are
|
|
distinguished in how they are defined and in what they do when expanded.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX428"></A>
|
|
The first flavor of variable is a <STRONG>recursively expanded</STRONG> variable.
|
|
Variables of this sort are defined by lines using <SAMP>`='</SAMP>
|
|
(see section <A HREF="make.html#SEC64">Setting Variables</A>) or by the <CODE>define</CODE> directive
|
|
(see section <A HREF="make.html#SEC67">Defining Variables Verbatim</A>). The value you specify
|
|
is installed verbatim; if it contains references to other variables,
|
|
these references are expanded whenever this variable is substituted (in
|
|
the course of expanding some other string). When this happens, it is
|
|
called <STRONG>recursive expansion</STRONG>.
|
|
</P>
|
|
<P>
|
|
For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo = $(bar)
|
|
bar = $(ugh)
|
|
ugh = Huh?
|
|
|
|
all:;echo $(foo)
|
|
</PRE>
|
|
|
|
<P>
|
|
will echo <SAMP>`Huh?'</SAMP>: <SAMP>`$(foo)'</SAMP> expands to <SAMP>`$(bar)'</SAMP> which
|
|
expands to <SAMP>`$(ugh)'</SAMP> which finally expands to <SAMP>`Huh?'</SAMP>.
|
|
</P>
|
|
<P>
|
|
This flavor of variable is the only sort supported by other versions of
|
|
<CODE>make</CODE>. It has its advantages and its disadvantages. An advantage
|
|
(most would say) is that:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
CFLAGS = $(include_dirs) -O
|
|
include_dirs = -Ifoo -Ibar
|
|
</PRE>
|
|
|
|
<P>
|
|
will do what was intended: when <SAMP>`CFLAGS'</SAMP> is expanded in a command,
|
|
it will expand to <SAMP>`-Ifoo -Ibar -O'</SAMP>. A major disadvantage is that you
|
|
cannot append something on the end of a variable, as in
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
CFLAGS = $(CFLAGS) -O
|
|
</PRE>
|
|
|
|
<P>
|
|
because it will cause an infinite loop in the variable expansion.
|
|
(Actually <CODE>make</CODE> detects the infinite loop and reports an error.)
|
|
<A NAME="IDX429"></A>
|
|
<A NAME="IDX430"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Another disadvantage is that any functions
|
|
(see section <A HREF="make.html#SEC75">Functions for Transforming Text</A>)
|
|
referenced in the definition will be executed every time the variable is
|
|
expanded. This makes <CODE>make</CODE> run slower; worse, it causes the
|
|
<CODE>wildcard</CODE> and <CODE>shell</CODE> functions to give unpredictable results
|
|
because you cannot easily control when they are called, or even how many
|
|
times.
|
|
|
|
</P>
|
|
<P>
|
|
To avoid all the problems and inconveniences of recursively expanded
|
|
variables, there is another flavor: simply expanded variables.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX431"></A>
|
|
<A NAME="IDX432"></A>
|
|
<A NAME="IDX433"></A>
|
|
<STRONG>Simply expanded variables</STRONG> are defined by lines using <SAMP>`:='</SAMP>
|
|
(see section <A HREF="make.html#SEC64">Setting Variables</A>).
|
|
The value of a simply expanded variable is scanned
|
|
once and for all, expanding any references to other variables and
|
|
functions, when the variable is defined. The actual value of the simply
|
|
expanded variable is the result of expanding the text that you write.
|
|
It does not contain any references to other variables; it contains their
|
|
values <EM>as of the time this variable was defined</EM>. Therefore,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
x := foo
|
|
y := $(x) bar
|
|
x := later
|
|
</PRE>
|
|
|
|
<P>
|
|
is equivalent to
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
y := foo bar
|
|
x := later
|
|
</PRE>
|
|
|
|
<P>
|
|
When a simply expanded variable is referenced, its value is substituted
|
|
verbatim.
|
|
|
|
</P>
|
|
<P>
|
|
Here is a somewhat more complicated example, illustrating the use of
|
|
<SAMP>`:='</SAMP> in conjunction with the <CODE>shell</CODE> function.
|
|
(See section <A HREF="make.html#SEC83">The <CODE>shell</CODE> Function</A>.) This example
|
|
also shows use of the variable <CODE>MAKELEVEL</CODE>, which is changed
|
|
when it is passed down from level to level.
|
|
(See section <A HREF="make.html#SEC52">Communicating Variables to a Sub-<CODE>make</CODE></A>, for information about <CODE>MAKELEVEL</CODE>.)
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX434"></A>
|
|
<A NAME="IDX435"></A>
|
|
|
|
<PRE>
|
|
ifeq (0,${MAKELEVEL})
|
|
cur-dir := $(shell pwd)
|
|
whoami := $(shell whoami)
|
|
host-type := $(shell arch)
|
|
MAKE := ${MAKE} host-type=${host-type} whoami=${whoami}
|
|
endif
|
|
</PRE>
|
|
|
|
<P>
|
|
An advantage of this use of <SAMP>`:='</SAMP> is that a typical
|
|
`descend into a directory' command then looks like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
${subdirs}:
|
|
${MAKE} cur-dir=${cur-dir}/$@ -C $@ all
|
|
</PRE>
|
|
|
|
<P>
|
|
Simply expanded variables generally make complicated makefile programming
|
|
more predictable because they work like variables in most programming
|
|
languages. They allow you to redefine a variable using its own value (or
|
|
its value processed in some way by one of the expansion functions) and to
|
|
use the expansion functions much more efficiently
|
|
(see section <A HREF="make.html#SEC75">Functions for Transforming Text</A>).
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX436"></A>
|
|
<A NAME="IDX437"></A>
|
|
<A NAME="IDX438"></A>
|
|
You can also use them to introduce controlled leading whitespace into
|
|
variable values. Leading whitespace characters are discarded from your
|
|
input before substitution of variable references and function calls;
|
|
this means you can include leading spaces in a variable value by
|
|
protecting them with variable references, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
nullstring :=
|
|
space := $(nullstring) # end of the line
|
|
</PRE>
|
|
|
|
<P>
|
|
Here the value of the variable <CODE>space</CODE> is precisely one space. The
|
|
comment <SAMP>`# end of the line'</SAMP> is included here just for clarity.
|
|
Since trailing space characters are <EM>not</EM> stripped from variable
|
|
values, just a space at the end of the line would have the same effect
|
|
(but be rather hard to read). If you put whitespace at the end of a
|
|
variable value, it is a good idea to put a comment like that at the end
|
|
of the line to make your intent clear. Conversely, if you do <EM>not</EM>
|
|
want any whitespace characters at the end of your variable value, you
|
|
must remember not to put a random comment on the end of the line after
|
|
some whitespace, such as this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
dir := /foo/bar # directory to put the frobs in
|
|
</PRE>
|
|
|
|
<P>
|
|
Here the value of the variable <CODE>dir</CODE> is <SAMP>`/foo/bar '</SAMP>
|
|
(with four trailing spaces), which was probably not the intention.
|
|
(Imagine something like <SAMP>`$(dir)/file'</SAMP> with this definition!)
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX439"></A>
|
|
<A NAME="IDX440"></A>
|
|
<A NAME="IDX441"></A>
|
|
There is another assignment operator for variables, <SAMP>`?='</SAMP>. This
|
|
is called a conditional variable assignment operator, because it only
|
|
has an effect if the variable is not yet defined. This statement:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
FOO ?= bar
|
|
</PRE>
|
|
|
|
<P>
|
|
is exactly equivalent to this
|
|
(see section <A HREF="make.html#SEC82">The <CODE>origin</CODE> Function</A>):
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
ifeq ($(origin FOO), undefined)
|
|
FOO = bar
|
|
endif
|
|
</PRE>
|
|
|
|
<P>
|
|
Note that a variable set to an empty value is still defined, so
|
|
<SAMP>`?='</SAMP> will not set that variable.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC60" HREF="make.html#TOC60">Advanced Features for Reference to Variables</A></H2>
|
|
<P>
|
|
<A NAME="IDX442"></A>
|
|
|
|
</P>
|
|
<P>
|
|
This section describes some advanced features you can use to reference
|
|
variables in more flexible ways.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC61" HREF="make.html#TOC61">Substitution References</A></H3>
|
|
<P>
|
|
<A NAME="IDX443"></A>
|
|
<A NAME="IDX444"></A>
|
|
<A NAME="IDX445"></A>
|
|
<A NAME="IDX446"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX447"></A>
|
|
<A NAME="IDX448"></A>
|
|
A <STRONG>substitution reference</STRONG> substitutes the value of a variable with
|
|
alterations that you specify. It has the form
|
|
<SAMP>`$(<VAR>var</VAR>:<VAR>a</VAR>=<VAR>b</VAR>)'</SAMP> (or
|
|
<SAMP>`${<VAR>var</VAR>:<VAR>a</VAR>=<VAR>b</VAR>}'</SAMP>) and its meaning is to take the value
|
|
of the variable <VAR>var</VAR>, replace every <VAR>a</VAR> at the end of a word with
|
|
<VAR>b</VAR> in that value, and substitute the resulting string.
|
|
|
|
</P>
|
|
<P>
|
|
When we say "at the end of a word", we mean that <VAR>a</VAR> must appear
|
|
either followed by whitespace or at the end of the value in order to be
|
|
replaced; other occurrences of <VAR>a</VAR> in the value are unaltered. For
|
|
example:
|
|
</P>
|
|
|
|
<PRE>
|
|
foo := a.o b.o c.o
|
|
bar := $(foo:.o=.c)
|
|
</PRE>
|
|
|
|
<P>
|
|
sets <SAMP>`bar'</SAMP> to <SAMP>`a.c b.c c.c'</SAMP>. See section <A HREF="make.html#SEC64">Setting Variables</A>.
|
|
|
|
</P>
|
|
<P>
|
|
A substitution reference is actually an abbreviation for use of the
|
|
<CODE>patsubst</CODE> expansion function (see section <A HREF="make.html#SEC77">Functions for String Substitution and Analysis</A>). We provide
|
|
substitution references as well as <CODE>patsubst</CODE> for compatibility with
|
|
other implementations of <CODE>make</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX449"></A>
|
|
Another type of substitution reference lets you use the full power of
|
|
the <CODE>patsubst</CODE> function. It has the same form
|
|
<SAMP>`$(<VAR>var</VAR>:<VAR>a</VAR>=<VAR>b</VAR>)'</SAMP> described above, except that now
|
|
<VAR>a</VAR> must contain a single <SAMP>`%'</SAMP> character. This case is
|
|
equivalent to <SAMP>`$(patsubst <VAR>a</VAR>,<VAR>b</VAR>,$(<VAR>var</VAR>))'</SAMP>.
|
|
See section <A HREF="make.html#SEC77">Functions for String Substitution and Analysis</A>,
|
|
for a description of the <CODE>patsubst</CODE> function.
|
|
</P>
|
|
|
|
<PRE>
|
|
For example:
|
|
|
|
foo := a.o b.o c.o
|
|
bar := $(foo:%.o=%.c)
|
|
</PRE>
|
|
|
|
<P>
|
|
sets <SAMP>`bar'</SAMP> to <SAMP>`a.c b.c c.c'</SAMP>.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC62" HREF="make.html#TOC62">Computed Variable Names</A></H3>
|
|
<P>
|
|
<A NAME="IDX450"></A>
|
|
<A NAME="IDX451"></A>
|
|
<A NAME="IDX452"></A>
|
|
<A NAME="IDX453"></A>
|
|
<A NAME="IDX454"></A>
|
|
<A NAME="IDX455"></A>
|
|
<A NAME="IDX456"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Computed variable names are a complicated concept needed only for
|
|
sophisticated makefile programming. For most purposes you need not
|
|
consider them, except to know that making a variable with a dollar sign
|
|
in its name might have strange results. However, if you are the type
|
|
that wants to understand everything, or you are actually interested in
|
|
what they do, read on.
|
|
|
|
</P>
|
|
<P>
|
|
Variables may be referenced inside the name of a variable. This is
|
|
called a <STRONG>computed variable name</STRONG> or a <STRONG>nested variable
|
|
reference</STRONG>. For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
x = y
|
|
y = z
|
|
a := $($(x))
|
|
</PRE>
|
|
|
|
<P>
|
|
defines <CODE>a</CODE> as <SAMP>`z'</SAMP>: the <SAMP>`$(x)'</SAMP> inside <SAMP>`$($(x))'</SAMP> expands
|
|
to <SAMP>`y'</SAMP>, so <SAMP>`$($(x))'</SAMP> expands to <SAMP>`$(y)'</SAMP> which in turn expands
|
|
to <SAMP>`z'</SAMP>. Here the name of the variable to reference is not stated
|
|
explicitly; it is computed by expansion of <SAMP>`$(x)'</SAMP>. The reference
|
|
<SAMP>`$(x)'</SAMP> here is nested within the outer variable reference.
|
|
|
|
</P>
|
|
<P>
|
|
The previous example shows two levels of nesting, but any number of levels
|
|
is possible. For example, here are three levels:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
x = y
|
|
y = z
|
|
z = u
|
|
a := $($($(x)))
|
|
</PRE>
|
|
|
|
<P>
|
|
Here the innermost <SAMP>`$(x)'</SAMP> expands to <SAMP>`y'</SAMP>, so <SAMP>`$($(x))'</SAMP>
|
|
expands to <SAMP>`$(y)'</SAMP> which in turn expands to <SAMP>`z'</SAMP>; now we have
|
|
<SAMP>`$(z)'</SAMP>, which becomes <SAMP>`u'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
References to recursively-expanded variables within a variable name are
|
|
reexpanded in the usual fashion. For example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
x = $(y)
|
|
y = z
|
|
z = Hello
|
|
a := $($(x))
|
|
</PRE>
|
|
|
|
<P>
|
|
defines <CODE>a</CODE> as <SAMP>`Hello'</SAMP>: <SAMP>`$($(x))'</SAMP> becomes <SAMP>`$($(y))'</SAMP>
|
|
which becomes <SAMP>`$(z)'</SAMP> which becomes <SAMP>`Hello'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
Nested variable references can also contain modified references and
|
|
function invocations (see section <A HREF="make.html#SEC75">Functions for Transforming Text</A>),
|
|
just like any other reference.
|
|
For example, using the <CODE>subst</CODE> function
|
|
(see section <A HREF="make.html#SEC77">Functions for String Substitution and Analysis</A>):
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
x = variable1
|
|
variable2 := Hello
|
|
y = $(subst 1,2,$(x))
|
|
z = y
|
|
a := $($($(z)))
|
|
</PRE>
|
|
|
|
<P>
|
|
eventually defines <CODE>a</CODE> as <SAMP>`Hello'</SAMP>. It is doubtful that anyone
|
|
would ever want to write a nested reference as convoluted as this one, but
|
|
it works: <SAMP>`$($($(z)))'</SAMP> expands to <SAMP>`$($(y))'</SAMP> which becomes
|
|
<SAMP>`$($(subst 1,2,$(x)))'</SAMP>. This gets the value <SAMP>`variable1'</SAMP> from
|
|
<CODE>x</CODE> and changes it by substitution to <SAMP>`variable2'</SAMP>, so that the
|
|
entire string becomes <SAMP>`$(variable2)'</SAMP>, a simple variable reference
|
|
whose value is <SAMP>`Hello'</SAMP>.
|
|
</P>
|
|
<P>
|
|
A computed variable name need not consist entirely of a single variable
|
|
reference. It can contain several variable references, as well as some
|
|
invariant text. For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
a_dirs := dira dirb
|
|
1_dirs := dir1 dir2
|
|
|
|
a_files := filea fileb
|
|
1_files := file1 file2
|
|
|
|
ifeq "$(use_a)" "yes"
|
|
a1 := a
|
|
else
|
|
a1 := 1
|
|
endif
|
|
|
|
ifeq "$(use_dirs)" "yes"
|
|
df := dirs
|
|
else
|
|
df := files
|
|
endif
|
|
|
|
dirs := $($(a1)_$(df))
|
|
</PRE>
|
|
|
|
<P>
|
|
will give <CODE>dirs</CODE> the same value as <CODE>a_dirs</CODE>, <CODE>1_dirs</CODE>,
|
|
<CODE>a_files</CODE> or <CODE>1_files</CODE> depending on the settings of <CODE>use_a</CODE>
|
|
and <CODE>use_dirs</CODE>.
|
|
</P>
|
|
<P>
|
|
Computed variable names can also be used in substitution references:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
a_objects := a.o b.o c.o
|
|
1_objects := 1.o 2.o 3.o
|
|
|
|
sources := $($(a1)_objects:.o=.c)
|
|
</PRE>
|
|
|
|
<P>
|
|
defines <CODE>sources</CODE> as either <SAMP>`a.c b.c c.c'</SAMP> or <SAMP>`1.c 2.c 3.c'</SAMP>,
|
|
depending on the value of <CODE>a1</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
The only restriction on this sort of use of nested variable references
|
|
is that they cannot specify part of the name of a function to be called.
|
|
This is because the test for a recognized function name is done before
|
|
the expansion of nested references. For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
ifdef do_sort
|
|
func := sort
|
|
else
|
|
func := strip
|
|
endif
|
|
|
|
bar := a d b g q c
|
|
|
|
foo := $($(func) $(bar))
|
|
</PRE>
|
|
|
|
<P>
|
|
attempts to give <SAMP>`foo'</SAMP> the value of the variable <SAMP>`sort a d b g
|
|
q c'</SAMP> or <SAMP>`strip a d b g q c'</SAMP>, rather than giving <SAMP>`a d b g q c'</SAMP>
|
|
as the argument to either the <CODE>sort</CODE> or the <CODE>strip</CODE> function.
|
|
This restriction could be removed in the future if that change is shown
|
|
to be a good idea.
|
|
|
|
</P>
|
|
<P>
|
|
You can also use computed variable names in the left-hand side of a
|
|
variable assignment, or in a <CODE>define</CODE> directive, as in:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
dir = foo
|
|
$(dir)_sources := $(wildcard $(dir)/*.c)
|
|
define $(dir)_print
|
|
lpr $($(dir)_sources)
|
|
endef
|
|
</PRE>
|
|
|
|
<P>
|
|
This example defines the variables <SAMP>`dir'</SAMP>, <SAMP>`foo_sources'</SAMP>, and
|
|
<SAMP>`foo_print'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
Note that <STRONG>nested variable references</STRONG> are quite different from
|
|
<STRONG>recursively expanded variables</STRONG>
|
|
(see section <A HREF="make.html#SEC59">The Two Flavors of Variables</A>), though both are
|
|
used together in complex ways when doing makefile programming.
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC63" HREF="make.html#TOC63">How Variables Get Their Values</A></H2>
|
|
<P>
|
|
<A NAME="IDX457"></A>
|
|
<A NAME="IDX458"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Variables can get values in several different ways:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
You can specify an overriding value when you run <CODE>make</CODE>.
|
|
See section <A HREF="make.html#SEC90">Overriding Variables</A>.
|
|
|
|
<LI>
|
|
|
|
You can specify a value in the makefile, either
|
|
with an assignment (see section <A HREF="make.html#SEC64">Setting Variables</A>) or with a
|
|
verbatim definition (see section <A HREF="make.html#SEC67">Defining Variables Verbatim</A>).
|
|
<LI>
|
|
|
|
Variables in the environment become <CODE>make</CODE> variables.
|
|
See section <A HREF="make.html#SEC68">Variables from the Environment</A>.
|
|
|
|
<LI>
|
|
|
|
Several <STRONG>automatic</STRONG> variables are given new values for each rule.
|
|
Each of these has a single conventional use.
|
|
See section <A HREF="make.html#SEC101">Automatic Variables</A>.
|
|
|
|
<LI>
|
|
|
|
Several variables have constant initial values.
|
|
See section <A HREF="make.html#SEC96">Variables Used by Implicit Rules</A>.
|
|
</UL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC64" HREF="make.html#TOC64">Setting Variables</A></H2>
|
|
<P>
|
|
<A NAME="IDX459"></A>
|
|
<A NAME="IDX460"></A>
|
|
<A NAME="IDX461"></A>
|
|
<A NAME="IDX462"></A>
|
|
<A NAME="IDX463"></A>
|
|
|
|
</P>
|
|
<P>
|
|
To set a variable from the makefile, write a line starting with the
|
|
variable name followed by <SAMP>`='</SAMP> or <SAMP>`:='</SAMP>. Whatever follows the
|
|
<SAMP>`='</SAMP> or <SAMP>`:='</SAMP> on the line becomes the value. For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects = main.o foo.o bar.o utils.o
|
|
</PRE>
|
|
|
|
<P>
|
|
defines a variable named <CODE>objects</CODE>. Whitespace around the variable
|
|
name and immediately after the <SAMP>`='</SAMP> is ignored.
|
|
|
|
</P>
|
|
<P>
|
|
Variables defined with <SAMP>`='</SAMP> are <STRONG>recursively expanded</STRONG> variables.
|
|
Variables defined with <SAMP>`:='</SAMP> are <STRONG>simply expanded</STRONG> variables; these
|
|
definitions can contain variable references which will be expanded before
|
|
the definition is made. See section <A HREF="make.html#SEC59">The Two Flavors of Variables</A>.
|
|
|
|
</P>
|
|
<P>
|
|
The variable name may contain function and variable references, which
|
|
are expanded when the line is read to find the actual variable name to use.
|
|
|
|
</P>
|
|
<P>
|
|
There is no limit on the length of the value of a variable except the
|
|
amount of swapping space on the computer. When a variable definition is
|
|
long, it is a good idea to break it into several lines by inserting
|
|
backslash-newline at convenient places in the definition. This will not
|
|
affect the functioning of <CODE>make</CODE>, but it will make the makefile easier
|
|
to read.
|
|
|
|
</P>
|
|
<P>
|
|
Most variable names are considered to have the empty string as a value if
|
|
you have never set them. Several variables have built-in initial values
|
|
that are not empty, but you can set them in the usual ways
|
|
(see section <A HREF="make.html#SEC96">Variables Used by Implicit Rules</A>).
|
|
Several special variables are set
|
|
automatically to a new value for each rule; these are called the
|
|
<STRONG>automatic</STRONG> variables (see section <A HREF="make.html#SEC101">Automatic Variables</A>).
|
|
|
|
</P>
|
|
<P>
|
|
If you'd like a variable to be set to a value only if it's not already
|
|
set, then you can use the shorthand operator <SAMP>`?='</SAMP> instead of
|
|
<SAMP>`='</SAMP>. These two settings of the variable <SAMP>`FOO'</SAMP> are identical
|
|
(see section <A HREF="make.html#SEC82">The <CODE>origin</CODE> Function</A>):
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
FOO ?= bar
|
|
</PRE>
|
|
|
|
<P>
|
|
and
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
ifeq ($(origin FOO), undefined)
|
|
FOO = bar
|
|
endif
|
|
</PRE>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC65" HREF="make.html#TOC65">Appending More Text to Variables</A></H2>
|
|
<P>
|
|
<A NAME="IDX464"></A>
|
|
<A NAME="IDX465"></A>
|
|
<A NAME="IDX466"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Often it is useful to add more text to the value of a variable already defined.
|
|
You do this with a line containing <SAMP>`+='</SAMP>, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects += another.o
|
|
</PRE>
|
|
|
|
<P>
|
|
This takes the value of the variable <CODE>objects</CODE>, and adds the text
|
|
<SAMP>`another.o'</SAMP> to it (preceded by a single space). Thus:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects = main.o foo.o bar.o utils.o
|
|
objects += another.o
|
|
</PRE>
|
|
|
|
<P>
|
|
sets <CODE>objects</CODE> to <SAMP>`main.o foo.o bar.o utils.o another.o'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
Using <SAMP>`+='</SAMP> is similar to:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
objects = main.o foo.o bar.o utils.o
|
|
objects := $(objects) another.o
|
|
</PRE>
|
|
|
|
<P>
|
|
but differs in ways that become important when you use more complex values.
|
|
|
|
</P>
|
|
<P>
|
|
When the variable in question has not been defined before, <SAMP>`+='</SAMP>
|
|
acts just like normal <SAMP>`='</SAMP>: it defines a recursively-expanded
|
|
variable. However, when there <EM>is</EM> a previous definition, exactly
|
|
what <SAMP>`+='</SAMP> does depends on what flavor of variable you defined
|
|
originally. See section <A HREF="make.html#SEC59">The Two Flavors of Variables</A>, for an
|
|
explanation of the two flavors of variables.
|
|
|
|
</P>
|
|
<P>
|
|
When you add to a variable's value with <SAMP>`+='</SAMP>, <CODE>make</CODE> acts
|
|
essentially as if you had included the extra text in the initial
|
|
definition of the variable. If you defined it first with <SAMP>`:='</SAMP>,
|
|
making it a simply-expanded variable, <SAMP>`+='</SAMP> adds to that
|
|
simply-expanded definition, and expands the new text before appending it
|
|
to the old value just as <SAMP>`:='</SAMP> does
|
|
(see section <A HREF="make.html#SEC64">Setting Variables</A>, for a full explanation of <SAMP>`:='</SAMP>).
|
|
In fact,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
variable := value
|
|
variable += more
|
|
</PRE>
|
|
|
|
<P>
|
|
is exactly equivalent to:
|
|
|
|
</P>
|
|
<P>
|
|
|
|
<PRE>
|
|
variable := value
|
|
variable := $(variable) more
|
|
</PRE>
|
|
|
|
<P>
|
|
On the other hand, when you use <SAMP>`+='</SAMP> with a variable that you defined
|
|
first to be recursively-expanded using plain <SAMP>`='</SAMP>, <CODE>make</CODE> does
|
|
something a bit different. Recall that when you define a
|
|
recursively-expanded variable, <CODE>make</CODE> does not expand the value you set
|
|
for variable and function references immediately. Instead it stores the text
|
|
verbatim, and saves these variable and function references to be expanded
|
|
later, when you refer to the new variable (see section <A HREF="make.html#SEC59">The Two Flavors of Variables</A>). When you use <SAMP>`+='</SAMP> on a recursively-expanded variable,
|
|
it is this unexpanded text to which <CODE>make</CODE> appends the new text you
|
|
specify.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
variable = value
|
|
variable += more
|
|
</PRE>
|
|
|
|
<P>
|
|
is roughly equivalent to:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
temp = value
|
|
variable = $(temp) more
|
|
</PRE>
|
|
|
|
<P>
|
|
except that of course it never defines a variable called <CODE>temp</CODE>.
|
|
The importance of this comes when the variable's old value contains
|
|
variable references. Take this common example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
CFLAGS = $(includes) -O
|
|
...
|
|
CFLAGS += -pg # enable profiling
|
|
</PRE>
|
|
|
|
<P>
|
|
The first line defines the <CODE>CFLAGS</CODE> variable with a reference to another
|
|
variable, <CODE>includes</CODE>. (<CODE>CFLAGS</CODE> is used by the rules for C
|
|
compilation; see section <A HREF="make.html#SEC95">Catalogue of Implicit Rules</A>.)
|
|
Using <SAMP>`='</SAMP> for the definition makes <CODE>CFLAGS</CODE> a recursively-expanded
|
|
variable, meaning <SAMP>`$(includes) -O'</SAMP> is <EM>not</EM> expanded when
|
|
<CODE>make</CODE> processes the definition of <CODE>CFLAGS</CODE>. Thus, <CODE>includes</CODE>
|
|
need not be defined yet for its value to take effect. It only has to be
|
|
defined before any reference to <CODE>CFLAGS</CODE>. If we tried to append to the
|
|
value of <CODE>CFLAGS</CODE> without using <SAMP>`+='</SAMP>, we might do it like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
CFLAGS := $(CFLAGS) -pg # enable profiling
|
|
</PRE>
|
|
|
|
<P>
|
|
This is pretty close, but not quite what we want. Using <SAMP>`:='</SAMP>
|
|
redefines <CODE>CFLAGS</CODE> as a simply-expanded variable; this means
|
|
<CODE>make</CODE> expands the text <SAMP>`$(CFLAGS) -pg'</SAMP> before setting the
|
|
variable. If <CODE>includes</CODE> is not yet defined, we get <SAMP>` -O
|
|
-pg'</SAMP>, and a later definition of <CODE>includes</CODE> will have no effect.
|
|
Conversely, by using <SAMP>`+='</SAMP> we set <CODE>CFLAGS</CODE> to the
|
|
<EM>unexpanded</EM> value <SAMP>`$(includes) -O -pg'</SAMP>. Thus we preserve
|
|
the reference to <CODE>includes</CODE>, so if that variable gets defined at
|
|
any later point, a reference like <SAMP>`$(CFLAGS)'</SAMP> still uses its
|
|
value.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC66" HREF="make.html#TOC66">The <CODE>override</CODE> Directive</A></H2>
|
|
<P>
|
|
<A NAME="IDX467"></A>
|
|
<A NAME="IDX468"></A>
|
|
<A NAME="IDX469"></A>
|
|
|
|
</P>
|
|
<P>
|
|
If a variable has been set with a command argument
|
|
(see section <A HREF="make.html#SEC90">Overriding Variables</A>),
|
|
then ordinary assignments in the makefile are ignored. If you want to set
|
|
the variable in the makefile even though it was set with a command
|
|
argument, you can use an <CODE>override</CODE> directive, which is a line that
|
|
looks like this:
|
|
</P>
|
|
|
|
<PRE>
|
|
override <VAR>variable</VAR> = <VAR>value</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
or
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
override <VAR>variable</VAR> := <VAR>value</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
To append more text to a variable defined on the command line, use:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
override <VAR>variable</VAR> += <VAR>more text</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
See section <A HREF="make.html#SEC65">Appending More Text to Variables</A>.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>override</CODE> directive was not invented for escalation in the war
|
|
between makefiles and command arguments. It was invented so you can alter
|
|
and add to values that the user specifies with command arguments.
|
|
|
|
</P>
|
|
<P>
|
|
For example, suppose you always want the <SAMP>`-g'</SAMP> switch when you run the
|
|
C compiler, but you would like to allow the user to specify the other
|
|
switches with a command argument just as usual. You could use this
|
|
<CODE>override</CODE> directive:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
override CFLAGS += -g
|
|
</PRE>
|
|
|
|
<P>
|
|
You can also use <CODE>override</CODE> directives with <CODE>define</CODE> directives.
|
|
This is done as you might expect:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
override define foo
|
|
bar
|
|
endef
|
|
</PRE>
|
|
|
|
<P>
|
|
See the next section for information about <CODE>define</CODE>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC67" HREF="make.html#TOC67">Defining Variables Verbatim</A></H2>
|
|
<P>
|
|
<A NAME="IDX470"></A>
|
|
<A NAME="IDX471"></A>
|
|
<A NAME="IDX472"></A>
|
|
<A NAME="IDX473"></A>
|
|
<A NAME="IDX474"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Another way to set the value of a variable is to use the <CODE>define</CODE>
|
|
directive. This directive has an unusual syntax which allows newline
|
|
characters to be included in the value, which is convenient for defining
|
|
canned sequences of commands
|
|
(see section <A HREF="make.html#SEC55">Defining Canned Command Sequences</A>).
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>define</CODE> directive is followed on the same line by the name of the
|
|
variable and nothing more. The value to give the variable appears on the
|
|
following lines. The end of the value is marked by a line containing just
|
|
the word <CODE>endef</CODE>. Aside from this difference in syntax, <CODE>define</CODE>
|
|
works just like <SAMP>`='</SAMP>: it creates a recursively-expanded variable
|
|
(see section <A HREF="make.html#SEC59">The Two Flavors of Variables</A>).
|
|
The variable name may contain function and variable references, which
|
|
are expanded when the directive is read to find the actual variable name
|
|
to use.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
define two-lines
|
|
echo foo
|
|
echo $(bar)
|
|
endef
|
|
</PRE>
|
|
|
|
<P>
|
|
The value in an ordinary assignment cannot contain a newline; but the
|
|
newlines that separate the lines of the value in a <CODE>define</CODE> become
|
|
part of the variable's value (except for the final newline which precedes
|
|
the <CODE>endef</CODE> and is not considered part of the value).
|
|
</P>
|
|
<P>
|
|
The previous example is functionally equivalent to this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
two-lines = echo foo; echo $(bar)
|
|
</PRE>
|
|
|
|
<P>
|
|
since two commands separated by semicolon behave much like two separate
|
|
shell commands. However, note that using two separate lines means
|
|
<CODE>make</CODE> will invoke the shell twice, running an independent subshell
|
|
for each line. See section <A HREF="make.html#SEC46">Command Execution</A>.
|
|
|
|
</P>
|
|
<P>
|
|
If you want variable definitions made with <CODE>define</CODE> to take
|
|
precedence over command-line variable definitions, you can use the
|
|
<CODE>override</CODE> directive together with <CODE>define</CODE>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
override define two-lines
|
|
foo
|
|
$(bar)
|
|
endef
|
|
</PRE>
|
|
|
|
<P>
|
|
See section <A HREF="make.html#SEC66">The <CODE>override</CODE> Directive</A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC68" HREF="make.html#TOC68">Variables from the Environment</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX475"></A>
|
|
<A NAME="IDX476"></A>
|
|
Variables in <CODE>make</CODE> can come from the environment in which
|
|
<CODE>make</CODE> is run. Every environment variable that <CODE>make</CODE> sees when
|
|
it starts up is transformed into a <CODE>make</CODE> variable with the same name
|
|
and value. But an explicit assignment in the makefile, or with a command
|
|
argument, overrides the environment. (If the <SAMP>`-e'</SAMP> flag is specified,
|
|
then values from the environment override assignments in the makefile.
|
|
See section <A HREF="make.html#SEC92">Summary of Options</A>.
|
|
But this is not recommended practice.)
|
|
|
|
</P>
|
|
<P>
|
|
Thus, by setting the variable <CODE>CFLAGS</CODE> in your environment, you can
|
|
cause all C compilations in most makefiles to use the compiler switches you
|
|
prefer. This is safe for variables with standard or conventional meanings
|
|
because you know that no makefile will use them for other things. (But
|
|
this is not totally reliable; some makefiles set <CODE>CFLAGS</CODE> explicitly
|
|
and therefore are not affected by the value in the environment.)
|
|
|
|
</P>
|
|
<P>
|
|
When <CODE>make</CODE> is invoked recursively, variables defined in the
|
|
outer invocation can be passed to inner invocations through the
|
|
environment (see section <A HREF="make.html#SEC50">Recursive Use of <CODE>make</CODE></A>). By
|
|
default, only variables that came from the environment or the command
|
|
line are passed to recursive invocations. You can use the
|
|
<CODE>export</CODE> directive to pass other variables.
|
|
See section <A HREF="make.html#SEC52">Communicating Variables to a Sub-<CODE>make</CODE></A>, for full details.
|
|
|
|
</P>
|
|
<P>
|
|
Other use of variables from the environment is not recommended. It is not
|
|
wise for makefiles to depend for their functioning on environment variables
|
|
set up outside their control, since this would cause different users to get
|
|
different results from the same makefile. This is against the whole
|
|
purpose of most makefiles.
|
|
|
|
</P>
|
|
<P>
|
|
Such problems would be especially likely with the variable <CODE>SHELL</CODE>,
|
|
which is normally present in the environment to specify the user's choice
|
|
of interactive shell. It would be very undesirable for this choice to
|
|
affect <CODE>make</CODE>. So <CODE>make</CODE> ignores the environment value of
|
|
<CODE>SHELL</CODE> (except on MS-DOS and MS-Windows, where <CODE>SHELL</CODE> is
|
|
usually not set. See section <A HREF="make.html#SEC46">Command Execution</A>.)
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC69" HREF="make.html#TOC69">Target-specific Variable Values</A></H2>
|
|
<P>
|
|
<A NAME="IDX477"></A>
|
|
<A NAME="IDX478"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Variable values in <CODE>make</CODE> are usually global; that is, they are the
|
|
same regardless of where they are evaluated (unless they're reset, of
|
|
course). One exception to that is automatic variables
|
|
(see section <A HREF="make.html#SEC101">Automatic Variables</A>).
|
|
|
|
</P>
|
|
<P>
|
|
The other exception is <STRONG>target-specific variable values</STRONG>. This
|
|
feature allows you to define different values for the same variable,
|
|
based on the target that <CODE>make</CODE> is currently building. As with
|
|
automatic variables, these values are only available within the context
|
|
of a target's command script (and in other target-specific assignments).
|
|
|
|
</P>
|
|
<P>
|
|
Set a target-specific variable value like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>target</VAR> ... : <VAR>variable-assignment</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
or like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>target</VAR> ... : override <VAR>variable-assignment</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
Multiple <VAR>target</VAR> values create a target-specific variable value for
|
|
each member of the target list individually.
|
|
|
|
</P>
|
|
<P>
|
|
The <VAR>variable-assignment</VAR> can be any valid form of assignment;
|
|
recursive (<SAMP>`='</SAMP>), static (<SAMP>`:='</SAMP>), appending (<SAMP>`+='</SAMP>), or
|
|
conditional (<SAMP>`?='</SAMP>). All variables that appear within the
|
|
<VAR>variable-assignment</VAR> are evaluated within the context of the
|
|
target: thus, any previously-defined target-specific variable values
|
|
will be in effect. Note that this variable is actually distinct from
|
|
any "global" value: the two variables do not have to have the same
|
|
flavor (recursive vs. static).
|
|
|
|
</P>
|
|
<P>
|
|
Target-specific variables have the same priority as any other makefile
|
|
variable. Variables provided on the command-line (and in the
|
|
environment if the <SAMP>`-e'</SAMP> option is in force) will take precedence.
|
|
Specifying the <CODE>override</CODE> directive will allow the target-specific
|
|
variable value to be preferred.
|
|
|
|
</P>
|
|
<P>
|
|
There is one more special feature of target-specific variables: when you
|
|
define a target-specific variable, that variable value is also in effect
|
|
for all prerequisites of this target (unless those prerequisites override
|
|
it with their own target-specific variable value). So, for example, a
|
|
statement like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
prog : CFLAGS = -g
|
|
prog : prog.o foo.o bar.o
|
|
</PRE>
|
|
|
|
<P>
|
|
will set <CODE>CFLAGS</CODE> to <SAMP>`-g'</SAMP> in the command script for
|
|
<TT>`prog'</TT>, but it will also set <CODE>CFLAGS</CODE> to <SAMP>`-g'</SAMP> in the
|
|
command scripts that create <TT>`prog.o'</TT>, <TT>`foo.o'</TT>, and
|
|
<TT>`bar.o'</TT>, and any command scripts which create their prerequisites.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC70" HREF="make.html#TOC70">Pattern-specific Variable Values</A></H2>
|
|
<P>
|
|
<A NAME="IDX479"></A>
|
|
<A NAME="IDX480"></A>
|
|
|
|
</P>
|
|
<P>
|
|
In addition to target-specific variable values (see section <A HREF="make.html#SEC69">Target-specific Variable Values</A>), GNU <CODE>make</CODE> supports
|
|
pattern-specific variable values. In this form, a variable is defined
|
|
for any target that matches the pattern specified. Variables defined in
|
|
this way are searched after any target-specific variables defined
|
|
explicitly for that target, and before target-specific variables defined
|
|
for the parent target.
|
|
|
|
</P>
|
|
<P>
|
|
Set a pattern-specific variable value like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>pattern</VAR> ... : <VAR>variable-assignment</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
or like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>pattern</VAR> ... : override <VAR>variable-assignment</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
where <VAR>pattern</VAR> is a %-pattern. As with target-specific variable
|
|
values, multiple <VAR>pattern</VAR> values create a pattern-specific variable
|
|
value for each pattern individually. The <VAR>variable-assignment</VAR> can
|
|
be any valid form of assignment. Any command-line variable setting will
|
|
take precedence, unless <CODE>override</CODE> is specified.
|
|
|
|
</P>
|
|
<P>
|
|
For example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
%.o : CFLAGS = -O
|
|
</PRE>
|
|
|
|
<P>
|
|
will assign <CODE>CFLAGS</CODE> the value of <SAMP>`-O'</SAMP> for all targets
|
|
matching the pattern <CODE>%.o</CODE>.
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC71" HREF="make.html#TOC71">Conditional Parts of Makefiles</A></H1>
|
|
|
|
<P>
|
|
<A NAME="IDX481"></A>
|
|
A <STRONG>conditional</STRONG> causes part of a makefile to be obeyed or ignored
|
|
depending on the values of variables. Conditionals can compare the
|
|
value of one variable to another, or the value of a variable to
|
|
a constant string. Conditionals control what <CODE>make</CODE> actually
|
|
"sees" in the makefile, so they <EM>cannot</EM> be used to control shell
|
|
commands at the time of execution.
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC72" HREF="make.html#TOC72">Example of a Conditional</A></H2>
|
|
|
|
<P>
|
|
The following example of a conditional tells <CODE>make</CODE> to use one set
|
|
of libraries if the <CODE>CC</CODE> variable is <SAMP>`gcc'</SAMP>, and a different
|
|
set of libraries otherwise. It works by controlling which of two
|
|
command lines will be used as the command for a rule. The result is
|
|
that <SAMP>`CC=gcc'</SAMP> as an argument to <CODE>make</CODE> changes not only which
|
|
compiler is used but also which libraries are linked.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
libs_for_gcc = -lgnu
|
|
normal_libs =
|
|
|
|
foo: $(objects)
|
|
ifeq ($(CC),gcc)
|
|
$(CC) -o foo $(objects) $(libs_for_gcc)
|
|
else
|
|
$(CC) -o foo $(objects) $(normal_libs)
|
|
endif
|
|
</PRE>
|
|
|
|
<P>
|
|
This conditional uses three directives: one <CODE>ifeq</CODE>, one <CODE>else</CODE>
|
|
and one <CODE>endif</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>ifeq</CODE> directive begins the conditional, and specifies the
|
|
condition. It contains two arguments, separated by a comma and surrounded
|
|
by parentheses. Variable substitution is performed on both arguments and
|
|
then they are compared. The lines of the makefile following the
|
|
<CODE>ifeq</CODE> are obeyed if the two arguments match; otherwise they are
|
|
ignored.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>else</CODE> directive causes the following lines to be obeyed if the
|
|
previous conditional failed. In the example above, this means that the
|
|
second alternative linking command is used whenever the first alternative
|
|
is not used. It is optional to have an <CODE>else</CODE> in a conditional.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>endif</CODE> directive ends the conditional. Every conditional must
|
|
end with an <CODE>endif</CODE>. Unconditional makefile text follows.
|
|
|
|
</P>
|
|
<P>
|
|
As this example illustrates, conditionals work at the textual level:
|
|
the lines of the conditional are treated as part of the makefile, or
|
|
ignored, according to the condition. This is why the larger syntactic
|
|
units of the makefile, such as rules, may cross the beginning or the
|
|
end of the conditional.
|
|
|
|
</P>
|
|
<P>
|
|
When the variable <CODE>CC</CODE> has the value <SAMP>`gcc'</SAMP>, the above example has
|
|
this effect:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo: $(objects)
|
|
$(CC) -o foo $(objects) $(libs_for_gcc)
|
|
</PRE>
|
|
|
|
<P>
|
|
When the variable <CODE>CC</CODE> has any other value, the effect is this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo: $(objects)
|
|
$(CC) -o foo $(objects) $(normal_libs)
|
|
</PRE>
|
|
|
|
<P>
|
|
Equivalent results can be obtained in another way by conditionalizing a
|
|
variable assignment and then using the variable unconditionally:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
libs_for_gcc = -lgnu
|
|
normal_libs =
|
|
|
|
ifeq ($(CC),gcc)
|
|
libs=$(libs_for_gcc)
|
|
else
|
|
libs=$(normal_libs)
|
|
endif
|
|
|
|
foo: $(objects)
|
|
$(CC) -o foo $(objects) $(libs)
|
|
</PRE>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC73" HREF="make.html#TOC73">Syntax of Conditionals</A></H2>
|
|
<P>
|
|
<A NAME="IDX482"></A>
|
|
<A NAME="IDX483"></A>
|
|
<A NAME="IDX484"></A>
|
|
<A NAME="IDX485"></A>
|
|
<A NAME="IDX486"></A>
|
|
<A NAME="IDX487"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The syntax of a simple conditional with no <CODE>else</CODE> is as follows:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>conditional-directive</VAR>
|
|
<VAR>text-if-true</VAR>
|
|
endif
|
|
</PRE>
|
|
|
|
<P>
|
|
The <VAR>text-if-true</VAR> may be any lines of text, to be considered as part
|
|
of the makefile if the condition is true. If the condition is false, no
|
|
text is used instead.
|
|
|
|
</P>
|
|
<P>
|
|
The syntax of a complex conditional is as follows:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>conditional-directive</VAR>
|
|
<VAR>text-if-true</VAR>
|
|
else
|
|
<VAR>text-if-false</VAR>
|
|
endif
|
|
</PRE>
|
|
|
|
<P>
|
|
If the condition is true, <VAR>text-if-true</VAR> is used; otherwise,
|
|
<VAR>text-if-false</VAR> is used instead. The <VAR>text-if-false</VAR> can be any
|
|
number of lines of text.
|
|
|
|
</P>
|
|
<P>
|
|
The syntax of the <VAR>conditional-directive</VAR> is the same whether the
|
|
conditional is simple or complex. There are four different directives that
|
|
test different conditions. Here is a table of them:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>ifeq (<VAR>arg1</VAR>, <VAR>arg2</VAR>)</CODE>
|
|
<DD>
|
|
<DT><CODE>ifeq '<VAR>arg1</VAR>' '<VAR>arg2</VAR>'</CODE>
|
|
<DD>
|
|
<DT><CODE>ifeq "<VAR>arg1</VAR>" "<VAR>arg2</VAR>"</CODE>
|
|
<DD>
|
|
<DT><CODE>ifeq "<VAR>arg1</VAR>" '<VAR>arg2</VAR>'</CODE>
|
|
<DD>
|
|
<DT><CODE>ifeq '<VAR>arg1</VAR>' "<VAR>arg2</VAR>"</CODE>
|
|
<DD>
|
|
Expand all variable references in <VAR>arg1</VAR> and <VAR>arg2</VAR> and
|
|
compare them. If they are identical, the <VAR>text-if-true</VAR> is
|
|
effective; otherwise, the <VAR>text-if-false</VAR>, if any, is effective.
|
|
|
|
Often you want to test if a variable has a non-empty value. When the
|
|
value results from complex expansions of variables and functions,
|
|
expansions you would consider empty may actually contain whitespace
|
|
characters and thus are not seen as empty. However, you can use the
|
|
<CODE>strip</CODE> function (see section <A HREF="make.html#SEC77">Functions for String Substitution and Analysis</A>) to avoid interpreting
|
|
whitespace as a non-empty value. For example:
|
|
|
|
|
|
<PRE>
|
|
ifeq ($(strip $(foo)),)
|
|
<VAR>text-if-empty</VAR>
|
|
endif
|
|
</PRE>
|
|
|
|
will evaluate <VAR>text-if-empty</VAR> even if the expansion of
|
|
<CODE>$(foo)</CODE> contains whitespace characters.
|
|
|
|
<DT><CODE>ifneq (<VAR>arg1</VAR>, <VAR>arg2</VAR>)</CODE>
|
|
<DD>
|
|
<DT><CODE>ifneq '<VAR>arg1</VAR>' '<VAR>arg2</VAR>'</CODE>
|
|
<DD>
|
|
<DT><CODE>ifneq "<VAR>arg1</VAR>" "<VAR>arg2</VAR>"</CODE>
|
|
<DD>
|
|
<DT><CODE>ifneq "<VAR>arg1</VAR>" '<VAR>arg2</VAR>'</CODE>
|
|
<DD>
|
|
<DT><CODE>ifneq '<VAR>arg1</VAR>' "<VAR>arg2</VAR>"</CODE>
|
|
<DD>
|
|
Expand all variable references in <VAR>arg1</VAR> and <VAR>arg2</VAR> and
|
|
compare them. If they are different, the <VAR>text-if-true</VAR> is
|
|
effective; otherwise, the <VAR>text-if-false</VAR>, if any, is effective.
|
|
|
|
<DT><CODE>ifdef <VAR>variable-name</VAR></CODE>
|
|
<DD>
|
|
If the variable <VAR>variable-name</VAR> has a non-empty value, the
|
|
<VAR>text-if-true</VAR> is effective; otherwise, the <VAR>text-if-false</VAR>,
|
|
if any, is effective. Variables that have never been defined have an
|
|
empty value.
|
|
|
|
Note that <CODE>ifdef</CODE> only tests whether a variable has a value. It
|
|
does not expand the variable to see if that value is nonempty.
|
|
Consequently, tests using <CODE>ifdef</CODE> return true for all definitions
|
|
except those like <CODE>foo =</CODE>. To test for an empty value, use
|
|
<CODE>ifeq ($(foo),)</CODE>. For example,
|
|
|
|
|
|
<PRE>
|
|
bar =
|
|
foo = $(bar)
|
|
ifdef foo
|
|
frobozz = yes
|
|
else
|
|
frobozz = no
|
|
endif
|
|
</PRE>
|
|
|
|
sets <SAMP>`frobozz'</SAMP> to <SAMP>`yes'</SAMP>, while:
|
|
|
|
|
|
<PRE>
|
|
foo =
|
|
ifdef foo
|
|
frobozz = yes
|
|
else
|
|
frobozz = no
|
|
endif
|
|
</PRE>
|
|
|
|
sets <SAMP>`frobozz'</SAMP> to <SAMP>`no'</SAMP>.
|
|
|
|
<DT><CODE>ifndef <VAR>variable-name</VAR></CODE>
|
|
<DD>
|
|
If the variable <VAR>variable-name</VAR> has an empty value, the
|
|
<VAR>text-if-true</VAR> is effective; otherwise, the <VAR>text-if-false</VAR>,
|
|
if any, is effective.
|
|
</DL>
|
|
|
|
<P>
|
|
Extra spaces are allowed and ignored at the beginning of the conditional
|
|
directive line, but a tab is not allowed. (If the line begins with a tab,
|
|
it will be considered a command for a rule.) Aside from this, extra spaces
|
|
or tabs may be inserted with no effect anywhere except within the directive
|
|
name or within an argument. A comment starting with <SAMP>`#'</SAMP> may appear at
|
|
the end of the line.
|
|
|
|
</P>
|
|
<P>
|
|
The other two directives that play a part in a conditional are <CODE>else</CODE>
|
|
and <CODE>endif</CODE>. Each of these directives is written as one word, with no
|
|
arguments. Extra spaces are allowed and ignored at the beginning of the
|
|
line, and spaces or tabs at the end. A comment starting with <SAMP>`#'</SAMP> may
|
|
appear at the end of the line.
|
|
|
|
</P>
|
|
<P>
|
|
Conditionals affect which lines of the makefile <CODE>make</CODE> uses. If
|
|
the condition is true, <CODE>make</CODE> reads the lines of the
|
|
<VAR>text-if-true</VAR> as part of the makefile; if the condition is false,
|
|
<CODE>make</CODE> ignores those lines completely. It follows that syntactic
|
|
units of the makefile, such as rules, may safely be split across the
|
|
beginning or the end of the conditional.
|
|
</P>
|
|
<P>
|
|
<CODE>make</CODE> evaluates conditionals when it reads a makefile.
|
|
Consequently, you cannot use automatic variables in the tests of
|
|
conditionals because they are not defined until commands are run
|
|
(see section <A HREF="make.html#SEC101">Automatic Variables</A>).
|
|
|
|
</P>
|
|
<P>
|
|
To prevent intolerable confusion, it is not permitted to start a
|
|
conditional in one makefile and end it in another. However, you may
|
|
write an <CODE>include</CODE> directive within a conditional, provided you do
|
|
not attempt to terminate the conditional inside the included file.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC74" HREF="make.html#TOC74">Conditionals that Test Flags</A></H2>
|
|
|
|
<P>
|
|
You can write a conditional that tests <CODE>make</CODE> command flags such as
|
|
<SAMP>`-t'</SAMP> by using the variable <CODE>MAKEFLAGS</CODE> together with the
|
|
<CODE>findstring</CODE> function
|
|
(see section <A HREF="make.html#SEC77">Functions for String Substitution and Analysis</A>).
|
|
This is useful when <CODE>touch</CODE> is not enough to make a file appear up
|
|
to date.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>findstring</CODE> function determines whether one string appears as a
|
|
substring of another. If you want to test for the <SAMP>`-t'</SAMP> flag,
|
|
use <SAMP>`t'</SAMP> as the first string and the value of <CODE>MAKEFLAGS</CODE> as
|
|
the other.
|
|
|
|
</P>
|
|
<P>
|
|
For example, here is how to arrange to use <SAMP>`ranlib -t'</SAMP> to finish
|
|
marking an archive file up to date:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
archive.a: ...
|
|
ifneq (,$(findstring t,$(MAKEFLAGS)))
|
|
+touch archive.a
|
|
+ranlib -t archive.a
|
|
else
|
|
ranlib archive.a
|
|
endif
|
|
</PRE>
|
|
|
|
<P>
|
|
The <SAMP>`+'</SAMP> prefix marks those command lines as "recursive" so
|
|
that they will be executed despite use of the <SAMP>`-t'</SAMP> flag.
|
|
See section <A HREF="make.html#SEC50">Recursive Use of <CODE>make</CODE></A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC75" HREF="make.html#TOC75">Functions for Transforming Text</A></H1>
|
|
<P>
|
|
<A NAME="IDX488"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<STRONG>Functions</STRONG> allow you to do text processing in the makefile to compute
|
|
the files to operate on or the commands to use. You use a function in a
|
|
<STRONG>function call</STRONG>, where you give the name of the function and some text
|
|
(the <STRONG>arguments</STRONG>) for the function to operate on. The result of the
|
|
function's processing is substituted into the makefile at the point of the
|
|
call, just as a variable might be substituted.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC76" HREF="make.html#TOC76">Function Call Syntax</A></H2>
|
|
<P>
|
|
<A NAME="IDX489"></A>
|
|
<A NAME="IDX490"></A>
|
|
<A NAME="IDX491"></A>
|
|
<A NAME="IDX492"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A function call resembles a variable reference. It looks like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$(<VAR>function</VAR> <VAR>arguments</VAR>)
|
|
</PRE>
|
|
|
|
<P>
|
|
or like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
${<VAR>function</VAR> <VAR>arguments</VAR>}
|
|
</PRE>
|
|
|
|
<P>
|
|
Here <VAR>function</VAR> is a function name; one of a short list of names
|
|
that are part of <CODE>make</CODE>. You can also essentially create your own
|
|
functions by using the <CODE>call</CODE> builtin function.
|
|
|
|
</P>
|
|
<P>
|
|
The <VAR>arguments</VAR> are the arguments of the function. They are
|
|
separated from the function name by one or more spaces or tabs, and if
|
|
there is more than one argument, then they are separated by commas.
|
|
Such whitespace and commas are not part of an argument's value. The
|
|
delimiters which you use to surround the function call, whether
|
|
parentheses or braces, can appear in an argument only in matching pairs;
|
|
the other kind of delimiters may appear singly. If the arguments
|
|
themselves contain other function calls or variable references, it is
|
|
wisest to use the same kind of delimiters for all the references; write
|
|
<SAMP>`$(subst a,b,$(x))'</SAMP>, not <SAMP>`$(subst a,b,${x})'</SAMP>. This
|
|
is because it is clearer, and because only one type of delimiter is
|
|
matched to find the end of the reference.
|
|
|
|
</P>
|
|
<P>
|
|
The text written for each argument is processed by substitution of
|
|
variables and function calls to produce the argument value, which
|
|
is the text on which the function acts. The substitution is done in the
|
|
order in which the arguments appear.
|
|
|
|
</P>
|
|
<P>
|
|
Commas and unmatched parentheses or braces cannot appear in the text of an
|
|
argument as written; leading spaces cannot appear in the text of the first
|
|
argument as written. These characters can be put into the argument value
|
|
by variable substitution. First define variables <CODE>comma</CODE> and
|
|
<CODE>space</CODE> whose values are isolated comma and space characters, then
|
|
substitute these variables where such characters are wanted, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
comma:= ,
|
|
empty:=
|
|
space:= $(empty) $(empty)
|
|
foo:= a b c
|
|
bar:= $(subst $(space),$(comma),$(foo))
|
|
# bar is now `a,b,c'.
|
|
</PRE>
|
|
|
|
<P>
|
|
Here the <CODE>subst</CODE> function replaces each space with a comma, through
|
|
the value of <CODE>foo</CODE>, and substitutes the result.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC77" HREF="make.html#TOC77">Functions for String Substitution and Analysis</A></H2>
|
|
<P>
|
|
<A NAME="IDX493"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Here are some functions that operate on strings:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>$(subst <VAR>from</VAR>,<VAR>to</VAR>,<VAR>text</VAR>)</CODE>
|
|
<DD>
|
|
<A NAME="IDX494"></A>
|
|
Performs a textual replacement on the text <VAR>text</VAR>: each occurrence
|
|
of <VAR>from</VAR> is replaced by <VAR>to</VAR>. The result is substituted for
|
|
the function call. For example,
|
|
|
|
|
|
<PRE>
|
|
$(subst ee,EE,feet on the street)
|
|
</PRE>
|
|
|
|
substitutes the string <SAMP>`fEEt on the strEEt'</SAMP>.
|
|
|
|
<DT><CODE>$(patsubst <VAR>pattern</VAR>,<VAR>replacement</VAR>,<VAR>text</VAR>)</CODE>
|
|
<DD>
|
|
<A NAME="IDX495"></A>
|
|
Finds whitespace-separated words in <VAR>text</VAR> that match
|
|
<VAR>pattern</VAR> and replaces them with <VAR>replacement</VAR>. Here
|
|
<VAR>pattern</VAR> may contain a <SAMP>`%'</SAMP> which acts as a wildcard,
|
|
matching any number of any characters within a word. If
|
|
<VAR>replacement</VAR> also contains a <SAMP>`%'</SAMP>, the <SAMP>`%'</SAMP> is replaced
|
|
by the text that matched the <SAMP>`%'</SAMP> in <VAR>pattern</VAR>.
|
|
<A NAME="IDX496"></A>
|
|
<A NAME="IDX497"></A>
|
|
<A NAME="IDX498"></A>
|
|
<A NAME="IDX499"></A>
|
|
<A NAME="IDX500"></A>
|
|
<SAMP>`%'</SAMP> characters in <CODE>patsubst</CODE> function invocations can be
|
|
quoted with preceding backslashes (<SAMP>`\'</SAMP>). Backslashes that would
|
|
otherwise quote <SAMP>`%'</SAMP> characters can be quoted with more backslashes.
|
|
Backslashes that quote <SAMP>`%'</SAMP> characters or other backslashes are
|
|
removed from the pattern before it is compared file names or has a stem
|
|
substituted into it. Backslashes that are not in danger of quoting
|
|
<SAMP>`%'</SAMP> characters go unmolested. For example, the pattern
|
|
<TT>`the\%weird\\%pattern\\'</TT> has <SAMP>`the%weird\'</SAMP> preceding the
|
|
operative <SAMP>`%'</SAMP> character, and <SAMP>`pattern\\'</SAMP> following it. The
|
|
final two backslashes are left alone because they cannot affect any
|
|
<SAMP>`%'</SAMP> character.
|
|
Whitespace between words is folded into single space characters;
|
|
leading and trailing whitespace is discarded.
|
|
|
|
For example,
|
|
|
|
|
|
<PRE>
|
|
$(patsubst %.c,%.o,x.c.c bar.c)
|
|
</PRE>
|
|
|
|
produces the value <SAMP>`x.c.o bar.o'</SAMP>.
|
|
|
|
Substitution references (see section <A HREF="make.html#SEC61">Substitution References</A>) are a simpler way to get the effect of the <CODE>patsubst</CODE>
|
|
function:
|
|
|
|
|
|
<PRE>
|
|
$(<VAR>var</VAR>:<VAR>pattern</VAR>=<VAR>replacement</VAR>)
|
|
</PRE>
|
|
|
|
is equivalent to
|
|
|
|
|
|
<PRE>
|
|
$(patsubst <VAR>pattern</VAR>,<VAR>replacement</VAR>,$(<VAR>var</VAR>))
|
|
</PRE>
|
|
|
|
The second shorthand simplifies one of the most common uses of
|
|
<CODE>patsubst</CODE>: replacing the suffix at the end of file names.
|
|
|
|
|
|
<PRE>
|
|
$(<VAR>var</VAR>:<VAR>suffix</VAR>=<VAR>replacement</VAR>)
|
|
</PRE>
|
|
|
|
is equivalent to
|
|
|
|
|
|
<PRE>
|
|
$(patsubst %<VAR>suffix</VAR>,%<VAR>replacement</VAR>,$(<VAR>var</VAR>))
|
|
</PRE>
|
|
|
|
For example, you might have a list of object files:
|
|
|
|
|
|
<PRE>
|
|
objects = foo.o bar.o baz.o
|
|
</PRE>
|
|
|
|
To get the list of corresponding source files, you could simply write:
|
|
|
|
|
|
<PRE>
|
|
$(objects:.o=.c)
|
|
</PRE>
|
|
|
|
instead of using the general form:
|
|
|
|
|
|
<PRE>
|
|
$(patsubst %.o,%.c,$(objects))
|
|
</PRE>
|
|
|
|
<DT><CODE>$(strip <VAR>string</VAR>)</CODE>
|
|
<DD>
|
|
<A NAME="IDX501"></A>
|
|
<A NAME="IDX502"></A>
|
|
<A NAME="IDX503"></A>
|
|
<A NAME="IDX504"></A>
|
|
Removes leading and trailing whitespace from <VAR>string</VAR> and replaces
|
|
each internal sequence of one or more whitespace characters with a
|
|
single space. Thus, <SAMP>`$(strip a b c )'</SAMP> results in <SAMP>`a b c'</SAMP>.
|
|
|
|
The function <CODE>strip</CODE> can be very useful when used in conjunction
|
|
with conditionals. When comparing something with the empty string
|
|
<SAMP>`'</SAMP> using <CODE>ifeq</CODE> or <CODE>ifneq</CODE>, you usually want a string of
|
|
just whitespace to match the empty string (see section <A HREF="make.html#SEC71">Conditional Parts of Makefiles</A>).
|
|
|
|
Thus, the following may fail to have the desired results:
|
|
|
|
|
|
<PRE>
|
|
.PHONY: all
|
|
ifneq "$(needs_made)" ""
|
|
all: $(needs_made)
|
|
else
|
|
all:;@echo 'Nothing to make!'
|
|
endif
|
|
</PRE>
|
|
|
|
Replacing the variable reference <SAMP>`$(needs_made)'</SAMP> with the
|
|
function call <SAMP>`$(strip $(needs_made))'</SAMP> in the <CODE>ifneq</CODE>
|
|
directive would make it more robust.
|
|
<DT><CODE>$(findstring <VAR>find</VAR>,<VAR>in</VAR>)</CODE>
|
|
<DD>
|
|
<A NAME="IDX505"></A>
|
|
<A NAME="IDX506"></A>
|
|
<A NAME="IDX507"></A>
|
|
<A NAME="IDX508"></A>
|
|
Searches <VAR>in</VAR> for an occurrence of <VAR>find</VAR>. If it occurs, the
|
|
value is <VAR>find</VAR>; otherwise, the value is empty. You can use this
|
|
function in a conditional to test for the presence of a specific
|
|
substring in a given string. Thus, the two examples,
|
|
|
|
|
|
<PRE>
|
|
$(findstring a,a b c)
|
|
$(findstring a,b c)
|
|
</PRE>
|
|
|
|
produce the values <SAMP>`a'</SAMP> and <SAMP>`'</SAMP> (the empty string),
|
|
respectively. See section <A HREF="make.html#SEC74">Conditionals that Test Flags</A>, for a practical application of
|
|
<CODE>findstring</CODE>.
|
|
<A NAME="IDX509"></A>
|
|
<A NAME="IDX510"></A>
|
|
<A NAME="IDX511"></A>
|
|
<DT><CODE>$(filter <VAR>pattern</VAR>...,<VAR>text</VAR>)</CODE>
|
|
<DD>
|
|
Returns all whitespace-separated words in <VAR>text</VAR> that <EM>do</EM> match
|
|
any of the <VAR>pattern</VAR> words, removing any words that <EM>do not</EM>
|
|
match. The patterns are written using <SAMP>`%'</SAMP>, just like the patterns
|
|
used in the <CODE>patsubst</CODE> function above.
|
|
The <CODE>filter</CODE> function can be used to separate out different types
|
|
of strings (such as file names) in a variable. For example:
|
|
|
|
|
|
<PRE>
|
|
sources := foo.c bar.c baz.s ugh.h
|
|
foo: $(sources)
|
|
cc $(filter %.c %.s,$(sources)) -o foo
|
|
</PRE>
|
|
|
|
says that <TT>`foo'</TT> depends of <TT>`foo.c'</TT>, <TT>`bar.c'</TT>,
|
|
<TT>`baz.s'</TT> and <TT>`ugh.h'</TT> but only <TT>`foo.c'</TT>, <TT>`bar.c'</TT> and
|
|
<TT>`baz.s'</TT> should be specified in the command to the
|
|
compiler.
|
|
<DT><CODE>$(filter-out <VAR>pattern</VAR>...,<VAR>text</VAR>)</CODE>
|
|
<DD>
|
|
<A NAME="IDX512"></A>
|
|
<A NAME="IDX513"></A>
|
|
<A NAME="IDX514"></A>
|
|
Returns all whitespace-separated words in <VAR>text</VAR> that <EM>do not</EM>
|
|
match any of the <VAR>pattern</VAR> words, removing the words that <EM>do</EM>
|
|
match one or more. This is the exact opposite of the <CODE>filter</CODE>
|
|
function.
|
|
Removes all whitespace-separated words in <VAR>text</VAR> that <EM>do</EM>
|
|
match the <VAR>pattern</VAR> words, returning only the words that <EM>do
|
|
not</EM> match. This is the exact opposite of the <CODE>filter</CODE>
|
|
function.
|
|
For example, given:
|
|
|
|
|
|
<PRE>
|
|
objects=main1.o foo.o main2.o bar.o
|
|
mains=main1.o main2.o
|
|
</PRE>
|
|
|
|
the following generates a list which contains all the object files not
|
|
in <SAMP>`mains'</SAMP>:
|
|
|
|
|
|
<PRE>
|
|
$(filter-out $(mains),$(objects))
|
|
</PRE>
|
|
|
|
<A NAME="IDX515"></A>
|
|
<A NAME="IDX516"></A>
|
|
<DT><CODE>$(sort <VAR>list</VAR>)</CODE>
|
|
<DD>
|
|
Sorts the words of <VAR>list</VAR> in lexical order, removing duplicate
|
|
words. The output is a list of words separated by single spaces.
|
|
Thus,
|
|
|
|
|
|
<PRE>
|
|
$(sort foo bar lose)
|
|
</PRE>
|
|
|
|
returns the value <SAMP>`bar foo lose'</SAMP>.
|
|
|
|
<A NAME="IDX517"></A>
|
|
<A NAME="IDX518"></A>
|
|
<A NAME="IDX519"></A>
|
|
Incidentally, since <CODE>sort</CODE> removes duplicate words, you can use
|
|
it for this purpose even if you don't care about the sort order.
|
|
</DL>
|
|
|
|
<P>
|
|
Here is a realistic example of the use of <CODE>subst</CODE> and
|
|
<CODE>patsubst</CODE>. Suppose that a makefile uses the <CODE>VPATH</CODE> variable
|
|
to specify a list of directories that <CODE>make</CODE> should search for
|
|
prerequisite files
|
|
(see section <A HREF="make.html#SEC27"><CODE>VPATH</CODE>: Search Path for All Prerequisites</A>).
|
|
This example shows how to
|
|
tell the C compiler to search for header files in the same list of
|
|
directories.
|
|
</P>
|
|
<P>
|
|
The value of <CODE>VPATH</CODE> is a list of directories separated by colons,
|
|
such as <SAMP>`src:../headers'</SAMP>. First, the <CODE>subst</CODE> function is used to
|
|
change the colons to spaces:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$(subst :, ,$(VPATH))
|
|
</PRE>
|
|
|
|
<P>
|
|
This produces <SAMP>`src ../headers'</SAMP>. Then <CODE>patsubst</CODE> is used to turn
|
|
each directory name into a <SAMP>`-I'</SAMP> flag. These can be added to the
|
|
value of the variable <CODE>CFLAGS</CODE>, which is passed automatically to the C
|
|
compiler, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
override CFLAGS += $(patsubst %,-I%,$(subst :, ,$(VPATH)))
|
|
</PRE>
|
|
|
|
<P>
|
|
The effect is to append the text <SAMP>`-Isrc -I../headers'</SAMP> to the
|
|
previously given value of <CODE>CFLAGS</CODE>. The <CODE>override</CODE> directive is
|
|
used so that the new value is assigned even if the previous value of
|
|
<CODE>CFLAGS</CODE> was specified with a command argument (see section <A HREF="make.html#SEC66">The <CODE>override</CODE> Directive</A>).
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC78" HREF="make.html#TOC78">Functions for File Names</A></H2>
|
|
<P>
|
|
<A NAME="IDX520"></A>
|
|
<A NAME="IDX521"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Several of the built-in expansion functions relate specifically to
|
|
taking apart file names or lists of file names.
|
|
|
|
</P>
|
|
<P>
|
|
Each of the following functions performs a specific transformation on a
|
|
file name. The argument of the function is regarded as a series of file
|
|
names, separated by whitespace. (Leading and trailing whitespace is
|
|
ignored.) Each file name in the series is transformed in the same way and
|
|
the results are concatenated with single spaces between them.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>$(dir <VAR>names</VAR>...)</CODE>
|
|
<DD>
|
|
<A NAME="IDX522"></A>
|
|
<A NAME="IDX523"></A>
|
|
<A NAME="IDX524"></A>
|
|
Extracts the directory-part of each file name in <VAR>names</VAR>. The
|
|
directory-part of the file name is everything up through (and
|
|
including) the last slash in it. If the file name contains no slash,
|
|
the directory part is the string <SAMP>`./'</SAMP>. For example,
|
|
|
|
|
|
<PRE>
|
|
$(dir src/foo.c hacks)
|
|
</PRE>
|
|
|
|
produces the result <SAMP>`src/ ./'</SAMP>.
|
|
|
|
<DT><CODE>$(notdir <VAR>names</VAR>...)</CODE>
|
|
<DD>
|
|
<A NAME="IDX525"></A>
|
|
<A NAME="IDX526"></A>
|
|
<A NAME="IDX527"></A>
|
|
Extracts all but the directory-part of each file name in <VAR>names</VAR>.
|
|
If the file name contains no slash, it is left unchanged. Otherwise,
|
|
everything through the last slash is removed from it.
|
|
|
|
A file name that ends with a slash becomes an empty string. This is
|
|
unfortunate, because it means that the result does not always have the
|
|
same number of whitespace-separated file names as the argument had;
|
|
but we do not see any other valid alternative.
|
|
|
|
For example,
|
|
|
|
|
|
<PRE>
|
|
$(notdir src/foo.c hacks)
|
|
</PRE>
|
|
|
|
produces the result <SAMP>`foo.c hacks'</SAMP>.
|
|
|
|
<DT><CODE>$(suffix <VAR>names</VAR>...)</CODE>
|
|
<DD>
|
|
<A NAME="IDX528"></A>
|
|
<A NAME="IDX529"></A>
|
|
<A NAME="IDX530"></A>
|
|
Extracts the suffix of each file name in <VAR>names</VAR>. If the file name
|
|
contains a period, the suffix is everything starting with the last
|
|
period. Otherwise, the suffix is the empty string. This frequently
|
|
means that the result will be empty when <VAR>names</VAR> is not, and if
|
|
<VAR>names</VAR> contains multiple file names, the result may contain fewer
|
|
file names.
|
|
|
|
For example,
|
|
|
|
|
|
<PRE>
|
|
$(suffix src/foo.c src-1.0/bar.c hacks)
|
|
</PRE>
|
|
|
|
produces the result <SAMP>`.c .c'</SAMP>.
|
|
|
|
<DT><CODE>$(basename <VAR>names</VAR>...)</CODE>
|
|
<DD>
|
|
<A NAME="IDX531"></A>
|
|
<A NAME="IDX532"></A>
|
|
<A NAME="IDX533"></A>
|
|
Extracts all but the suffix of each file name in <VAR>names</VAR>. If the
|
|
file name contains a period, the basename is everything starting up to
|
|
(and not including) the last period. Periods in the directory part are
|
|
ignored. If there is no period, the basename is the entire file name.
|
|
For example,
|
|
|
|
|
|
<PRE>
|
|
$(basename src/foo.c src-1.0/bar hacks)
|
|
</PRE>
|
|
|
|
produces the result <SAMP>`src/foo src-1.0/bar hacks'</SAMP>.
|
|
|
|
<DT><CODE>$(addsuffix <VAR>suffix</VAR>,<VAR>names</VAR>...)</CODE>
|
|
<DD>
|
|
<A NAME="IDX534"></A>
|
|
<A NAME="IDX535"></A>
|
|
<A NAME="IDX536"></A>
|
|
The argument <VAR>names</VAR> is regarded as a series of names, separated
|
|
by whitespace; <VAR>suffix</VAR> is used as a unit. The value of
|
|
<VAR>suffix</VAR> is appended to the end of each individual name and the
|
|
resulting larger names are concatenated with single spaces between
|
|
them. For example,
|
|
|
|
|
|
<PRE>
|
|
$(addsuffix .c,foo bar)
|
|
</PRE>
|
|
|
|
produces the result <SAMP>`foo.c bar.c'</SAMP>.
|
|
|
|
<DT><CODE>$(addprefix <VAR>prefix</VAR>,<VAR>names</VAR>...)</CODE>
|
|
<DD>
|
|
<A NAME="IDX537"></A>
|
|
<A NAME="IDX538"></A>
|
|
<A NAME="IDX539"></A>
|
|
The argument <VAR>names</VAR> is regarded as a series of names, separated
|
|
by whitespace; <VAR>prefix</VAR> is used as a unit. The value of
|
|
<VAR>prefix</VAR> is prepended to the front of each individual name and the
|
|
resulting larger names are concatenated with single spaces between
|
|
them. For example,
|
|
|
|
|
|
<PRE>
|
|
$(addprefix src/,foo bar)
|
|
</PRE>
|
|
|
|
produces the result <SAMP>`src/foo src/bar'</SAMP>.
|
|
|
|
<DT><CODE>$(join <VAR>list1</VAR>,<VAR>list2</VAR>)</CODE>
|
|
<DD>
|
|
<A NAME="IDX540"></A>
|
|
<A NAME="IDX541"></A>
|
|
<A NAME="IDX542"></A>
|
|
Concatenates the two arguments word by word: the two first words (one
|
|
from each argument) concatenated form the first word of the result, the
|
|
two second words form the second word of the result, and so on. So the
|
|
<VAR>n</VAR>th word of the result comes from the <VAR>n</VAR>th word of each
|
|
argument. If one argument has more words that the other, the extra
|
|
words are copied unchanged into the result.
|
|
|
|
For example, <SAMP>`$(join a b,.c .o)'</SAMP> produces <SAMP>`a.c b.o'</SAMP>.
|
|
|
|
Whitespace between the words in the lists is not preserved; it is
|
|
replaced with a single space.
|
|
|
|
This function can merge the results of the <CODE>dir</CODE> and
|
|
<CODE>notdir</CODE> functions, to produce the original list of files which
|
|
was given to those two functions.
|
|
<DT><CODE>$(word <VAR>n</VAR>,<VAR>text</VAR>)</CODE>
|
|
<DD>
|
|
<A NAME="IDX543"></A>
|
|
<A NAME="IDX544"></A>
|
|
<A NAME="IDX545"></A>
|
|
Returns the <VAR>n</VAR>th word of <VAR>text</VAR>. The legitimate values of
|
|
<VAR>n</VAR> start from 1. If <VAR>n</VAR> is bigger than the number of words
|
|
in <VAR>text</VAR>, the value is empty. For example,
|
|
|
|
|
|
<PRE>
|
|
$(word 2, foo bar baz)
|
|
</PRE>
|
|
|
|
returns <SAMP>`bar'</SAMP>.
|
|
|
|
<DT><CODE>$(wordlist <VAR>s</VAR>,<VAR>e</VAR>,<VAR>text</VAR>)</CODE>
|
|
<DD>
|
|
<A NAME="IDX546"></A>
|
|
<A NAME="IDX547"></A>
|
|
<A NAME="IDX548"></A>
|
|
Returns the list of words in <VAR>text</VAR> starting with word <VAR>s</VAR> and
|
|
ending with word <VAR>e</VAR> (inclusive). The legitimate values of <VAR>s</VAR>
|
|
and <VAR>e</VAR> start from 1. If <VAR>s</VAR> is bigger than the number of words
|
|
in <VAR>text</VAR>, the value is empty. If <VAR>e</VAR> is bigger than the number
|
|
of words in <VAR>text</VAR>, words up to the end of <VAR>text</VAR> are returned.
|
|
If <VAR>s</VAR> is greater than <VAR>e</VAR>, nothing is returned. For example,
|
|
|
|
|
|
<PRE>
|
|
$(wordlist 2, 3, foo bar baz)
|
|
</PRE>
|
|
|
|
returns <SAMP>`bar baz'</SAMP>.
|
|
|
|
<DT><CODE>$(words <VAR>text</VAR>)</CODE>
|
|
<DD>
|
|
<A NAME="IDX549"></A>
|
|
<A NAME="IDX550"></A>
|
|
Returns the number of words in <VAR>text</VAR>.
|
|
Thus, the last word of <VAR>text</VAR> is
|
|
<CODE>$(word $(words <VAR>text</VAR>),<VAR>text</VAR>)</CODE>.
|
|
<DT><CODE>$(firstword <VAR>names</VAR>...)</CODE>
|
|
<DD>
|
|
<A NAME="IDX551"></A>
|
|
<A NAME="IDX552"></A>
|
|
The argument <VAR>names</VAR> is regarded as a series of names, separated
|
|
by whitespace. The value is the first name in the series. The rest
|
|
of the names are ignored.
|
|
|
|
For example,
|
|
|
|
|
|
<PRE>
|
|
$(firstword foo bar)
|
|
</PRE>
|
|
|
|
produces the result <SAMP>`foo'</SAMP>. Although <CODE>$(firstword
|
|
<VAR>text</VAR>)</CODE> is the same as <CODE>$(word 1,<VAR>text</VAR>)</CODE>, the
|
|
<CODE>firstword</CODE> function is retained for its simplicity.
|
|
<DT><CODE>$(wildcard <VAR>pattern</VAR>)</CODE>
|
|
<DD>
|
|
<A NAME="IDX553"></A>
|
|
<A NAME="IDX554"></A>
|
|
The argument <VAR>pattern</VAR> is a file name pattern, typically containing
|
|
wildcard characters (as in shell file name patterns). The result of
|
|
<CODE>wildcard</CODE> is a space-separated list of the names of existing files
|
|
that match the pattern.
|
|
See section <A HREF="make.html#SEC22">Using Wildcard Characters in File Names</A>.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC79" HREF="make.html#TOC79">The <CODE>foreach</CODE> Function</A></H2>
|
|
<P>
|
|
<A NAME="IDX555"></A>
|
|
<A NAME="IDX556"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>foreach</CODE> function is very different from other functions. It
|
|
causes one piece of text to be used repeatedly, each time with a different
|
|
substitution performed on it. It resembles the <CODE>for</CODE> command in the
|
|
shell <CODE>sh</CODE> and the <CODE>foreach</CODE> command in the C-shell <CODE>csh</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
The syntax of the <CODE>foreach</CODE> function is:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$(foreach <VAR>var</VAR>,<VAR>list</VAR>,<VAR>text</VAR>)
|
|
</PRE>
|
|
|
|
<P>
|
|
The first two arguments, <VAR>var</VAR> and <VAR>list</VAR>, are expanded before
|
|
anything else is done; note that the last argument, <VAR>text</VAR>, is
|
|
<STRONG>not</STRONG> expanded at the same time. Then for each word of the expanded
|
|
value of <VAR>list</VAR>, the variable named by the expanded value of <VAR>var</VAR>
|
|
is set to that word, and <VAR>text</VAR> is expanded. Presumably <VAR>text</VAR>
|
|
contains references to that variable, so its expansion will be different
|
|
each time.
|
|
|
|
</P>
|
|
<P>
|
|
The result is that <VAR>text</VAR> is expanded as many times as there are
|
|
whitespace-separated words in <VAR>list</VAR>. The multiple expansions of
|
|
<VAR>text</VAR> are concatenated, with spaces between them, to make the result
|
|
of <CODE>foreach</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
This simple example sets the variable <SAMP>`files'</SAMP> to the list of all files
|
|
in the directories in the list <SAMP>`dirs'</SAMP>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
dirs := a b c d
|
|
files := $(foreach dir,$(dirs),$(wildcard $(dir)/*))
|
|
</PRE>
|
|
|
|
<P>
|
|
Here <VAR>text</VAR> is <SAMP>`$(wildcard $(dir)/*)'</SAMP>. The first repetition
|
|
finds the value <SAMP>`a'</SAMP> for <CODE>dir</CODE>, so it produces the same result
|
|
as <SAMP>`$(wildcard a/*)'</SAMP>; the second repetition produces the result
|
|
of <SAMP>`$(wildcard b/*)'</SAMP>; and the third, that of <SAMP>`$(wildcard c/*)'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
This example has the same result (except for setting <SAMP>`dirs'</SAMP>) as
|
|
the following example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
files := $(wildcard a/* b/* c/* d/*)
|
|
</PRE>
|
|
|
|
<P>
|
|
When <VAR>text</VAR> is complicated, you can improve readability by giving it
|
|
a name, with an additional variable:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
find_files = $(wildcard $(dir)/*)
|
|
dirs := a b c d
|
|
files := $(foreach dir,$(dirs),$(find_files))
|
|
</PRE>
|
|
|
|
<P>
|
|
Here we use the variable <CODE>find_files</CODE> this way. We use plain <SAMP>`='</SAMP>
|
|
to define a recursively-expanding variable, so that its value contains an
|
|
actual function call to be reexpanded under the control of <CODE>foreach</CODE>;
|
|
a simply-expanded variable would not do, since <CODE>wildcard</CODE> would be
|
|
called only once at the time of defining <CODE>find_files</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>foreach</CODE> function has no permanent effect on the variable
|
|
<VAR>var</VAR>; its value and flavor after the <CODE>foreach</CODE> function call are
|
|
the same as they were beforehand. The other values which are taken from
|
|
<VAR>list</VAR> are in effect only temporarily, during the execution of
|
|
<CODE>foreach</CODE>. The variable <VAR>var</VAR> is a simply-expanded variable
|
|
during the execution of <CODE>foreach</CODE>. If <VAR>var</VAR> was undefined
|
|
before the <CODE>foreach</CODE> function call, it is undefined after the call.
|
|
See section <A HREF="make.html#SEC59">The Two Flavors of Variables</A>.
|
|
</P>
|
|
<P>
|
|
You must take care when using complex variable expressions that result in
|
|
variable names because many strange things are valid variable names, but
|
|
are probably not what you intended. For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
files := $(foreach Esta escrito en espanol!,b c ch,$(find_files))
|
|
</PRE>
|
|
|
|
<P>
|
|
might be useful if the value of <CODE>find_files</CODE> references the variable
|
|
whose name is <SAMP>`Esta escrito en espanol!'</SAMP> (es un nombre bastante largo,
|
|
no?), but it is more likely to be a mistake.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC80" HREF="make.html#TOC80">The <CODE>if</CODE> Function</A></H2>
|
|
<P>
|
|
<A NAME="IDX557"></A>
|
|
<A NAME="IDX558"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>if</CODE> function provides support for conditional expansion in a
|
|
functional context (as opposed to the GNU <CODE>make</CODE> makefile
|
|
conditionals such as <CODE>ifeq</CODE> (see section <A HREF="make.html#SEC73">Syntax of Conditionals</A>).
|
|
|
|
</P>
|
|
<P>
|
|
An <CODE>if</CODE> function call can contain either two or three arguments:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$(if <VAR>condition</VAR>,<VAR>then-part</VAR>[,<VAR>else-part</VAR>])
|
|
</PRE>
|
|
|
|
<P>
|
|
The first argument, <VAR>condition</VAR>, first has all preceding and
|
|
trailing whitespace stripped, then is expanded. If it expands to any
|
|
non-empty string, then the condition is considered to be true. If it
|
|
expands to an empty string, the condition is considered to be false.
|
|
|
|
</P>
|
|
<P>
|
|
If the condition is true then the second argument, <VAR>then-part</VAR>, is
|
|
evaluated and this is used as the result of the evaluation of the entire
|
|
<CODE>if</CODE> function.
|
|
|
|
</P>
|
|
<P>
|
|
If the condition is false then the third argument, <VAR>else-part</VAR>, is
|
|
evaluated and this is the result of the <CODE>if</CODE> function. If there is
|
|
no third argument, the <CODE>if</CODE> function evaluates to nothing (the
|
|
empty string).
|
|
|
|
</P>
|
|
<P>
|
|
Note that only one of the <VAR>then-part</VAR> or the <VAR>else-part</VAR> will be
|
|
evaluated, never both. Thus, either can contain side-effects (such as
|
|
<CODE>shell</CODE> function calls, etc.)
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC81" HREF="make.html#TOC81">The <CODE>call</CODE> Function</A></H2>
|
|
<P>
|
|
<A NAME="IDX559"></A>
|
|
<A NAME="IDX560"></A>
|
|
<A NAME="IDX561"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>call</CODE> function is unique in that it can be used to create new
|
|
parameterized functions. You can write a complex expression as the
|
|
value of a variable, then use <CODE>call</CODE> to expand it with different
|
|
values.
|
|
|
|
</P>
|
|
<P>
|
|
The syntax of the <CODE>call</CODE> function is:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$(call <VAR>variable</VAR>,<VAR>param</VAR>,<VAR>param</VAR>,...)
|
|
</PRE>
|
|
|
|
<P>
|
|
When <CODE>make</CODE> expands this function, it assigns each <VAR>param</VAR> to
|
|
temporary variables <CODE>$(1)</CODE>, <CODE>$(2)</CODE>, etc. The variable
|
|
<CODE>$(0)</CODE> will contain <VAR>variable</VAR>. There is no maximum number of
|
|
parameter arguments. There is no minimum, either, but it doesn't make
|
|
sense to use <CODE>call</CODE> with no parameters.
|
|
|
|
</P>
|
|
<P>
|
|
Then <VAR>variable</VAR> is expanded as a <CODE>make</CODE> variable in the context
|
|
of these temporary assignments. Thus, any reference to <CODE>$(1)</CODE> in
|
|
the value of <VAR>variable</VAR> will resolve to the first <VAR>param</VAR> in the
|
|
invocation of <CODE>call</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
Note that <VAR>variable</VAR> is the <EM>name</EM> of a variable, not a
|
|
<EM>reference</EM> to that variable. Therefore you would not normally use
|
|
a <SAMP>`$'</SAMP> or parentheses when writing it. (You can, however, use a
|
|
variable reference in the name if you want the name not to be a
|
|
constant.)
|
|
|
|
</P>
|
|
<P>
|
|
If <VAR>variable</VAR> is the name of a builtin function, the builtin function
|
|
is always invoked (even if a <CODE>make</CODE> variable by that name also
|
|
exists).
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>call</CODE> function expands the <VAR>param</VAR> arguments before
|
|
assigning them to temporary variables. This means that <VAR>variable</VAR>
|
|
values containing references to builtin functions that have special
|
|
expansion rules, like <CODE>foreach</CODE> or <CODE>if</CODE>, may not work as you
|
|
expect.
|
|
|
|
</P>
|
|
<P>
|
|
Some examples may make this clearer.
|
|
|
|
</P>
|
|
<P>
|
|
This macro simply reverses its arguments:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
reverse = $(2) $(1)
|
|
|
|
foo = $(call reverse,a,b)
|
|
</PRE>
|
|
|
|
<P>
|
|
Here <VAR>foo</VAR> will contain <SAMP>`b a'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
This one is slightly more interesting: it defines a macro to search for
|
|
the first instance of a program in <CODE>PATH</CODE>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
pathsearch = $(firstword $(wildcard $(addsufix /$(1),$(subst :, ,$(PATH)))))
|
|
|
|
LS := $(call pathsearch,ls)
|
|
</PRE>
|
|
|
|
<P>
|
|
Now the variable LS contains <CODE>/bin/ls</CODE> or similar.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>call</CODE> function can be nested. Each recursive invocation gets
|
|
its own local values for <CODE>$(1)</CODE>, etc. that mask the values of
|
|
higher-level <CODE>call</CODE>. For example, here is an implementation of a
|
|
<STRONG>map</STRONG> function:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
map = $(foreach a,$(2),$(call $(1),$(a)))
|
|
</PRE>
|
|
|
|
<P>
|
|
Now you can <VAR>map</VAR> a function that normally takes only one argument,
|
|
such as <CODE>origin</CODE>, to multiple values in one step:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
o = $(call map,origin,o map MAKE)
|
|
</PRE>
|
|
|
|
<P>
|
|
and end up with <VAR>o</VAR> containing something like <SAMP>`file file default'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
A final caution: be careful when adding whitespace to the arguments to
|
|
<CODE>call</CODE>. As with other functions, any whitespace contained in the
|
|
second and subsequent arguments is kept; this can cause strange
|
|
effects. It's generally safest to remove all extraneous whitespace when
|
|
providing parameters to <CODE>call</CODE>.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC82" HREF="make.html#TOC82">The <CODE>origin</CODE> Function</A></H2>
|
|
<P>
|
|
<A NAME="IDX562"></A>
|
|
<A NAME="IDX563"></A>
|
|
<A NAME="IDX564"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>origin</CODE> function is unlike most other functions in that it does
|
|
not operate on the values of variables; it tells you something <EM>about</EM>
|
|
a variable. Specifically, it tells you where it came from.
|
|
|
|
</P>
|
|
<P>
|
|
The syntax of the <CODE>origin</CODE> function is:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$(origin <VAR>variable</VAR>)
|
|
</PRE>
|
|
|
|
<P>
|
|
Note that <VAR>variable</VAR> is the <EM>name</EM> of a variable to inquire about;
|
|
not a <EM>reference</EM> to that variable. Therefore you would not normally
|
|
use a <SAMP>`$'</SAMP> or parentheses when writing it. (You can, however, use a
|
|
variable reference in the name if you want the name not to be a constant.)
|
|
|
|
</P>
|
|
<P>
|
|
The result of this function is a string telling you how the variable
|
|
<VAR>variable</VAR> was defined:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><SAMP>`undefined'</SAMP>
|
|
<DD>
|
|
if <VAR>variable</VAR> was never defined.
|
|
|
|
<DT><SAMP>`default'</SAMP>
|
|
<DD>
|
|
if <VAR>variable</VAR> has a default definition, as is usual with <CODE>CC</CODE>
|
|
and so on. See section <A HREF="make.html#SEC96">Variables Used by Implicit Rules</A>.
|
|
Note that if you have redefined a default variable, the <CODE>origin</CODE>
|
|
function will return the origin of the later definition.
|
|
|
|
<DT><SAMP>`environment'</SAMP>
|
|
<DD>
|
|
if <VAR>variable</VAR> was defined as an environment variable and the
|
|
<SAMP>`-e'</SAMP> option is <EM>not</EM> turned on (see section <A HREF="make.html#SEC92">Summary of Options</A>).
|
|
|
|
<DT><SAMP>`environment override'</SAMP>
|
|
<DD>
|
|
if <VAR>variable</VAR> was defined as an environment variable and the
|
|
<SAMP>`-e'</SAMP> option <EM>is</EM> turned on (see section <A HREF="make.html#SEC92">Summary of Options</A>).
|
|
<DT><SAMP>`file'</SAMP>
|
|
<DD>
|
|
if <VAR>variable</VAR> was defined in a makefile.
|
|
|
|
<DT><SAMP>`command line'</SAMP>
|
|
<DD>
|
|
if <VAR>variable</VAR> was defined on the command line.
|
|
|
|
<DT><SAMP>`override'</SAMP>
|
|
<DD>
|
|
if <VAR>variable</VAR> was defined with an <CODE>override</CODE> directive in a
|
|
makefile (see section <A HREF="make.html#SEC66">The <CODE>override</CODE> Directive</A>).
|
|
|
|
<DT><SAMP>`automatic'</SAMP>
|
|
<DD>
|
|
if <VAR>variable</VAR> is an automatic variable defined for the
|
|
execution of the commands for each rule
|
|
(see section <A HREF="make.html#SEC101">Automatic Variables</A>).
|
|
</DL>
|
|
|
|
<P>
|
|
This information is primarily useful (other than for your curiosity) to
|
|
determine if you want to believe the value of a variable. For example,
|
|
suppose you have a makefile <TT>`foo'</TT> that includes another makefile
|
|
<TT>`bar'</TT>. You want a variable <CODE>bletch</CODE> to be defined in <TT>`bar'</TT>
|
|
if you run the command <SAMP>`make -f bar'</SAMP>, even if the environment contains
|
|
a definition of <CODE>bletch</CODE>. However, if <TT>`foo'</TT> defined
|
|
<CODE>bletch</CODE> before including <TT>`bar'</TT>, you do not want to override that
|
|
definition. This could be done by using an <CODE>override</CODE> directive in
|
|
<TT>`foo'</TT>, giving that definition precedence over the later definition in
|
|
<TT>`bar'</TT>; unfortunately, the <CODE>override</CODE> directive would also
|
|
override any command line definitions. So, <TT>`bar'</TT> could
|
|
include:
|
|
</P>
|
|
|
|
<PRE>
|
|
ifdef bletch
|
|
ifeq "$(origin bletch)" "environment"
|
|
bletch = barf, gag, etc.
|
|
endif
|
|
endif
|
|
</PRE>
|
|
|
|
<P>
|
|
If <CODE>bletch</CODE> has been defined from the environment, this will redefine
|
|
it.
|
|
|
|
</P>
|
|
<P>
|
|
If you want to override a previous definition of <CODE>bletch</CODE> if it came
|
|
from the environment, even under <SAMP>`-e'</SAMP>, you could instead write:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
ifneq "$(findstring environment,$(origin bletch))" ""
|
|
bletch = barf, gag, etc.
|
|
endif
|
|
</PRE>
|
|
|
|
<P>
|
|
Here the redefinition takes place if <SAMP>`$(origin bletch)'</SAMP> returns either
|
|
<SAMP>`environment'</SAMP> or <SAMP>`environment override'</SAMP>.
|
|
See section <A HREF="make.html#SEC77">Functions for String Substitution and Analysis</A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC83" HREF="make.html#TOC83">The <CODE>shell</CODE> Function</A></H2>
|
|
<P>
|
|
<A NAME="IDX565"></A>
|
|
<A NAME="IDX566"></A>
|
|
<A NAME="IDX567"></A>
|
|
<A NAME="IDX568"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>shell</CODE> function is unlike any other function except the
|
|
<CODE>wildcard</CODE> function
|
|
(see section <A HREF="make.html#SEC25">The Function <CODE>wildcard</CODE></A>) in that it
|
|
communicates with the world outside of <CODE>make</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>shell</CODE> function performs the same function that backquotes
|
|
(<SAMP>``'</SAMP>) perform in most shells: it does <STRONG>command expansion</STRONG>. This
|
|
means that it takes an argument that is a shell command and returns the
|
|
output of the command. The only processing <CODE>make</CODE> does on the result,
|
|
before substituting it into the surrounding text, is to convert each
|
|
newline or carriage-return / newline pair to a single space. It also
|
|
removes the trailing (carriage-return and) newline, if it's the last
|
|
thing in the result.
|
|
</P>
|
|
<P>
|
|
The commands run by calls to the <CODE>shell</CODE> function are run when the
|
|
function calls are expanded. In most cases, this is when the makefile is
|
|
read in. The exception is that function calls in the commands of the rules
|
|
are expanded when the commands are run, and this applies to <CODE>shell</CODE>
|
|
function calls like all others.
|
|
|
|
</P>
|
|
<P>
|
|
Here are some examples of the use of the <CODE>shell</CODE> function:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
contents := $(shell cat foo)
|
|
</PRE>
|
|
|
|
<P>
|
|
sets <CODE>contents</CODE> to the contents of the file <TT>`foo'</TT>, with a space
|
|
(rather than a newline) separating each line.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
files := $(shell echo *.c)
|
|
</PRE>
|
|
|
|
<P>
|
|
sets <CODE>files</CODE> to the expansion of <SAMP>`*.c'</SAMP>. Unless <CODE>make</CODE> is
|
|
using a very strange shell, this has the same result as
|
|
<SAMP>`$(wildcard *.c)'</SAMP>.
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC84" HREF="make.html#TOC84">Functions That Control Make</A></H2>
|
|
<P>
|
|
<A NAME="IDX569"></A>
|
|
<A NAME="IDX570"></A>
|
|
|
|
</P>
|
|
<P>
|
|
These functions control the way make runs. Generally, they are used to
|
|
provide information to the user of the makefile or to cause make to stop
|
|
if some sort of environmental error is detected.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>$(error <VAR>text</VAR>...)</CODE>
|
|
<DD>
|
|
<A NAME="IDX571"></A>
|
|
<A NAME="IDX572"></A>
|
|
<A NAME="IDX573"></A>
|
|
Generates a fatal error where the message is <VAR>text</VAR>. Note that the
|
|
error is generated whenever this function is evaluated. So, if you put
|
|
it inside a command script or on the right side of a recursive variable
|
|
assignment, it won't be evaluated until later. The <VAR>text</VAR> will be
|
|
expanded before the error is generated.
|
|
|
|
For example,
|
|
|
|
|
|
<PRE>
|
|
ifdef ERROR1
|
|
$(error error is $(ERROR1))
|
|
endif
|
|
</PRE>
|
|
|
|
will generate a fatal error during the read of the makefile if the
|
|
<CODE>make</CODE> variable <CODE>ERROR1</CODE> is defined. Or,
|
|
|
|
|
|
<PRE>
|
|
ERR = $(error found an error!)
|
|
|
|
.PHONY: err
|
|
err: ; $(ERR)
|
|
</PRE>
|
|
|
|
will generate a fatal error while <CODE>make</CODE> is running, if the
|
|
<CODE>err</CODE> target is invoked.
|
|
|
|
<DT><CODE>$(warning <VAR>text</VAR>...)</CODE>
|
|
<DD>
|
|
<A NAME="IDX574"></A>
|
|
<A NAME="IDX575"></A>
|
|
<A NAME="IDX576"></A>
|
|
This function works similarly to the <CODE>error</CODE> function, above,
|
|
except that <CODE>make</CODE> doesn't exit. Instead, <VAR>text</VAR> is expanded
|
|
and the resulting message is displayed, but processing of the makefile
|
|
continues.
|
|
|
|
The result of the expansion of this function is the empty string.
|
|
</DL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC85" HREF="make.html#TOC85">How to Run <CODE>make</CODE></A></H1>
|
|
|
|
<P>
|
|
A makefile that says how to recompile a program can be used in more
|
|
than one way. The simplest use is to recompile every file that is out
|
|
of date. Usually, makefiles are written so that if you run
|
|
<CODE>make</CODE> with no arguments, it does just that.
|
|
|
|
</P>
|
|
<P>
|
|
But you might want to update only some of the files; you might want to use
|
|
a different compiler or different compiler options; you might want just to
|
|
find out which files are out of date without changing them.
|
|
|
|
</P>
|
|
<P>
|
|
By giving arguments when you run <CODE>make</CODE>, you can do any of these
|
|
things and many others.
|
|
|
|
</P>
|
|
<P>
|
|
The exit status of <CODE>make</CODE> is always one of three values:
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>0</CODE>
|
|
<DD>
|
|
The exit status is zero if <CODE>make</CODE> is successful.
|
|
<DT><CODE>2</CODE>
|
|
<DD>
|
|
The exit status is two if <CODE>make</CODE> encounters any errors.
|
|
It will print messages describing the particular errors.
|
|
<DT><CODE>1</CODE>
|
|
<DD>
|
|
The exit status is one if you use the <SAMP>`-q'</SAMP> flag and <CODE>make</CODE>
|
|
determines that some target is not already up to date.
|
|
See section <A HREF="make.html#SEC88">Instead of Executing the Commands</A>.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC86" HREF="make.html#TOC86">Arguments to Specify the Makefile</A></H2>
|
|
<P>
|
|
<A NAME="IDX577"></A>
|
|
<A NAME="IDX578"></A>
|
|
<A NAME="IDX579"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The way to specify the name of the makefile is with the <SAMP>`-f'</SAMP> or
|
|
<SAMP>`--file'</SAMP> option (<SAMP>`--makefile'</SAMP> also works). For example,
|
|
<SAMP>`-f altmake'</SAMP> says to use the file <TT>`altmake'</TT> as the makefile.
|
|
|
|
</P>
|
|
<P>
|
|
If you use the <SAMP>`-f'</SAMP> flag several times and follow each <SAMP>`-f'</SAMP>
|
|
with an argument, all the specified files are used jointly as
|
|
makefiles.
|
|
|
|
</P>
|
|
<P>
|
|
If you do not use the <SAMP>`-f'</SAMP> or <SAMP>`--file'</SAMP> flag, the default is
|
|
to try <TT>`GNUmakefile'</TT>, <TT>`makefile'</TT>, and <TT>`Makefile'</TT>, in
|
|
that order, and use the first of these three which exists or can be made
|
|
(see section <A HREF="make.html#SEC12">Writing Makefiles</A>).
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC87" HREF="make.html#TOC87">Arguments to Specify the Goals</A></H2>
|
|
<P>
|
|
<A NAME="IDX580"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The <STRONG>goals</STRONG> are the targets that <CODE>make</CODE> should strive ultimately
|
|
to update. Other targets are updated as well if they appear as
|
|
prerequisites of goals, or prerequisites of prerequisites of goals, etc.
|
|
|
|
</P>
|
|
<P>
|
|
By default, the goal is the first target in the makefile (not counting
|
|
targets that start with a period). Therefore, makefiles are usually
|
|
written so that the first target is for compiling the entire program or
|
|
programs they describe. If the first rule in the makefile has several
|
|
targets, only the first target in the rule becomes the default goal, not
|
|
the whole list.
|
|
|
|
</P>
|
|
<P>
|
|
You can specify a different goal or goals with arguments to <CODE>make</CODE>.
|
|
Use the name of the goal as an argument. If you specify several goals,
|
|
<CODE>make</CODE> processes each of them in turn, in the order you name them.
|
|
|
|
</P>
|
|
<P>
|
|
Any target in the makefile may be specified as a goal (unless it
|
|
starts with <SAMP>`-'</SAMP> or contains an <SAMP>`='</SAMP>, in which case it will be
|
|
parsed as a switch or variable definition, respectively). Even
|
|
targets not in the makefile may be specified, if <CODE>make</CODE> can find
|
|
implicit rules that say how to make them.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX581"></A>
|
|
<A NAME="IDX582"></A>
|
|
<CODE>Make</CODE> will set the special variable <CODE>MAKECMDGOALS</CODE> to the
|
|
list of goals you specified on the command line. If no goals were given
|
|
on the command line, this variable is empty. Note that this variable
|
|
should be used only in special circumstances.
|
|
|
|
</P>
|
|
<P>
|
|
An example of appropriate use is to avoid including <TT>`.d'</TT> files
|
|
during <CODE>clean</CODE> rules (see section <A HREF="make.html#SEC43">Generating Prerequisites Automatically</A>), so
|
|
<CODE>make</CODE> won't create them only to immediately remove them
|
|
again:
|
|
</P>
|
|
|
|
<PRE>
|
|
sources = foo.c bar.c
|
|
|
|
ifneq ($(MAKECMDGOALS),clean)
|
|
include $(sources:.c=.d)
|
|
endif
|
|
</PRE>
|
|
|
|
<P>
|
|
One use of specifying a goal is if you want to compile only a part of
|
|
the program, or only one of several programs. Specify as a goal each
|
|
file that you wish to remake. For example, consider a directory containing
|
|
several programs, with a makefile that starts like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
.PHONY: all
|
|
all: size nm ld ar as
|
|
</PRE>
|
|
|
|
<P>
|
|
If you are working on the program <CODE>size</CODE>, you might want to say
|
|
<SAMP>`make size'</SAMP> so that only the files of that program are recompiled.
|
|
|
|
</P>
|
|
<P>
|
|
Another use of specifying a goal is to make files that are not normally
|
|
made. For example, there may be a file of debugging output, or a
|
|
version of the program that is compiled specially for testing, which has
|
|
a rule in the makefile but is not a prerequisite of the default goal.
|
|
|
|
</P>
|
|
<P>
|
|
Another use of specifying a goal is to run the commands associated with
|
|
a phony target (see section <A HREF="make.html#SEC33">Phony Targets</A>) or empty target (see section <A HREF="make.html#SEC35">Empty Target Files to Record Events</A>). Many makefiles contain
|
|
a phony target named <TT>`clean'</TT> which deletes everything except source
|
|
files. Naturally, this is done only if you request it explicitly with
|
|
<SAMP>`make clean'</SAMP>. Following is a list of typical phony and empty
|
|
target names. See section <A HREF="make.html#SEC121">Standard Targets for Users</A>, for a detailed list of all the
|
|
standard target names which GNU software packages use.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><TT>`all'</TT>
|
|
<DD>
|
|
<A NAME="IDX583"></A>
|
|
Make all the top-level targets the makefile knows about.
|
|
|
|
<DT><TT>`clean'</TT>
|
|
<DD>
|
|
<A NAME="IDX584"></A>
|
|
Delete all files that are normally created by running <CODE>make</CODE>.
|
|
|
|
<DT><TT>`mostlyclean'</TT>
|
|
<DD>
|
|
<A NAME="IDX585"></A>
|
|
Like <SAMP>`clean'</SAMP>, but may refrain from deleting a few files that people
|
|
normally don't want to recompile. For example, the <SAMP>`mostlyclean'</SAMP>
|
|
target for GCC does not delete <TT>`libgcc.a'</TT>, because recompiling it
|
|
is rarely necessary and takes a lot of time.
|
|
|
|
<DT><TT>`distclean'</TT>
|
|
<DD>
|
|
<A NAME="IDX586"></A>
|
|
<DT><TT>`realclean'</TT>
|
|
<DD>
|
|
<A NAME="IDX587"></A>
|
|
<DT><TT>`clobber'</TT>
|
|
<DD>
|
|
<A NAME="IDX588"></A>
|
|
Any of these targets might be defined to delete <EM>more</EM> files than
|
|
<SAMP>`clean'</SAMP> does. For example, this would delete configuration files
|
|
or links that you would normally create as preparation for compilation,
|
|
even if the makefile itself cannot create these files.
|
|
|
|
<DT><TT>`install'</TT>
|
|
<DD>
|
|
<A NAME="IDX589"></A>
|
|
Copy the executable file into a directory that users typically search
|
|
for commands; copy any auxiliary files that the executable uses into
|
|
the directories where it will look for them.
|
|
|
|
<DT><TT>`print'</TT>
|
|
<DD>
|
|
<A NAME="IDX590"></A>
|
|
Print listings of the source files that have changed.
|
|
|
|
<DT><TT>`tar'</TT>
|
|
<DD>
|
|
<A NAME="IDX591"></A>
|
|
Create a tar file of the source files.
|
|
|
|
<DT><TT>`shar'</TT>
|
|
<DD>
|
|
<A NAME="IDX592"></A>
|
|
Create a shell archive (shar file) of the source files.
|
|
|
|
<DT><TT>`dist'</TT>
|
|
<DD>
|
|
<A NAME="IDX593"></A>
|
|
Create a distribution file of the source files. This might
|
|
be a tar file, or a shar file, or a compressed version of one of the
|
|
above, or even more than one of the above.
|
|
|
|
<DT><TT>`TAGS'</TT>
|
|
<DD>
|
|
<A NAME="IDX594"></A>
|
|
Update a tags table for this program.
|
|
|
|
<DT><TT>`check'</TT>
|
|
<DD>
|
|
<A NAME="IDX595"></A>
|
|
<DT><TT>`test'</TT>
|
|
<DD>
|
|
<A NAME="IDX596"></A>
|
|
Perform self tests on the program this makefile builds.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC88" HREF="make.html#TOC88">Instead of Executing the Commands</A></H2>
|
|
<P>
|
|
<A NAME="IDX597"></A>
|
|
<A NAME="IDX598"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The makefile tells <CODE>make</CODE> how to tell whether a target is up to date,
|
|
and how to update each target. But updating the targets is not always
|
|
what you want. Certain options specify other activities for <CODE>make</CODE>.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><SAMP>`-n'</SAMP>
|
|
<DD>
|
|
<DT><SAMP>`--just-print'</SAMP>
|
|
<DD>
|
|
<DT><SAMP>`--dry-run'</SAMP>
|
|
<DD>
|
|
<DT><SAMP>`--recon'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX599"></A>
|
|
<A NAME="IDX600"></A>
|
|
<A NAME="IDX601"></A>
|
|
<A NAME="IDX602"></A>
|
|
|
|
"No-op". The activity is to print what commands would be used to make
|
|
the targets up to date, but not actually execute them.
|
|
|
|
<DT><SAMP>`-t'</SAMP>
|
|
<DD>
|
|
<DT><SAMP>`--touch'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX603"></A>
|
|
<A NAME="IDX604"></A>
|
|
<A NAME="IDX605"></A>
|
|
<A NAME="IDX606"></A>
|
|
|
|
"Touch". The activity is to mark the targets as up to date without
|
|
actually changing them. In other words, <CODE>make</CODE> pretends to compile
|
|
the targets but does not really change their contents.
|
|
|
|
<DT><SAMP>`-q'</SAMP>
|
|
<DD>
|
|
<DT><SAMP>`--question'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX607"></A>
|
|
<A NAME="IDX608"></A>
|
|
<A NAME="IDX609"></A>
|
|
|
|
"Question". The activity is to find out silently whether the targets
|
|
are up to date already; but execute no commands in either case. In other
|
|
words, neither compilation nor output will occur.
|
|
|
|
<DT><SAMP>`-W <VAR>file</VAR>'</SAMP>
|
|
<DD>
|
|
<DT><SAMP>`--what-if=<VAR>file</VAR>'</SAMP>
|
|
<DD>
|
|
<DT><SAMP>`--assume-new=<VAR>file</VAR>'</SAMP>
|
|
<DD>
|
|
<DT><SAMP>`--new-file=<VAR>file</VAR>'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX610"></A>
|
|
<A NAME="IDX611"></A>
|
|
<A NAME="IDX612"></A>
|
|
<A NAME="IDX613"></A>
|
|
<A NAME="IDX614"></A>
|
|
<A NAME="IDX615"></A>
|
|
|
|
"What if". Each <SAMP>`-W'</SAMP> flag is followed by a file name. The given
|
|
files' modification times are recorded by <CODE>make</CODE> as being the present
|
|
time, although the actual modification times remain the same.
|
|
You can use the <SAMP>`-W'</SAMP> flag in conjunction with the <SAMP>`-n'</SAMP> flag
|
|
to see what would happen if you were to modify specific files.</DL>
|
|
|
|
<P>
|
|
With the <SAMP>`-n'</SAMP> flag, <CODE>make</CODE> prints the commands that it would
|
|
normally execute but does not execute them.
|
|
|
|
</P>
|
|
<P>
|
|
With the <SAMP>`-t'</SAMP> flag, <CODE>make</CODE> ignores the commands in the rules
|
|
and uses (in effect) the command <CODE>touch</CODE> for each target that needs to
|
|
be remade. The <CODE>touch</CODE> command is also printed, unless <SAMP>`-s'</SAMP> or
|
|
<CODE>.SILENT</CODE> is used. For speed, <CODE>make</CODE> does not actually invoke
|
|
the program <CODE>touch</CODE>. It does the work directly.
|
|
|
|
</P>
|
|
<P>
|
|
With the <SAMP>`-q'</SAMP> flag, <CODE>make</CODE> prints nothing and executes no
|
|
commands, but the exit status code it returns is zero if and only if the
|
|
targets to be considered are already up to date. If the exit status is
|
|
one, then some updating needs to be done. If <CODE>make</CODE> encounters an
|
|
error, the exit status is two, so you can distinguish an error from a
|
|
target that is not up to date.
|
|
|
|
</P>
|
|
<P>
|
|
It is an error to use more than one of these three flags in the same
|
|
invocation of <CODE>make</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
The <SAMP>`-n'</SAMP>, <SAMP>`-t'</SAMP>, and <SAMP>`-q'</SAMP> options do not affect command
|
|
lines that begin with <SAMP>`+'</SAMP> characters or contain the strings
|
|
<SAMP>`$(MAKE)'</SAMP> or <SAMP>`${MAKE}'</SAMP>. Note that only the line containing
|
|
the <SAMP>`+'</SAMP> character or the strings <SAMP>`$(MAKE)'</SAMP> or <SAMP>`${MAKE}'</SAMP>
|
|
is run regardless of these options. Other lines in the same rule are
|
|
not run unless they too begin with <SAMP>`+'</SAMP> or contain <SAMP>`$(MAKE)'</SAMP> or
|
|
<SAMP>`${MAKE}'</SAMP> (See section <A HREF="make.html#SEC51">How the <CODE>MAKE</CODE> Variable Works</A>.)
|
|
|
|
</P>
|
|
<P>
|
|
The <SAMP>`-W'</SAMP> flag provides two features:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
If you also use the <SAMP>`-n'</SAMP> or <SAMP>`-q'</SAMP> flag, you can see what
|
|
<CODE>make</CODE> would do if you were to modify some files.
|
|
|
|
<LI>
|
|
|
|
Without the <SAMP>`-n'</SAMP> or <SAMP>`-q'</SAMP> flag, when <CODE>make</CODE> is actually
|
|
executing commands, the <SAMP>`-W'</SAMP> flag can direct <CODE>make</CODE> to act
|
|
as if some files had been modified, without actually modifying the
|
|
files.</UL>
|
|
|
|
<P>
|
|
Note that the options <SAMP>`-p'</SAMP> and <SAMP>`-v'</SAMP> allow you to obtain other
|
|
information about <CODE>make</CODE> or about the makefiles in use
|
|
(see section <A HREF="make.html#SEC92">Summary of Options</A>).
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC89" HREF="make.html#TOC89">Avoiding Recompilation of Some Files</A></H2>
|
|
<P>
|
|
<A NAME="IDX616"></A>
|
|
<A NAME="IDX617"></A>
|
|
<A NAME="IDX618"></A>
|
|
<A NAME="IDX619"></A>
|
|
<A NAME="IDX620"></A>
|
|
<A NAME="IDX621"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Sometimes you may have changed a source file but you do not want to
|
|
recompile all the files that depend on it. For example, suppose you add
|
|
a macro or a declaration to a header file that many other files depend
|
|
on. Being conservative, <CODE>make</CODE> assumes that any change in the
|
|
header file requires recompilation of all dependent files, but you know
|
|
that they do not need to be recompiled and you would rather not waste
|
|
the time waiting for them to compile.
|
|
|
|
</P>
|
|
<P>
|
|
If you anticipate the problem before changing the header file, you can
|
|
use the <SAMP>`-t'</SAMP> flag. This flag tells <CODE>make</CODE> not to run the
|
|
commands in the rules, but rather to mark the target up to date by
|
|
changing its last-modification date. You would follow this procedure:
|
|
|
|
</P>
|
|
|
|
<OL>
|
|
<LI>
|
|
|
|
Use the command <SAMP>`make'</SAMP> to recompile the source files that really
|
|
need recompilation.
|
|
|
|
<LI>
|
|
|
|
Make the changes in the header files.
|
|
|
|
<LI>
|
|
|
|
Use the command <SAMP>`make -t'</SAMP> to mark all the object files as
|
|
up to date. The next time you run <CODE>make</CODE>, the changes in the
|
|
header files will not cause any recompilation.
|
|
</OL>
|
|
|
|
<P>
|
|
If you have already changed the header file at a time when some files
|
|
do need recompilation, it is too late to do this. Instead, you can
|
|
use the <SAMP>`-o <VAR>file</VAR>'</SAMP> flag, which marks a specified file as
|
|
"old" (see section <A HREF="make.html#SEC92">Summary of Options</A>). This means
|
|
that the file itself will not be remade, and nothing else will be
|
|
remade on its account. Follow this procedure:
|
|
|
|
</P>
|
|
|
|
<OL>
|
|
<LI>
|
|
|
|
Recompile the source files that need compilation for reasons independent
|
|
of the particular header file, with <SAMP>`make -o <VAR>headerfile</VAR>'</SAMP>.
|
|
If several header files are involved, use a separate <SAMP>`-o'</SAMP> option
|
|
for each header file.
|
|
|
|
<LI>
|
|
|
|
Touch all the object files with <SAMP>`make -t'</SAMP>.
|
|
</OL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC90" HREF="make.html#TOC90">Overriding Variables</A></H2>
|
|
<P>
|
|
<A NAME="IDX622"></A>
|
|
<A NAME="IDX623"></A>
|
|
<A NAME="IDX624"></A>
|
|
<A NAME="IDX625"></A>
|
|
|
|
</P>
|
|
<P>
|
|
An argument that contains <SAMP>`='</SAMP> specifies the value of a variable:
|
|
<SAMP>`<VAR>v</VAR>=<VAR>x</VAR>'</SAMP> sets the value of the variable <VAR>v</VAR> to <VAR>x</VAR>.
|
|
If you specify a value in this way, all ordinary assignments of the same
|
|
variable in the makefile are ignored; we say they have been
|
|
<STRONG>overridden</STRONG> by the command line argument.
|
|
|
|
</P>
|
|
<P>
|
|
The most common way to use this facility is to pass extra flags to
|
|
compilers. For example, in a properly written makefile, the variable
|
|
<CODE>CFLAGS</CODE> is included in each command that runs the C compiler, so a
|
|
file <TT>`foo.c'</TT> would be compiled something like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
cc -c $(CFLAGS) foo.c
|
|
</PRE>
|
|
|
|
<P>
|
|
Thus, whatever value you set for <CODE>CFLAGS</CODE> affects each compilation
|
|
that occurs. The makefile probably specifies the usual value for
|
|
<CODE>CFLAGS</CODE>, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
CFLAGS=-g
|
|
</PRE>
|
|
|
|
<P>
|
|
Each time you run <CODE>make</CODE>, you can override this value if you
|
|
wish. For example, if you say <SAMP>`make CFLAGS='-g -O''</SAMP>, each C
|
|
compilation will be done with <SAMP>`cc -c -g -O'</SAMP>. (This illustrates
|
|
how you can use quoting in the shell to enclose spaces and other
|
|
special characters in the value of a variable when you override it.)
|
|
|
|
</P>
|
|
<P>
|
|
The variable <CODE>CFLAGS</CODE> is only one of many standard variables that
|
|
exist just so that you can change them this way. See section <A HREF="make.html#SEC96">Variables Used by Implicit Rules</A>, for a complete list.
|
|
|
|
</P>
|
|
<P>
|
|
You can also program the makefile to look at additional variables of your
|
|
own, giving the user the ability to control other aspects of how the
|
|
makefile works by changing the variables.
|
|
|
|
</P>
|
|
<P>
|
|
When you override a variable with a command argument, you can define either
|
|
a recursively-expanded variable or a simply-expanded variable. The
|
|
examples shown above make a recursively-expanded variable; to make a
|
|
simply-expanded variable, write <SAMP>`:='</SAMP> instead of <SAMP>`='</SAMP>. But, unless
|
|
you want to include a variable reference or function call in the
|
|
<EM>value</EM> that you specify, it makes no difference which kind of
|
|
variable you create.
|
|
|
|
</P>
|
|
<P>
|
|
There is one way that the makefile can change a variable that you have
|
|
overridden. This is to use the <CODE>override</CODE> directive, which is a line
|
|
that looks like this: <SAMP>`override <VAR>variable</VAR> = <VAR>value</VAR>'</SAMP>
|
|
(see section <A HREF="make.html#SEC66">The <CODE>override</CODE> Directive</A>).
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC91" HREF="make.html#TOC91">Testing the Compilation of a Program</A></H2>
|
|
<P>
|
|
<A NAME="IDX626"></A>
|
|
<A NAME="IDX627"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Normally, when an error happens in executing a shell command, <CODE>make</CODE>
|
|
gives up immediately, returning a nonzero status. No further commands are
|
|
executed for any target. The error implies that the goal cannot be
|
|
correctly remade, and <CODE>make</CODE> reports this as soon as it knows.
|
|
|
|
</P>
|
|
<P>
|
|
When you are compiling a program that you have just changed, this is not
|
|
what you want. Instead, you would rather that <CODE>make</CODE> try compiling
|
|
every file that can be tried, to show you as many compilation errors
|
|
as possible.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX628"></A>
|
|
<A NAME="IDX629"></A>
|
|
On these occasions, you should use the <SAMP>`-k'</SAMP> or
|
|
<SAMP>`--keep-going'</SAMP> flag. This tells <CODE>make</CODE> to continue to
|
|
consider the other prerequisites of the pending targets, remaking them
|
|
if necessary, before it gives up and returns nonzero status. For
|
|
example, after an error in compiling one object file, <SAMP>`make -k'</SAMP>
|
|
will continue compiling other object files even though it already
|
|
knows that linking them will be impossible. In addition to continuing
|
|
after failed shell commands, <SAMP>`make -k'</SAMP> will continue as much as
|
|
possible after discovering that it does not know how to make a target
|
|
or prerequisite file. This will always cause an error message, but
|
|
without <SAMP>`-k'</SAMP>, it is a fatal error (see section <A HREF="make.html#SEC92">Summary of Options</A>).
|
|
</P>
|
|
<P>
|
|
The usual behavior of <CODE>make</CODE> assumes that your purpose is to get the
|
|
goals up to date; once <CODE>make</CODE> learns that this is impossible, it might
|
|
as well report the failure immediately. The <SAMP>`-k'</SAMP> flag says that the
|
|
real purpose is to test as much as possible of the changes made in the
|
|
program, perhaps to find several independent problems so that you can
|
|
correct them all before the next attempt to compile. This is why Emacs'
|
|
<KBD>M-x compile</KBD> command passes the <SAMP>`-k'</SAMP> flag by default.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC92" HREF="make.html#TOC92">Summary of Options</A></H2>
|
|
<P>
|
|
<A NAME="IDX630"></A>
|
|
<A NAME="IDX631"></A>
|
|
<A NAME="IDX632"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Here is a table of all the options <CODE>make</CODE> understands:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><SAMP>`-b'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX633"></A>
|
|
<DT><SAMP>`-m'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX634"></A>
|
|
These options are ignored for compatibility with other versions of <CODE>make</CODE>.
|
|
|
|
<DT><SAMP>`-C <VAR>dir</VAR>'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX635"></A>
|
|
<DT><SAMP>`--directory=<VAR>dir</VAR>'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX636"></A>
|
|
Change to directory <VAR>dir</VAR> before reading the makefiles. If multiple
|
|
<SAMP>`-C'</SAMP> options are specified, each is interpreted relative to the
|
|
previous one: <SAMP>`-C / -C etc'</SAMP> is equivalent to <SAMP>`-C /etc'</SAMP>.
|
|
This is typically used with recursive invocations of <CODE>make</CODE>
|
|
(see section <A HREF="make.html#SEC50">Recursive Use of <CODE>make</CODE></A>).
|
|
|
|
<DT><SAMP>`-d'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX637"></A>
|
|
|
|
Print debugging information in addition to normal processing. The
|
|
debugging information says which files are being considered for
|
|
remaking, which file-times are being compared and with what results,
|
|
which files actually need to be remade, which implicit rules are
|
|
considered and which are applied--everything interesting about how
|
|
<CODE>make</CODE> decides what to do. The <CODE>-d</CODE> option is equivalent to
|
|
<SAMP>`--debug=a'</SAMP> (see below).
|
|
|
|
<DT><SAMP>`--debug[=<VAR>options</VAR>]'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX638"></A>
|
|
|
|
Print debugging information in addition to normal processing. Various
|
|
levels and types of output can be chosen. With no arguments, print the
|
|
"basic" level of debugging. Possible arguments are below; only the
|
|
first character is considered, and values must be comma- or
|
|
space-separated.
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>a (<I>all</I>)</CODE>
|
|
<DD>
|
|
All types of debugging output are enabled. This is equivalent to using
|
|
<SAMP>`-d'</SAMP>.
|
|
|
|
<DT><CODE>b (<I>basic</I>)</CODE>
|
|
<DD>
|
|
Basic debugging prints each target that was found to be out-of-date, and
|
|
whether the build was successful or not.
|
|
|
|
<DT><CODE>v (<I>verbose</I>)</CODE>
|
|
<DD>
|
|
A level above <SAMP>`basic'</SAMP>; includes messages about which makefiles were
|
|
parsed, prerequisites that did not need to be rebuilt, etc. This option
|
|
also enables <SAMP>`basic'</SAMP> messages.
|
|
|
|
<DT><CODE>i (<I>implicit</I>)</CODE>
|
|
<DD>
|
|
Prints messages describing the implicit rule searches for each target.
|
|
This option also enables <SAMP>`basic'</SAMP> messages.
|
|
|
|
<DT><CODE>j (<I>jobs</I>)</CODE>
|
|
<DD>
|
|
Prints messages giving details on the invocation of specific subcommands.
|
|
|
|
<DT><CODE>m (<I>makefile</I>)</CODE>
|
|
<DD>
|
|
By default, the above messages are not enabled while trying to remake
|
|
the makefiles. This option enables messages while rebuilding makefiles,
|
|
too. Note that the <SAMP>`all'</SAMP> option does enable this option. This
|
|
option also enables <SAMP>`basic'</SAMP> messages.
|
|
</DL>
|
|
|
|
<DT><SAMP>`-e'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX639"></A>
|
|
<DT><SAMP>`--environment-overrides'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX640"></A>
|
|
Give variables taken from the environment precedence
|
|
over variables from makefiles.
|
|
See section <A HREF="make.html#SEC68">Variables from the Environment</A>.
|
|
|
|
<DT><SAMP>`-f <VAR>file</VAR>'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX641"></A>
|
|
<DT><SAMP>`--file=<VAR>file</VAR>'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX642"></A>
|
|
<DT><SAMP>`--makefile=<VAR>file</VAR>'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX643"></A>
|
|
Read the file named <VAR>file</VAR> as a makefile.
|
|
See section <A HREF="make.html#SEC12">Writing Makefiles</A>.
|
|
|
|
<DT><SAMP>`-h'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX644"></A>
|
|
<DT><SAMP>`--help'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX645"></A>
|
|
|
|
Remind you of the options that <CODE>make</CODE> understands and then exit.
|
|
|
|
<DT><SAMP>`-i'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX646"></A>
|
|
<DT><SAMP>`--ignore-errors'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX647"></A>
|
|
Ignore all errors in commands executed to remake files.
|
|
See section <A HREF="make.html#SEC48">Errors in Commands</A>.
|
|
|
|
<DT><SAMP>`-I <VAR>dir</VAR>'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX648"></A>
|
|
<DT><SAMP>`--include-dir=<VAR>dir</VAR>'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX649"></A>
|
|
Specifies a directory <VAR>dir</VAR> to search for included makefiles.
|
|
See section <A HREF="make.html#SEC15">Including Other Makefiles</A>. If several <SAMP>`-I'</SAMP>
|
|
options are used to specify several directories, the directories are
|
|
searched in the order specified.
|
|
|
|
<DT><SAMP>`-j [<VAR>jobs</VAR>]'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX650"></A>
|
|
<DT><SAMP>`--jobs[=<VAR>jobs</VAR>]'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX651"></A>
|
|
Specifies the number of jobs (commands) to run simultaneously. With no
|
|
argument, <CODE>make</CODE> runs as many jobs simultaneously as possible. If
|
|
there is more than one <SAMP>`-j'</SAMP> option, the last one is effective.
|
|
See section <A HREF="make.html#SEC47">Parallel Execution</A>,
|
|
for more information on how commands are run.
|
|
Note that this option is ignored on MS-DOS.
|
|
|
|
<DT><SAMP>`-k'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX652"></A>
|
|
<DT><SAMP>`--keep-going'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX653"></A>
|
|
Continue as much as possible after an error. While the target that
|
|
failed, and those that depend on it, cannot be remade, the other
|
|
prerequisites of these targets can be processed all the same.
|
|
See section <A HREF="make.html#SEC91">Testing the Compilation of a Program</A>.
|
|
|
|
<DT><SAMP>`-l [<VAR>load</VAR>]'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX654"></A>
|
|
<DT><SAMP>`--load-average[=<VAR>load</VAR>]'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX655"></A>
|
|
<DT><SAMP>`--max-load[=<VAR>load</VAR>]'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX656"></A>
|
|
Specifies that no new jobs (commands) should be started if there are
|
|
other jobs running and the load average is at least <VAR>load</VAR> (a
|
|
floating-point number). With no argument, removes a previous load
|
|
limit. See section <A HREF="make.html#SEC47">Parallel Execution</A>.
|
|
|
|
<DT><SAMP>`-n'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX657"></A>
|
|
<DT><SAMP>`--just-print'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX658"></A>
|
|
<DT><SAMP>`--dry-run'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX659"></A>
|
|
<DT><SAMP>`--recon'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX660"></A>
|
|
|
|
Print the commands that would be executed, but do not execute them.
|
|
See section <A HREF="make.html#SEC88">Instead of Executing the Commands</A>.
|
|
|
|
<DT><SAMP>`-o <VAR>file</VAR>'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX661"></A>
|
|
<DT><SAMP>`--old-file=<VAR>file</VAR>'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX662"></A>
|
|
<DT><SAMP>`--assume-old=<VAR>file</VAR>'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX663"></A>
|
|
Do not remake the file <VAR>file</VAR> even if it is older than its
|
|
prerequisites, and do not remake anything on account of changes in
|
|
<VAR>file</VAR>. Essentially the file is treated as very old and its rules
|
|
are ignored. See section <A HREF="make.html#SEC89">Avoiding Recompilation of Some Files</A>.
|
|
<DT><SAMP>`-p'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX664"></A>
|
|
<DT><SAMP>`--print-data-base'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX665"></A>
|
|
<A NAME="IDX666"></A>
|
|
<A NAME="IDX667"></A>
|
|
Print the data base (rules and variable values) that results from
|
|
reading the makefiles; then execute as usual or as otherwise specified.
|
|
This also prints the version information given by the <SAMP>`-v'</SAMP> switch
|
|
(see below). To print the data base without trying to remake any files,
|
|
use <SAMP>`make -qp'</SAMP>. To print the data base of predefined rules and
|
|
variables, use <SAMP>`make -p -f /dev/null'</SAMP>. The data base output
|
|
contains filename and linenumber information for command and variable
|
|
definitions, so it can be a useful debugging tool in complex environments.
|
|
|
|
<DT><SAMP>`-q'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX668"></A>
|
|
<DT><SAMP>`--question'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX669"></A>
|
|
"Question mode". Do not run any commands, or print anything; just
|
|
return an exit status that is zero if the specified targets are already
|
|
up to date, one if any remaking is required, or two if an error is
|
|
encountered. See section <A HREF="make.html#SEC88">Instead of Executing the Commands</A>.
|
|
<DT><SAMP>`-r'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX670"></A>
|
|
<DT><SAMP>`--no-builtin-rules'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX671"></A>
|
|
Eliminate use of the built-in implicit rules (see section <A HREF="make.html#SEC93">Using Implicit Rules</A>). You can still define your own by writing
|
|
pattern rules (see section <A HREF="make.html#SEC98">Defining and Redefining Pattern Rules</A>). The <SAMP>`-r'</SAMP> option also clears out the default list of
|
|
suffixes for suffix rules (see section <A HREF="make.html#SEC106">Old-Fashioned Suffix Rules</A>). But you can still define your own suffixes with a rule for
|
|
<CODE>.SUFFIXES</CODE>, and then define your own suffix rules. Note that only
|
|
<EM>rules</EM> are affected by the <CODE>-r</CODE> option; default variables
|
|
remain in effect (see section <A HREF="make.html#SEC96">Variables Used by Implicit Rules</A>); see the <SAMP>`-R'</SAMP> option below.
|
|
|
|
<DT><SAMP>`-R'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX672"></A>
|
|
<DT><SAMP>`--no-builtin-variables'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX673"></A>
|
|
Eliminate use of the built-in rule-specific variables (see section <A HREF="make.html#SEC96">Variables Used by Implicit Rules</A>). You can still define
|
|
your own, of course. The <SAMP>`-R'</SAMP> option also automatically enables
|
|
the <SAMP>`-r'</SAMP> option (see above), since it doesn't make sense to have
|
|
implicit rules without any definitions for the variables that they use.
|
|
|
|
<DT><SAMP>`-s'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX674"></A>
|
|
<DT><SAMP>`--silent'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX675"></A>
|
|
<DT><SAMP>`--quiet'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX676"></A>
|
|
|
|
Silent operation; do not print the commands as they are executed.
|
|
See section <A HREF="make.html#SEC45">Command Echoing</A>.
|
|
|
|
<DT><SAMP>`-S'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX677"></A>
|
|
<DT><SAMP>`--no-keep-going'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX678"></A>
|
|
<DT><SAMP>`--stop'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX679"></A>
|
|
|
|
Cancel the effect of the <SAMP>`-k'</SAMP> option. This is never necessary
|
|
except in a recursive <CODE>make</CODE> where <SAMP>`-k'</SAMP> might be inherited
|
|
from the top-level <CODE>make</CODE> via <CODE>MAKEFLAGS</CODE>
|
|
(see section <A HREF="make.html#SEC50">Recursive Use of <CODE>make</CODE></A>)
|
|
or if you set <SAMP>`-k'</SAMP> in <CODE>MAKEFLAGS</CODE> in your environment.
|
|
<DT><SAMP>`-t'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX680"></A>
|
|
<DT><SAMP>`--touch'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX681"></A>
|
|
|
|
Touch files (mark them up to date without really changing them)
|
|
instead of running their commands. This is used to pretend that the
|
|
commands were done, in order to fool future invocations of
|
|
<CODE>make</CODE>. See section <A HREF="make.html#SEC88">Instead of Executing the Commands</A>.
|
|
|
|
<DT><SAMP>`-v'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX682"></A>
|
|
<DT><SAMP>`--version'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX683"></A>
|
|
Print the version of the <CODE>make</CODE> program plus a copyright, a list
|
|
of authors, and a notice that there is no warranty; then exit.
|
|
|
|
<DT><SAMP>`-w'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX684"></A>
|
|
<DT><SAMP>`--print-directory'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX685"></A>
|
|
Print a message containing the working directory both before and after
|
|
executing the makefile. This may be useful for tracking down errors
|
|
from complicated nests of recursive <CODE>make</CODE> commands.
|
|
See section <A HREF="make.html#SEC50">Recursive Use of <CODE>make</CODE></A>. (In practice, you
|
|
rarely need to specify this option since <SAMP>`make'</SAMP> does it for you;
|
|
see section <A HREF="make.html#SEC54">The <SAMP>`--print-directory'</SAMP> Option</A>.)
|
|
|
|
<DT><SAMP>`--no-print-directory'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX686"></A>
|
|
Disable printing of the working directory under <CODE>-w</CODE>.
|
|
This option is useful when <CODE>-w</CODE> is turned on automatically,
|
|
but you do not want to see the extra messages.
|
|
See section <A HREF="make.html#SEC54">The <SAMP>`--print-directory'</SAMP> Option</A>.
|
|
|
|
<DT><SAMP>`-W <VAR>file</VAR>'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX687"></A>
|
|
<DT><SAMP>`--what-if=<VAR>file</VAR>'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX688"></A>
|
|
<DT><SAMP>`--new-file=<VAR>file</VAR>'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX689"></A>
|
|
<DT><SAMP>`--assume-new=<VAR>file</VAR>'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX690"></A>
|
|
Pretend that the target <VAR>file</VAR> has just been modified. When used
|
|
with the <SAMP>`-n'</SAMP> flag, this shows you what would happen if you were
|
|
to modify that file. Without <SAMP>`-n'</SAMP>, it is almost the same as
|
|
running a <CODE>touch</CODE> command on the given file before running
|
|
<CODE>make</CODE>, except that the modification time is changed only in the
|
|
imagination of <CODE>make</CODE>.
|
|
See section <A HREF="make.html#SEC88">Instead of Executing the Commands</A>.
|
|
|
|
<DT><SAMP>`--warn-undefined-variables'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX691"></A>
|
|
<A NAME="IDX692"></A>
|
|
<A NAME="IDX693"></A>
|
|
Issue a warning message whenever <CODE>make</CODE> sees a reference to an
|
|
undefined variable. This can be helpful when you are trying to debug
|
|
makefiles which use variables in complex ways.
|
|
</DL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC93" HREF="make.html#TOC93">Using Implicit Rules</A></H1>
|
|
<P>
|
|
<A NAME="IDX694"></A>
|
|
<A NAME="IDX695"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Certain standard ways of remaking target files are used very often. For
|
|
example, one customary way to make an object file is from a C source file
|
|
using the C compiler, <CODE>cc</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
<STRONG>Implicit rules</STRONG> tell <CODE>make</CODE> how to use customary techniques so
|
|
that you do not have to specify them in detail when you want to use
|
|
them. For example, there is an implicit rule for C compilation. File
|
|
names determine which implicit rules are run. For example, C
|
|
compilation typically takes a <TT>`.c'</TT> file and makes a <TT>`.o'</TT> file.
|
|
So <CODE>make</CODE> applies the implicit rule for C compilation when it sees
|
|
this combination of file name endings.
|
|
</P>
|
|
<P>
|
|
A chain of implicit rules can apply in sequence; for example, <CODE>make</CODE>
|
|
will remake a <TT>`.o'</TT> file from a <TT>`.y'</TT> file by way of a <TT>`.c'</TT> file.
|
|
See section <A HREF="make.html#SEC97">Chains of Implicit Rules</A>.
|
|
|
|
</P>
|
|
<P>
|
|
The built-in implicit rules use several variables in their commands so
|
|
that, by changing the values of the variables, you can change the way the
|
|
implicit rule works. For example, the variable <CODE>CFLAGS</CODE> controls the
|
|
flags given to the C compiler by the implicit rule for C compilation.
|
|
See section <A HREF="make.html#SEC96">Variables Used by Implicit Rules</A>.
|
|
|
|
</P>
|
|
<P>
|
|
You can define your own implicit rules by writing <STRONG>pattern rules</STRONG>.
|
|
See section <A HREF="make.html#SEC98">Defining and Redefining Pattern Rules</A>.
|
|
|
|
</P>
|
|
<P>
|
|
<STRONG>Suffix rules</STRONG> are a more limited way to define implicit rules.
|
|
Pattern rules are more general and clearer, but suffix rules are
|
|
retained for compatibility.
|
|
See section <A HREF="make.html#SEC106">Old-Fashioned Suffix Rules</A>.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC94" HREF="make.html#TOC94">Using Implicit Rules</A></H2>
|
|
<P>
|
|
<A NAME="IDX696"></A>
|
|
<A NAME="IDX697"></A>
|
|
|
|
</P>
|
|
<P>
|
|
To allow <CODE>make</CODE> to find a customary method for updating a target file,
|
|
all you have to do is refrain from specifying commands yourself. Either
|
|
write a rule with no command lines, or don't write a rule at all. Then
|
|
<CODE>make</CODE> will figure out which implicit rule to use based on which
|
|
kind of source file exists or can be made.
|
|
|
|
</P>
|
|
<P>
|
|
For example, suppose the makefile looks like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo : foo.o bar.o
|
|
cc -o foo foo.o bar.o $(CFLAGS) $(LDFLAGS)
|
|
</PRE>
|
|
|
|
<P>
|
|
Because you mention <TT>`foo.o'</TT> but do not give a rule for it, <CODE>make</CODE>
|
|
will automatically look for an implicit rule that tells how to update it.
|
|
This happens whether or not the file <TT>`foo.o'</TT> currently exists.
|
|
|
|
</P>
|
|
<P>
|
|
If an implicit rule is found, it can supply both commands and one or
|
|
more prerequisites (the source files). You would want to write a rule
|
|
for <TT>`foo.o'</TT> with no command lines if you need to specify additional
|
|
prerequisites, such as header files, that the implicit rule cannot
|
|
supply.
|
|
|
|
</P>
|
|
<P>
|
|
Each implicit rule has a target pattern and prerequisite patterns. There may
|
|
be many implicit rules with the same target pattern. For example, numerous
|
|
rules make <SAMP>`.o'</SAMP> files: one, from a <SAMP>`.c'</SAMP> file with the C compiler;
|
|
another, from a <SAMP>`.p'</SAMP> file with the Pascal compiler; and so on. The rule
|
|
that actually applies is the one whose prerequisites exist or can be made.
|
|
So, if you have a file <TT>`foo.c'</TT>, <CODE>make</CODE> will run the C compiler;
|
|
otherwise, if you have a file <TT>`foo.p'</TT>, <CODE>make</CODE> will run the Pascal
|
|
compiler; and so on.
|
|
|
|
</P>
|
|
<P>
|
|
Of course, when you write the makefile, you know which implicit rule you
|
|
want <CODE>make</CODE> to use, and you know it will choose that one because you
|
|
know which possible prerequisite files are supposed to exist.
|
|
See section <A HREF="make.html#SEC95">Catalogue of Implicit Rules</A>,
|
|
for a catalogue of all the predefined implicit rules.
|
|
|
|
</P>
|
|
<P>
|
|
Above, we said an implicit rule applies if the required prerequisites "exist
|
|
or can be made". A file "can be made" if it is mentioned explicitly in
|
|
the makefile as a target or a prerequisite, or if an implicit rule can be
|
|
recursively found for how to make it. When an implicit prerequisite is the
|
|
result of another implicit rule, we say that <STRONG>chaining</STRONG> is occurring.
|
|
See section <A HREF="make.html#SEC97">Chains of Implicit Rules</A>.
|
|
|
|
</P>
|
|
<P>
|
|
In general, <CODE>make</CODE> searches for an implicit rule for each target, and
|
|
for each double-colon rule, that has no commands. A file that is mentioned
|
|
only as a prerequisite is considered a target whose rule specifies nothing,
|
|
so implicit rule search happens for it. See section <A HREF="make.html#SEC107">Implicit Rule Search Algorithm</A>, for the
|
|
details of how the search is done.
|
|
|
|
</P>
|
|
<P>
|
|
Note that explicit prerequisites do not influence implicit rule search.
|
|
For example, consider this explicit rule:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo.o: foo.p
|
|
</PRE>
|
|
|
|
<P>
|
|
The prerequisite on <TT>`foo.p'</TT> does not necessarily mean that
|
|
<CODE>make</CODE> will remake <TT>`foo.o'</TT> according to the implicit rule to
|
|
make an object file, a <TT>`.o'</TT> file, from a Pascal source file, a
|
|
<TT>`.p'</TT> file. For example, if <TT>`foo.c'</TT> also exists, the implicit
|
|
rule to make an object file from a C source file is used instead,
|
|
because it appears before the Pascal rule in the list of predefined
|
|
implicit rules (see section <A HREF="make.html#SEC95">Catalogue of Implicit Rules</A>).
|
|
|
|
</P>
|
|
<P>
|
|
If you do not want an implicit rule to be used for a target that has no
|
|
commands, you can give that target empty commands by writing a semicolon
|
|
(see section <A HREF="make.html#SEC56">Using Empty Commands</A>).
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC95" HREF="make.html#TOC95">Catalogue of Implicit Rules</A></H2>
|
|
<P>
|
|
<A NAME="IDX698"></A>
|
|
<A NAME="IDX699"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Here is a catalogue of predefined implicit rules which are always
|
|
available unless the makefile explicitly overrides or cancels them.
|
|
See section <A HREF="make.html#SEC104">Canceling Implicit Rules</A>, for information on
|
|
canceling or overriding an implicit rule. The <SAMP>`-r'</SAMP> or
|
|
<SAMP>`--no-builtin-rules'</SAMP> option cancels all predefined rules.
|
|
|
|
</P>
|
|
<P>
|
|
Not all of these rules will always be defined, even when the <SAMP>`-r'</SAMP>
|
|
option is not given. Many of the predefined implicit rules are
|
|
implemented in <CODE>make</CODE> as suffix rules, so which ones will be
|
|
defined depends on the <STRONG>suffix list</STRONG> (the list of prerequisites of
|
|
the special target <CODE>.SUFFIXES</CODE>). The default suffix list is:
|
|
<CODE>.out</CODE>, <CODE>.a</CODE>, <CODE>.ln</CODE>, <CODE>.o</CODE>, <CODE>.c</CODE>, <CODE>.cc</CODE>,
|
|
<CODE>.C</CODE>, <CODE>.p</CODE>, <CODE>.f</CODE>, <CODE>.F</CODE>, <CODE>.r</CODE>, <CODE>.y</CODE>,
|
|
<CODE>.l</CODE>, <CODE>.s</CODE>, <CODE>.S</CODE>, <CODE>.mod</CODE>, <CODE>.sym</CODE>, <CODE>.def</CODE>,
|
|
<CODE>.h</CODE>, <CODE>.info</CODE>, <CODE>.dvi</CODE>, <CODE>.tex</CODE>, <CODE>.texinfo</CODE>,
|
|
<CODE>.texi</CODE>, <CODE>.txinfo</CODE>, <CODE>.w</CODE>, <CODE>.ch</CODE> <CODE>.web</CODE>,
|
|
<CODE>.sh</CODE>, <CODE>.elc</CODE>, <CODE>.el</CODE>. All of the implicit rules
|
|
described below whose prerequisites have one of these suffixes are
|
|
actually suffix rules. If you modify the suffix list, the only
|
|
predefined suffix rules in effect will be those named by one or two of
|
|
the suffixes that are on the list you specify; rules whose suffixes fail
|
|
to be on the list are disabled. See section <A HREF="make.html#SEC106">Old-Fashioned Suffix Rules</A>, for full details on suffix rules.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT>Compiling C programs
|
|
<DD>
|
|
<A NAME="IDX700"></A>
|
|
<A NAME="IDX701"></A>
|
|
<A NAME="IDX702"></A>
|
|
<A NAME="IDX703"></A>
|
|
<A NAME="IDX704"></A>
|
|
<TT>`<VAR>n</VAR>.o'</TT> is made automatically from <TT>`<VAR>n</VAR>.c'</TT> with
|
|
a command of the form <SAMP>`$(CC) -c $(CPPFLAGS) $(CFLAGS)'</SAMP>.
|
|
<DT>Compiling C++ programs
|
|
<DD>
|
|
<A NAME="IDX705"></A>
|
|
<A NAME="IDX706"></A>
|
|
<A NAME="IDX707"></A>
|
|
<A NAME="IDX708"></A>
|
|
<TT>`<VAR>n</VAR>.o'</TT> is made automatically from <TT>`<VAR>n</VAR>.cc'</TT> or
|
|
<TT>`<VAR>n</VAR>.C'</TT> with a command of the form <SAMP>`$(CXX) -c $(CPPFLAGS)
|
|
$(CXXFLAGS)'</SAMP>. We encourage you to use the suffix <SAMP>`.cc'</SAMP> for C++
|
|
source files instead of <SAMP>`.C'</SAMP>.
|
|
<DT>Compiling Pascal programs
|
|
<DD>
|
|
<A NAME="IDX709"></A>
|
|
<A NAME="IDX710"></A>
|
|
<A NAME="IDX711"></A>
|
|
<TT>`<VAR>n</VAR>.o'</TT> is made automatically from <TT>`<VAR>n</VAR>.p'</TT>
|
|
with the command <SAMP>`$(PC) -c $(PFLAGS)'</SAMP>.
|
|
<DT>Compiling Fortran and Ratfor programs
|
|
<DD>
|
|
<A NAME="IDX712"></A>
|
|
<A NAME="IDX713"></A>
|
|
<A NAME="IDX714"></A>
|
|
<A NAME="IDX715"></A>
|
|
<A NAME="IDX716"></A>
|
|
<A NAME="IDX717"></A>
|
|
<TT>`<VAR>n</VAR>.o'</TT> is made automatically from <TT>`<VAR>n</VAR>.r'</TT>,
|
|
<TT>`<VAR>n</VAR>.F'</TT> or <TT>`<VAR>n</VAR>.f'</TT> by running the
|
|
Fortran compiler. The precise command used is as follows:
|
|
<DL COMPACT>
|
|
|
|
<DT><SAMP>`.f'</SAMP>
|
|
<DD>
|
|
<SAMP>`$(FC) -c $(FFLAGS)'</SAMP>.
|
|
<DT><SAMP>`.F'</SAMP>
|
|
<DD>
|
|
<SAMP>`$(FC) -c $(FFLAGS) $(CPPFLAGS)'</SAMP>.
|
|
<DT><SAMP>`.r'</SAMP>
|
|
<DD>
|
|
<SAMP>`$(FC) -c $(FFLAGS) $(RFLAGS)'</SAMP>.
|
|
</DL>
|
|
|
|
<DT>Preprocessing Fortran and Ratfor programs
|
|
<DD>
|
|
<TT>`<VAR>n</VAR>.f'</TT> is made automatically from <TT>`<VAR>n</VAR>.r'</TT> or
|
|
<TT>`<VAR>n</VAR>.F'</TT>. This rule runs just the preprocessor to convert a
|
|
Ratfor or preprocessable Fortran program into a strict Fortran
|
|
program. The precise command used is as follows:
|
|
<DL COMPACT>
|
|
|
|
<DT><SAMP>`.F'</SAMP>
|
|
<DD>
|
|
<SAMP>`$(FC) -F $(CPPFLAGS) $(FFLAGS)'</SAMP>.
|
|
<DT><SAMP>`.r'</SAMP>
|
|
<DD>
|
|
<SAMP>`$(FC) -F $(FFLAGS) $(RFLAGS)'</SAMP>.
|
|
</DL>
|
|
|
|
<DT>Compiling Modula-2 programs
|
|
<DD>
|
|
<A NAME="IDX718"></A>
|
|
<A NAME="IDX719"></A>
|
|
<A NAME="IDX720"></A>
|
|
<A NAME="IDX721"></A>
|
|
<A NAME="IDX722"></A>
|
|
<TT>`<VAR>n</VAR>.sym'</TT> is made from <TT>`<VAR>n</VAR>.def'</TT> with a command
|
|
of the form <SAMP>`$(M2C) $(M2FLAGS) $(DEFFLAGS)'</SAMP>. <TT>`<VAR>n</VAR>.o'</TT>
|
|
is made from <TT>`<VAR>n</VAR>.mod'</TT>; the form is:
|
|
<SAMP>`$(M2C) $(M2FLAGS) $(MODFLAGS)'</SAMP>.
|
|
<DT>Assembling and preprocessing assembler programs
|
|
<DD>
|
|
<A NAME="IDX723"></A>
|
|
<A NAME="IDX724"></A>
|
|
<A NAME="IDX725"></A>
|
|
<TT>`<VAR>n</VAR>.o'</TT> is made automatically from <TT>`<VAR>n</VAR>.s'</TT> by
|
|
running the assembler, <CODE>as</CODE>. The precise command is
|
|
<SAMP>`$(AS) $(ASFLAGS)'</SAMP>.
|
|
<A NAME="IDX726"></A>
|
|
<TT>`<VAR>n</VAR>.s'</TT> is made automatically from <TT>`<VAR>n</VAR>.S'</TT> by
|
|
running the C preprocessor, <CODE>cpp</CODE>. The precise command is
|
|
<SAMP>`$(CPP) $(CPPFLAGS)'</SAMP>.
|
|
|
|
<DT>Linking a single object file
|
|
<DD>
|
|
<A NAME="IDX727"></A>
|
|
<A NAME="IDX728"></A>
|
|
<A NAME="IDX729"></A>
|
|
<TT>`<VAR>n</VAR>'</TT> is made automatically from <TT>`<VAR>n</VAR>.o'</TT> by running
|
|
the linker (usually called <CODE>ld</CODE>) via the C compiler. The precise
|
|
command used is <SAMP>`$(CC) $(LDFLAGS) <VAR>n</VAR>.o $(LOADLIBES) $(LDLIBS)'</SAMP>.
|
|
|
|
This rule does the right thing for a simple program with only one
|
|
source file. It will also do the right thing if there are multiple
|
|
object files (presumably coming from various other source files), one
|
|
of which has a name matching that of the executable file. Thus,
|
|
|
|
|
|
<PRE>
|
|
x: y.o z.o
|
|
</PRE>
|
|
|
|
when <TT>`x.c'</TT>, <TT>`y.c'</TT> and <TT>`z.c'</TT> all exist will execute:
|
|
|
|
|
|
<PRE>
|
|
cc -c x.c -o x.o
|
|
cc -c y.c -o y.o
|
|
cc -c z.c -o z.o
|
|
cc x.o y.o z.o -o x
|
|
rm -f x.o
|
|
rm -f y.o
|
|
rm -f z.o
|
|
</PRE>
|
|
|
|
In more complicated cases, such as when there is no object file whose
|
|
name derives from the executable file name, you must write an explicit
|
|
command for linking.
|
|
|
|
Each kind of file automatically made into <SAMP>`.o'</SAMP> object files will
|
|
be automatically linked by using the compiler (<SAMP>`$(CC)'</SAMP>,
|
|
<SAMP>`$(FC)'</SAMP> or <SAMP>`$(PC)'</SAMP>; the C compiler <SAMP>`$(CC)'</SAMP> is used to
|
|
assemble <SAMP>`.s'</SAMP> files) without the <SAMP>`-c'</SAMP> option. This could be
|
|
done by using the <SAMP>`.o'</SAMP> object files as intermediates, but it is
|
|
faster to do the compiling and linking in one step, so that's how it's
|
|
done.
|
|
<DT>Yacc for C programs
|
|
<DD>
|
|
<A NAME="IDX730"></A>
|
|
<A NAME="IDX731"></A>
|
|
<A NAME="IDX732"></A>
|
|
<TT>`<VAR>n</VAR>.c'</TT> is made automatically from <TT>`<VAR>n</VAR>.y'</TT> by
|
|
running Yacc with the command <SAMP>`$(YACC) $(YFLAGS)'</SAMP>.
|
|
|
|
<DT>Lex for C programs
|
|
<DD>
|
|
<A NAME="IDX733"></A>
|
|
<A NAME="IDX734"></A>
|
|
<A NAME="IDX735"></A>
|
|
<TT>`<VAR>n</VAR>.c'</TT> is made automatically from <TT>`<VAR>n</VAR>.l'</TT> by
|
|
by running Lex. The actual command is <SAMP>`$(LEX) $(LFLAGS)'</SAMP>.
|
|
|
|
<DT>Lex for Ratfor programs
|
|
<DD>
|
|
<TT>`<VAR>n</VAR>.r'</TT> is made automatically from <TT>`<VAR>n</VAR>.l'</TT> by
|
|
by running Lex. The actual command is <SAMP>`$(LEX) $(LFLAGS)'</SAMP>.
|
|
|
|
The convention of using the same suffix <SAMP>`.l'</SAMP> for all Lex files
|
|
regardless of whether they produce C code or Ratfor code makes it
|
|
impossible for <CODE>make</CODE> to determine automatically which of the two
|
|
languages you are using in any particular case. If <CODE>make</CODE> is
|
|
called upon to remake an object file from a <SAMP>`.l'</SAMP> file, it must
|
|
guess which compiler to use. It will guess the C compiler, because
|
|
that is more common. If you are using Ratfor, make sure <CODE>make</CODE>
|
|
knows this by mentioning <TT>`<VAR>n</VAR>.r'</TT> in the makefile. Or, if you
|
|
are using Ratfor exclusively, with no C files, remove <SAMP>`.c'</SAMP> from
|
|
the list of implicit rule suffixes with:
|
|
|
|
<PRE>
|
|
.SUFFIXES:
|
|
.SUFFIXES: .o .r .f .l ...
|
|
</PRE>
|
|
|
|
<DT>Making Lint Libraries from C, Yacc, or Lex programs
|
|
<DD>
|
|
<A NAME="IDX736"></A>
|
|
<A NAME="IDX737"></A>
|
|
<A NAME="IDX738"></A>
|
|
<TT>`<VAR>n</VAR>.ln'</TT> is made from <TT>`<VAR>n</VAR>.c'</TT> by running <CODE>lint</CODE>.
|
|
The precise command is <SAMP>`$(LINT) $(LINTFLAGS) $(CPPFLAGS) -i'</SAMP>.
|
|
The same command is used on the C code produced from
|
|
<TT>`<VAR>n</VAR>.y'</TT> or <TT>`<VAR>n</VAR>.l'</TT>.
|
|
<DT>TeX and Web
|
|
<DD>
|
|
<A NAME="IDX739"></A>
|
|
<A NAME="IDX740"></A>
|
|
<A NAME="IDX741"></A>
|
|
<A NAME="IDX742"></A>
|
|
<A NAME="IDX743"></A>
|
|
<A NAME="IDX744"></A>
|
|
<A NAME="IDX745"></A>
|
|
<A NAME="IDX746"></A>
|
|
<A NAME="IDX747"></A>
|
|
<A NAME="IDX748"></A>
|
|
<A NAME="IDX749"></A>
|
|
<A NAME="IDX750"></A>
|
|
<TT>`<VAR>n</VAR>.dvi'</TT> is made from <TT>`<VAR>n</VAR>.tex'</TT> with the command
|
|
<SAMP>`$(TEX)'</SAMP>. <TT>`<VAR>n</VAR>.tex'</TT> is made from <TT>`<VAR>n</VAR>.web'</TT> with
|
|
<SAMP>`$(WEAVE)'</SAMP>, or from <TT>`<VAR>n</VAR>.w'</TT> (and from <TT>`<VAR>n</VAR>.ch'</TT> if
|
|
it exists or can be made) with <SAMP>`$(CWEAVE)'</SAMP>. <TT>`<VAR>n</VAR>.p'</TT> is
|
|
made from <TT>`<VAR>n</VAR>.web'</TT> with <SAMP>`$(TANGLE)'</SAMP> and <TT>`<VAR>n</VAR>.c'</TT>
|
|
is made from <TT>`<VAR>n</VAR>.w'</TT> (and from <TT>`<VAR>n</VAR>.ch'</TT> if it exists
|
|
or can be made) with <SAMP>`$(CTANGLE)'</SAMP>.
|
|
<DT>Texinfo and Info
|
|
<DD>
|
|
<A NAME="IDX751"></A>
|
|
<A NAME="IDX752"></A>
|
|
<A NAME="IDX753"></A>
|
|
<A NAME="IDX754"></A>
|
|
<A NAME="IDX755"></A>
|
|
<A NAME="IDX756"></A>
|
|
<A NAME="IDX757"></A>
|
|
<A NAME="IDX758"></A>
|
|
<TT>`<VAR>n</VAR>.dvi'</TT> is made from <TT>`<VAR>n</VAR>.texinfo'</TT>,
|
|
<TT>`<VAR>n</VAR>.texi'</TT>, or <TT>`<VAR>n</VAR>.txinfo'</TT>, with the command
|
|
<SAMP>`$(TEXI2DVI) $(TEXI2DVI_FLAGS)'</SAMP>. <TT>`<VAR>n</VAR>.info'</TT> is made from
|
|
<TT>`<VAR>n</VAR>.texinfo'</TT>, <TT>`<VAR>n</VAR>.texi'</TT>, or <TT>`<VAR>n</VAR>.txinfo'</TT>, with
|
|
the command <SAMP>`$(MAKEINFO) $(MAKEINFO_FLAGS)'</SAMP>.
|
|
|
|
<DT>RCS
|
|
<DD>
|
|
<A NAME="IDX759"></A>
|
|
<A NAME="IDX760"></A>
|
|
<A NAME="IDX761"></A>
|
|
Any file <TT>`<VAR>n</VAR>'</TT> is extracted if necessary from an RCS file
|
|
named either <TT>`<VAR>n</VAR>,v'</TT> or <TT>`RCS/<VAR>n</VAR>,v'</TT>. The precise
|
|
command used is <SAMP>`$(CO) $(COFLAGS)'</SAMP>. <TT>`<VAR>n</VAR>'</TT> will not be
|
|
extracted from RCS if it already exists, even if the RCS file is
|
|
newer. The rules for RCS are terminal
|
|
(see section <A HREF="make.html#SEC103">Match-Anything Pattern Rules</A>),
|
|
so RCS files cannot be generated from another source; they must
|
|
actually exist.
|
|
<DT>SCCS
|
|
<DD>
|
|
<A NAME="IDX762"></A>
|
|
<A NAME="IDX763"></A>
|
|
<A NAME="IDX764"></A>
|
|
Any file <TT>`<VAR>n</VAR>'</TT> is extracted if necessary from an SCCS file
|
|
named either <TT>`s.<VAR>n</VAR>'</TT> or <TT>`SCCS/s.<VAR>n</VAR>'</TT>. The precise
|
|
command used is <SAMP>`$(GET) $(GFLAGS)'</SAMP>. The rules for SCCS are
|
|
terminal (see section <A HREF="make.html#SEC103">Match-Anything Pattern Rules</A>),
|
|
so SCCS files cannot be generated from another source; they must
|
|
actually exist.
|
|
<A NAME="IDX765"></A>
|
|
For the benefit of SCCS, a file <TT>`<VAR>n</VAR>'</TT> is copied from
|
|
<TT>`<VAR>n</VAR>.sh'</TT> and made executable (by everyone). This is for
|
|
shell scripts that are checked into SCCS. Since RCS preserves the
|
|
execution permission of a file, you do not need to use this feature
|
|
with RCS.
|
|
We recommend that you avoid using of SCCS. RCS is widely held to be
|
|
superior, and is also free. By choosing free software in place of
|
|
comparable (or inferior) proprietary software, you support the free
|
|
software movement.
|
|
</DL>
|
|
|
|
<P>
|
|
Usually, you want to change only the variables listed in the table
|
|
above, which are documented in the following section.
|
|
|
|
</P>
|
|
<P>
|
|
However, the commands in built-in implicit rules actually use
|
|
variables such as <CODE>COMPILE.c</CODE>, <CODE>LINK.p</CODE>, and
|
|
<CODE>PREPROCESS.S</CODE>, whose values contain the commands listed above.
|
|
|
|
</P>
|
|
<P>
|
|
<CODE>make</CODE> follows the convention that the rule to compile a
|
|
<TT>`.<VAR>x</VAR>'</TT> source file uses the variable <CODE>COMPILE.<VAR>x</VAR></CODE>.
|
|
Similarly, the rule to produce an executable from a <TT>`.<VAR>x</VAR>'</TT>
|
|
file uses <CODE>LINK.<VAR>x</VAR></CODE>; and the rule to preprocess a
|
|
<TT>`.<VAR>x</VAR>'</TT> file uses <CODE>PREPROCESS.<VAR>x</VAR></CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX766"></A>
|
|
Every rule that produces an object file uses the variable
|
|
<CODE>OUTPUT_OPTION</CODE>. <CODE>make</CODE> defines this variable either to
|
|
contain <SAMP>`-o $@'</SAMP>, or to be empty, depending on a compile-time
|
|
option. You need the <SAMP>`-o'</SAMP> option to ensure that the output goes
|
|
into the right file when the source file is in a different directory,
|
|
as when using <CODE>VPATH</CODE> (see section <A HREF="make.html#SEC26">Searching Directories for Prerequisites</A>). However,
|
|
compilers on some systems do not accept a <SAMP>`-o'</SAMP> switch for object
|
|
files. If you use such a system, and use <CODE>VPATH</CODE>, some
|
|
compilations will put their output in the wrong place.
|
|
A possible workaround for this problem is to give <CODE>OUTPUT_OPTION</CODE>
|
|
the value <SAMP>`; mv $*.o $@'</SAMP>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC96" HREF="make.html#TOC96">Variables Used by Implicit Rules</A></H2>
|
|
<P>
|
|
<A NAME="IDX767"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The commands in built-in implicit rules make liberal use of certain
|
|
predefined variables. You can alter these variables in the makefile,
|
|
with arguments to <CODE>make</CODE>, or in the environment to alter how the
|
|
implicit rules work without redefining the rules themselves. You can
|
|
cancel all variables used by implicit rules with the <SAMP>`-R'</SAMP> or
|
|
<SAMP>`--no-builtin-variables'</SAMP> option.
|
|
|
|
</P>
|
|
<P>
|
|
For example, the command used to compile a C source file actually says
|
|
<SAMP>`$(CC) -c $(CFLAGS) $(CPPFLAGS)'</SAMP>. The default values of the variables
|
|
used are <SAMP>`cc'</SAMP> and nothing, resulting in the command <SAMP>`cc -c'</SAMP>. By
|
|
redefining <SAMP>`CC'</SAMP> to <SAMP>`ncc'</SAMP>, you could cause <SAMP>`ncc'</SAMP> to be
|
|
used for all C compilations performed by the implicit rule. By redefining
|
|
<SAMP>`CFLAGS'</SAMP> to be <SAMP>`-g'</SAMP>, you could pass the <SAMP>`-g'</SAMP> option to
|
|
each compilation. <EM>All</EM> implicit rules that do C compilation use
|
|
<SAMP>`$(CC)'</SAMP> to get the program name for the compiler and <EM>all</EM>
|
|
include <SAMP>`$(CFLAGS)'</SAMP> among the arguments given to the compiler.
|
|
</P>
|
|
<P>
|
|
The variables used in implicit rules fall into two classes: those that are
|
|
names of programs (like <CODE>CC</CODE>) and those that contain arguments for the
|
|
programs (like <CODE>CFLAGS</CODE>). (The "name of a program" may also contain
|
|
some command arguments, but it must start with an actual executable program
|
|
name.) If a variable value contains more than one argument, separate them
|
|
with spaces.
|
|
|
|
</P>
|
|
<P>
|
|
Here is a table of variables used as names of programs in built-in rules:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>AR</CODE>
|
|
<DD>
|
|
<A NAME="IDX768"></A>
|
|
Archive-maintaining program; default <SAMP>`ar'</SAMP>.
|
|
<A NAME="IDX769"></A>
|
|
|
|
<DT><CODE>AS</CODE>
|
|
<DD>
|
|
<A NAME="IDX770"></A>
|
|
Program for doing assembly; default <SAMP>`as'</SAMP>.
|
|
<A NAME="IDX771"></A>
|
|
|
|
<DT><CODE>CC</CODE>
|
|
<DD>
|
|
<A NAME="IDX772"></A>
|
|
Program for compiling C programs; default <SAMP>`cc'</SAMP>.
|
|
<A NAME="IDX773"></A>
|
|
|
|
<DT><CODE>CXX</CODE>
|
|
<DD>
|
|
<A NAME="IDX774"></A>
|
|
Program for compiling C++ programs; default <SAMP>`g++'</SAMP>.
|
|
<A NAME="IDX775"></A>
|
|
|
|
<DT><CODE>CO</CODE>
|
|
<DD>
|
|
<A NAME="IDX776"></A>
|
|
Program for extracting a file from RCS; default <SAMP>`co'</SAMP>.
|
|
<A NAME="IDX777"></A>
|
|
|
|
<DT><CODE>CPP</CODE>
|
|
<DD>
|
|
<A NAME="IDX778"></A>
|
|
Program for running the C preprocessor, with results to standard output;
|
|
default <SAMP>`$(CC) -E'</SAMP>.
|
|
|
|
<DT><CODE>FC</CODE>
|
|
<DD>
|
|
<A NAME="IDX779"></A>
|
|
Program for compiling or preprocessing Fortran and Ratfor programs;
|
|
default <SAMP>`f77'</SAMP>.
|
|
<A NAME="IDX780"></A>
|
|
|
|
<DT><CODE>GET</CODE>
|
|
<DD>
|
|
<A NAME="IDX781"></A>
|
|
Program for extracting a file from SCCS; default <SAMP>`get'</SAMP>.
|
|
<A NAME="IDX782"></A>
|
|
|
|
<DT><CODE>LEX</CODE>
|
|
<DD>
|
|
<A NAME="IDX783"></A>
|
|
Program to use to turn Lex grammars into C programs or Ratfor programs;
|
|
default <SAMP>`lex'</SAMP>.
|
|
<A NAME="IDX784"></A>
|
|
|
|
<DT><CODE>PC</CODE>
|
|
<DD>
|
|
<A NAME="IDX785"></A>
|
|
Program for compiling Pascal programs; default <SAMP>`pc'</SAMP>.
|
|
<A NAME="IDX786"></A>
|
|
|
|
<DT><CODE>YACC</CODE>
|
|
<DD>
|
|
<A NAME="IDX787"></A>
|
|
Program to use to turn Yacc grammars into C programs; default <SAMP>`yacc'</SAMP>.
|
|
<A NAME="IDX788"></A>
|
|
|
|
<DT><CODE>YACCR</CODE>
|
|
<DD>
|
|
<A NAME="IDX789"></A>
|
|
Program to use to turn Yacc grammars into Ratfor
|
|
programs; default <SAMP>`yacc -r'</SAMP>.
|
|
|
|
<DT><CODE>MAKEINFO</CODE>
|
|
<DD>
|
|
<A NAME="IDX790"></A>
|
|
Program to convert a Texinfo source file into an Info file; default
|
|
<SAMP>`makeinfo'</SAMP>.
|
|
<A NAME="IDX791"></A>
|
|
|
|
<DT><CODE>TEX</CODE>
|
|
<DD>
|
|
<A NAME="IDX792"></A>
|
|
Program to make TeX DVI files from TeX source;
|
|
default <SAMP>`tex'</SAMP>.
|
|
<A NAME="IDX793"></A>
|
|
|
|
<DT><CODE>TEXI2DVI</CODE>
|
|
<DD>
|
|
<A NAME="IDX794"></A>
|
|
Program to make TeX DVI files from Texinfo source;
|
|
default <SAMP>`texi2dvi'</SAMP>.
|
|
<A NAME="IDX795"></A>
|
|
|
|
<DT><CODE>WEAVE</CODE>
|
|
<DD>
|
|
<A NAME="IDX796"></A>
|
|
Program to translate Web into TeX; default <SAMP>`weave'</SAMP>.
|
|
<A NAME="IDX797"></A>
|
|
|
|
<DT><CODE>CWEAVE</CODE>
|
|
<DD>
|
|
<A NAME="IDX798"></A>
|
|
Program to translate C Web into TeX; default <SAMP>`cweave'</SAMP>.
|
|
<A NAME="IDX799"></A>
|
|
|
|
<DT><CODE>TANGLE</CODE>
|
|
<DD>
|
|
<A NAME="IDX800"></A>
|
|
Program to translate Web into Pascal; default <SAMP>`tangle'</SAMP>.
|
|
<A NAME="IDX801"></A>
|
|
|
|
<DT><CODE>CTANGLE</CODE>
|
|
<DD>
|
|
<A NAME="IDX802"></A>
|
|
Program to translate C Web into C; default <SAMP>`ctangle'</SAMP>.
|
|
<A NAME="IDX803"></A>
|
|
|
|
<DT><CODE>RM</CODE>
|
|
<DD>
|
|
<A NAME="IDX804"></A>
|
|
Command to remove a file; default <SAMP>`rm -f'</SAMP>.
|
|
<A NAME="IDX805"></A>
|
|
</DL>
|
|
|
|
<P>
|
|
Here is a table of variables whose values are additional arguments for the
|
|
programs above. The default values for all of these is the empty
|
|
string, unless otherwise noted.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>ARFLAGS</CODE>
|
|
<DD>
|
|
<A NAME="IDX806"></A>
|
|
Flags to give the archive-maintaining program; default <SAMP>`rv'</SAMP>.
|
|
|
|
<DT><CODE>ASFLAGS</CODE>
|
|
<DD>
|
|
<A NAME="IDX807"></A>
|
|
Extra flags to give to the assembler (when explicitly
|
|
invoked on a <SAMP>`.s'</SAMP> or <SAMP>`.S'</SAMP> file).
|
|
|
|
<DT><CODE>CFLAGS</CODE>
|
|
<DD>
|
|
<A NAME="IDX808"></A>
|
|
Extra flags to give to the C compiler.
|
|
|
|
<DT><CODE>CXXFLAGS</CODE>
|
|
<DD>
|
|
<A NAME="IDX809"></A>
|
|
Extra flags to give to the C++ compiler.
|
|
|
|
<DT><CODE>COFLAGS</CODE>
|
|
<DD>
|
|
<A NAME="IDX810"></A>
|
|
Extra flags to give to the RCS <CODE>co</CODE> program.
|
|
|
|
<DT><CODE>CPPFLAGS</CODE>
|
|
<DD>
|
|
<A NAME="IDX811"></A>
|
|
Extra flags to give to the C preprocessor and programs
|
|
that use it (the C and Fortran compilers).
|
|
|
|
<DT><CODE>FFLAGS</CODE>
|
|
<DD>
|
|
<A NAME="IDX812"></A>
|
|
Extra flags to give to the Fortran compiler.
|
|
|
|
<DT><CODE>GFLAGS</CODE>
|
|
<DD>
|
|
<A NAME="IDX813"></A>
|
|
Extra flags to give to the SCCS <CODE>get</CODE> program.
|
|
|
|
<DT><CODE>LDFLAGS</CODE>
|
|
<DD>
|
|
<A NAME="IDX814"></A>
|
|
Extra flags to give to compilers when they are
|
|
supposed to invoke the linker, <SAMP>`ld'</SAMP>.
|
|
|
|
<DT><CODE>LFLAGS</CODE>
|
|
<DD>
|
|
<A NAME="IDX815"></A>
|
|
Extra flags to give to Lex.
|
|
|
|
<DT><CODE>PFLAGS</CODE>
|
|
<DD>
|
|
<A NAME="IDX816"></A>
|
|
Extra flags to give to the Pascal compiler.
|
|
|
|
<DT><CODE>RFLAGS</CODE>
|
|
<DD>
|
|
<A NAME="IDX817"></A>
|
|
Extra flags to give to the Fortran compiler for Ratfor programs.
|
|
|
|
<DT><CODE>YFLAGS</CODE>
|
|
<DD>
|
|
<A NAME="IDX818"></A>
|
|
Extra flags to give to Yacc.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC97" HREF="make.html#TOC97">Chains of Implicit Rules</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX819"></A>
|
|
<A NAME="IDX820"></A>
|
|
Sometimes a file can be made by a sequence of implicit rules. For example,
|
|
a file <TT>`<VAR>n</VAR>.o'</TT> could be made from <TT>`<VAR>n</VAR>.y'</TT> by running
|
|
first Yacc and then <CODE>cc</CODE>. Such a sequence is called a <STRONG>chain</STRONG>.
|
|
|
|
</P>
|
|
<P>
|
|
If the file <TT>`<VAR>n</VAR>.c'</TT> exists, or is mentioned in the makefile, no
|
|
special searching is required: <CODE>make</CODE> finds that the object file can
|
|
be made by C compilation from <TT>`<VAR>n</VAR>.c'</TT>; later on, when considering
|
|
how to make <TT>`<VAR>n</VAR>.c'</TT>, the rule for running Yacc is
|
|
used. Ultimately both <TT>`<VAR>n</VAR>.c'</TT> and <TT>`<VAR>n</VAR>.o'</TT> are
|
|
updated.
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX821"></A>
|
|
<A NAME="IDX822"></A>
|
|
However, even if <TT>`<VAR>n</VAR>.c'</TT> does not exist and is not mentioned,
|
|
<CODE>make</CODE> knows how to envision it as the missing link between
|
|
<TT>`<VAR>n</VAR>.o'</TT> and <TT>`<VAR>n</VAR>.y'</TT>! In this case, <TT>`<VAR>n</VAR>.c'</TT> is
|
|
called an <STRONG>intermediate file</STRONG>. Once <CODE>make</CODE> has decided to use the
|
|
intermediate file, it is entered in the data base as if it had been
|
|
mentioned in the makefile, along with the implicit rule that says how to
|
|
create it.
|
|
</P>
|
|
<P>
|
|
Intermediate files are remade using their rules just like all other
|
|
files. But intermediate files are treated differently in two ways.
|
|
|
|
</P>
|
|
<P>
|
|
The first difference is what happens if the intermediate file does not
|
|
exist. If an ordinary file <VAR>b</VAR> does not exist, and <CODE>make</CODE>
|
|
considers a target that depends on <VAR>b</VAR>, it invariably creates
|
|
<VAR>b</VAR> and then updates the target from <VAR>b</VAR>. But if <VAR>b</VAR> is an
|
|
intermediate file, then <CODE>make</CODE> can leave well enough alone. It
|
|
won't bother updating <VAR>b</VAR>, or the ultimate target, unless some
|
|
prerequisite of <VAR>b</VAR> is newer than that target or there is some other
|
|
reason to update that target.
|
|
|
|
</P>
|
|
<P>
|
|
The second difference is that if <CODE>make</CODE> <EM>does</EM> create <VAR>b</VAR>
|
|
in order to update something else, it deletes <VAR>b</VAR> later on after it
|
|
is no longer needed. Therefore, an intermediate file which did not
|
|
exist before <CODE>make</CODE> also does not exist after <CODE>make</CODE>.
|
|
<CODE>make</CODE> reports the deletion to you by printing a <SAMP>`rm -f'</SAMP>
|
|
command showing which file it is deleting.
|
|
|
|
</P>
|
|
<P>
|
|
Ordinarily, a file cannot be intermediate if it is mentioned in the
|
|
makefile as a target or prerequisite. However, you can explicitly mark a
|
|
file as intermediate by listing it as a prerequisite of the special target
|
|
<CODE>.INTERMEDIATE</CODE>. This takes effect even if the file is mentioned
|
|
explicitly in some other way.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX823"></A>
|
|
<A NAME="IDX824"></A>
|
|
<A NAME="IDX825"></A>
|
|
You can prevent automatic deletion of an intermediate file by marking it
|
|
as a <STRONG>secondary</STRONG> file. To do this, list it as a prerequisite of the
|
|
special target <CODE>.SECONDARY</CODE>. When a file is secondary, <CODE>make</CODE>
|
|
will not create the file merely because it does not already exist, but
|
|
<CODE>make</CODE> does not automatically delete the file. Marking a file as
|
|
secondary also marks it as intermediate.
|
|
|
|
</P>
|
|
<P>
|
|
You can list the target pattern of an implicit rule (such as <SAMP>`%.o'</SAMP>)
|
|
as a prerequisite of the special target <CODE>.PRECIOUS</CODE> to preserve
|
|
intermediate files made by implicit rules whose target patterns match
|
|
that file's name; see section <A HREF="make.html#SEC49">Interrupting or Killing <CODE>make</CODE></A>.<A NAME="IDX826"></A>
|
|
<A NAME="IDX827"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A chain can involve more than two implicit rules. For example, it is
|
|
possible to make a file <TT>`foo'</TT> from <TT>`RCS/foo.y,v'</TT> by running RCS,
|
|
Yacc and <CODE>cc</CODE>. Then both <TT>`foo.y'</TT> and <TT>`foo.c'</TT> are
|
|
intermediate files that are deleted at the end.
|
|
</P>
|
|
<P>
|
|
No single implicit rule can appear more than once in a chain. This means
|
|
that <CODE>make</CODE> will not even consider such a ridiculous thing as making
|
|
<TT>`foo'</TT> from <TT>`foo.o.o'</TT> by running the linker twice. This
|
|
constraint has the added benefit of preventing any infinite loop in the
|
|
search for an implicit rule chain.
|
|
|
|
</P>
|
|
<P>
|
|
There are some special implicit rules to optimize certain cases that would
|
|
otherwise be handled by rule chains. For example, making <TT>`foo'</TT> from
|
|
<TT>`foo.c'</TT> could be handled by compiling and linking with separate
|
|
chained rules, using <TT>`foo.o'</TT> as an intermediate file. But what
|
|
actually happens is that a special rule for this case does the compilation
|
|
and linking with a single <CODE>cc</CODE> command. The optimized rule is used in
|
|
preference to the step-by-step chain because it comes earlier in the
|
|
ordering of rules.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC98" HREF="make.html#TOC98">Defining and Redefining Pattern Rules</A></H2>
|
|
|
|
<P>
|
|
You define an implicit rule by writing a <STRONG>pattern rule</STRONG>. A pattern
|
|
rule looks like an ordinary rule, except that its target contains the
|
|
character <SAMP>`%'</SAMP> (exactly one of them). The target is considered a
|
|
pattern for matching file names; the <SAMP>`%'</SAMP> can match any nonempty
|
|
substring, while other characters match only themselves. The prerequisites
|
|
likewise use <SAMP>`%'</SAMP> to show how their names relate to the target name.
|
|
|
|
</P>
|
|
<P>
|
|
Thus, a pattern rule <SAMP>`%.o : %.c'</SAMP> says how to make any file
|
|
<TT>`<VAR>stem</VAR>.o'</TT> from another file <TT>`<VAR>stem</VAR>.c'</TT>.
|
|
</P>
|
|
<P>
|
|
Note that expansion using <SAMP>`%'</SAMP> in pattern rules occurs
|
|
<STRONG>after</STRONG> any variable or function expansions, which take place
|
|
when the makefile is read. See section <A HREF="make.html#SEC57">How to Use Variables</A>, and section <A HREF="make.html#SEC75">Functions for Transforming Text</A>.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC99" HREF="make.html#TOC99">Introduction to Pattern Rules</A></H3>
|
|
<P>
|
|
<A NAME="IDX828"></A>
|
|
<A NAME="IDX829"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A pattern rule contains the character <SAMP>`%'</SAMP> (exactly one of them)
|
|
in the target; otherwise, it looks exactly like an ordinary rule. The
|
|
target is a pattern for matching file names; the <SAMP>`%'</SAMP> matches any
|
|
nonempty substring, while other characters match only themselves.
|
|
<A NAME="IDX830"></A>
|
|
<A NAME="IDX831"></A>
|
|
|
|
</P>
|
|
<P>
|
|
For example, <SAMP>`%.c'</SAMP> as a pattern matches any file name that ends in
|
|
<SAMP>`.c'</SAMP>. <SAMP>`s.%.c'</SAMP> as a pattern matches any file name that starts
|
|
with <SAMP>`s.'</SAMP>, ends in <SAMP>`.c'</SAMP> and is at least five characters long.
|
|
(There must be at least one character to match the <SAMP>`%'</SAMP>.) The substring
|
|
that the <SAMP>`%'</SAMP> matches is called the <STRONG>stem</STRONG>.
|
|
</P>
|
|
<P>
|
|
<SAMP>`%'</SAMP> in a prerequisite of a pattern rule stands for the same stem
|
|
that was matched by the <SAMP>`%'</SAMP> in the target. In order for
|
|
the pattern rule to apply, its target pattern must match the file name
|
|
under consideration, and its prerequisite patterns must name files that
|
|
exist or can be made. These files become prerequisites of the target.
|
|
<A NAME="IDX832"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Thus, a rule of the form
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
%.o : %.c ; <VAR>command</VAR>...
|
|
</PRE>
|
|
|
|
<P>
|
|
specifies how to make a file <TT>`<VAR>n</VAR>.o'</TT>, with another file
|
|
<TT>`<VAR>n</VAR>.c'</TT> as its prerequisite, provided that <TT>`<VAR>n</VAR>.c'</TT>
|
|
exists or can be made.
|
|
|
|
</P>
|
|
<P>
|
|
There may also be prerequisites that do not use <SAMP>`%'</SAMP>; such a prerequisite
|
|
attaches to every file made by this pattern rule. These unvarying
|
|
prerequisites are useful occasionally.
|
|
|
|
</P>
|
|
<P>
|
|
A pattern rule need not have any prerequisites that contain <SAMP>`%'</SAMP>, or
|
|
in fact any prerequisites at all. Such a rule is effectively a general
|
|
wildcard. It provides a way to make any file that matches the target
|
|
pattern. See section <A HREF="make.html#SEC105">Defining Last-Resort Default Rules</A>.
|
|
|
|
</P>
|
|
<P>
|
|
Pattern rules may have more than one target. Unlike normal rules, this
|
|
does not act as many different rules with the same prerequisites and
|
|
commands. If a pattern rule has multiple targets, <CODE>make</CODE> knows that
|
|
the rule's commands are responsible for making all of the targets. The
|
|
commands are executed only once to make all the targets. When searching
|
|
for a pattern rule to match a target, the target patterns of a rule other
|
|
than the one that matches the target in need of a rule are incidental:
|
|
<CODE>make</CODE> worries only about giving commands and prerequisites to the file
|
|
presently in question. However, when this file's commands are run, the
|
|
other targets are marked as having been updated themselves.
|
|
<A NAME="IDX833"></A>
|
|
<A NAME="IDX834"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The order in which pattern rules appear in the makefile is important
|
|
since this is the order in which they are considered.
|
|
Of equally applicable
|
|
rules, only the first one found is used. The rules you write take precedence
|
|
over those that are built in. Note however, that a rule whose
|
|
prerequisites actually exist or are mentioned always takes priority over a
|
|
rule with prerequisites that must be made by chaining other implicit rules.
|
|
<A NAME="IDX835"></A>
|
|
<A NAME="IDX836"></A>
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC100" HREF="make.html#TOC100">Pattern Rule Examples</A></H3>
|
|
|
|
<P>
|
|
Here are some examples of pattern rules actually predefined in
|
|
<CODE>make</CODE>. First, the rule that compiles <SAMP>`.c'</SAMP> files into <SAMP>`.o'</SAMP>
|
|
files:
|
|
</P>
|
|
|
|
<PRE>
|
|
%.o : %.c
|
|
$(CC) -c $(CFLAGS) $(CPPFLAGS) $< -o $@
|
|
</PRE>
|
|
|
|
<P>
|
|
defines a rule that can make any file <TT>`<VAR>x</VAR>.o'</TT> from
|
|
<TT>`<VAR>x</VAR>.c'</TT>. The command uses the automatic variables <SAMP>`$@'</SAMP> and
|
|
<SAMP>`$<'</SAMP> to substitute the names of the target file and the source file
|
|
in each case where the rule applies (see section <A HREF="make.html#SEC101">Automatic Variables</A>).
|
|
</P>
|
|
<P>
|
|
Here is a second built-in rule:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
% :: RCS/%,v
|
|
$(CO) $(COFLAGS) $<
|
|
</PRE>
|
|
|
|
<P>
|
|
defines a rule that can make any file <TT>`<VAR>x</VAR>'</TT> whatsoever from a
|
|
corresponding file <TT>`<VAR>x</VAR>,v'</TT> in the subdirectory <TT>`RCS'</TT>. Since
|
|
the target is <SAMP>`%'</SAMP>, this rule will apply to any file whatever, provided
|
|
the appropriate prerequisite file exists. The double colon makes the rule
|
|
<STRONG>terminal</STRONG>, which means that its prerequisite may not be an intermediate
|
|
file (see section <A HREF="make.html#SEC103">Match-Anything Pattern Rules</A>).
|
|
</P>
|
|
<P>
|
|
This pattern rule has two targets:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
%.tab.c %.tab.h: %.y
|
|
bison -d $<
|
|
</PRE>
|
|
|
|
<P>
|
|
This tells <CODE>make</CODE> that the command <SAMP>`bison -d <VAR>x</VAR>.y'</SAMP> will
|
|
make both <TT>`<VAR>x</VAR>.tab.c'</TT> and <TT>`<VAR>x</VAR>.tab.h'</TT>. If the file
|
|
<TT>`foo'</TT> depends on the files <TT>`parse.tab.o'</TT> and <TT>`scan.o'</TT>
|
|
and the file <TT>`scan.o'</TT> depends on the file <TT>`parse.tab.h'</TT>,
|
|
when <TT>`parse.y'</TT> is changed, the command <SAMP>`bison -d parse.y'</SAMP>
|
|
will be executed only once, and the prerequisites of both
|
|
<TT>`parse.tab.o'</TT> and <TT>`scan.o'</TT> will be satisfied. (Presumably
|
|
the file <TT>`parse.tab.o'</TT> will be recompiled from <TT>`parse.tab.c'</TT>
|
|
and the file <TT>`scan.o'</TT> from <TT>`scan.c'</TT>, while <TT>`foo'</TT> is
|
|
linked from <TT>`parse.tab.o'</TT>, <TT>`scan.o'</TT>, and its other
|
|
prerequisites, and it will execute happily ever after.)
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC101" HREF="make.html#TOC101">Automatic Variables</A></H3>
|
|
<P>
|
|
<A NAME="IDX837"></A>
|
|
<A NAME="IDX838"></A>
|
|
<A NAME="IDX839"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Suppose you are writing a pattern rule to compile a <SAMP>`.c'</SAMP> file into a
|
|
<SAMP>`.o'</SAMP> file: how do you write the <SAMP>`cc'</SAMP> command so that it operates
|
|
on the right source file name? You cannot write the name in the command,
|
|
because the name is different each time the implicit rule is applied.
|
|
|
|
</P>
|
|
<P>
|
|
What you do is use a special feature of <CODE>make</CODE>, the <STRONG>automatic
|
|
variables</STRONG>. These variables have values computed afresh for each rule that
|
|
is executed, based on the target and prerequisites of the rule. In this
|
|
example, you would use <SAMP>`$@'</SAMP> for the object file name and <SAMP>`$<'</SAMP>
|
|
for the source file name.
|
|
|
|
</P>
|
|
<P>
|
|
Here is a table of automatic variables:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>$@</CODE>
|
|
<DD>
|
|
<A NAME="IDX840"></A>
|
|
<A NAME="IDX841"></A>
|
|
|
|
The file name of the target of the rule. If the target is an archive
|
|
member, then <SAMP>`$@'</SAMP> is the name of the archive file. In a pattern
|
|
rule that has multiple targets (see section <A HREF="make.html#SEC99">Introduction to Pattern Rules</A>), <SAMP>`$@'</SAMP> is the name of whichever target caused the
|
|
rule's commands to be run.
|
|
|
|
<A NAME="IDX842"></A>
|
|
<A NAME="IDX843"></A>
|
|
<DT><CODE>$%</CODE>
|
|
<DD>
|
|
The target member name, when the target is an archive member.
|
|
See section <A HREF="make.html#SEC108">Using <CODE>make</CODE> to Update Archive Files</A>. For example, if the target is <TT>`foo.a(bar.o)'</TT> then
|
|
<SAMP>`$%'</SAMP> is <TT>`bar.o'</TT> and <SAMP>`$@'</SAMP> is <TT>`foo.a'</TT>. <SAMP>`$%'</SAMP> is
|
|
empty when the target is not an archive member.
|
|
|
|
<A NAME="IDX844"></A>
|
|
<A NAME="IDX845"></A>
|
|
<DT><CODE>$<</CODE>
|
|
<DD>
|
|
The name of the first prerequisite. If the target got its commands from
|
|
an implicit rule, this will be the first prerequisite added by the
|
|
implicit rule (see section <A HREF="make.html#SEC93">Using Implicit Rules</A>).
|
|
|
|
<A NAME="IDX846"></A>
|
|
<A NAME="IDX847"></A>
|
|
<DT><CODE>$?</CODE>
|
|
<DD>
|
|
The names of all the prerequisites that are newer than the target, with
|
|
spaces between them. For prerequisites which are archive members, only
|
|
the member named is used (see section <A HREF="make.html#SEC108">Using <CODE>make</CODE> to Update Archive Files</A>).
|
|
<A NAME="IDX848"></A>
|
|
<A NAME="IDX849"></A>
|
|
|
|
<A NAME="IDX850"></A>
|
|
<A NAME="IDX851"></A>
|
|
<DT><CODE>$^</CODE>
|
|
<DD>
|
|
The names of all the prerequisites, with spaces between them. For
|
|
prerequisites which are archive members, only the member named is used
|
|
(see section <A HREF="make.html#SEC108">Using <CODE>make</CODE> to Update Archive Files</A>). A target has only one prerequisite on each other file
|
|
it depends on, no matter how many times each file is listed as a
|
|
prerequisite. So if you list a prerequisite more than once for a target,
|
|
the value of <CODE>$^</CODE> contains just one copy of the name.
|
|
<A NAME="IDX852"></A>
|
|
<A NAME="IDX853"></A>
|
|
|
|
<A NAME="IDX854"></A>
|
|
<A NAME="IDX855"></A>
|
|
<DT><CODE>$+</CODE>
|
|
<DD>
|
|
This is like <SAMP>`$^'</SAMP>, but prerequisites listed more than once are
|
|
duplicated in the order they were listed in the makefile. This is
|
|
primarily useful for use in linking commands where it is meaningful to
|
|
repeat library file names in a particular order.
|
|
|
|
<A NAME="IDX856"></A>
|
|
<A NAME="IDX857"></A>
|
|
<DT><CODE>$*</CODE>
|
|
<DD>
|
|
The stem with which an implicit rule matches (see section <A HREF="make.html#SEC102">How Patterns Match</A>). If the target is <TT>`dir/a.foo.b'</TT> and the target
|
|
pattern is <TT>`a.%.b'</TT> then the stem is <TT>`dir/foo'</TT>. The stem is
|
|
useful for constructing names of related files.<A NAME="IDX858"></A>
|
|
|
|
In a static pattern rule, the stem is part of the file name that matched
|
|
the <SAMP>`%'</SAMP> in the target pattern.
|
|
|
|
In an explicit rule, there is no stem; so <SAMP>`$*'</SAMP> cannot be determined
|
|
in that way. Instead, if the target name ends with a recognized suffix
|
|
(see section <A HREF="make.html#SEC106">Old-Fashioned Suffix Rules</A>), <SAMP>`$*'</SAMP> is set to
|
|
the target name minus the suffix. For example, if the target name is
|
|
<SAMP>`foo.c'</SAMP>, then <SAMP>`$*'</SAMP> is set to <SAMP>`foo'</SAMP>, since <SAMP>`.c'</SAMP> is a
|
|
suffix. GNU <CODE>make</CODE> does this bizarre thing only for compatibility
|
|
with other implementations of <CODE>make</CODE>. You should generally avoid
|
|
using <SAMP>`$*'</SAMP> except in implicit rules or static pattern rules.
|
|
If the target name in an explicit rule does not end with a recognized
|
|
suffix, <SAMP>`$*'</SAMP> is set to the empty string for that rule.
|
|
</DL>
|
|
|
|
<P>
|
|
<SAMP>`$?'</SAMP> is useful even in explicit rules when you wish to operate on only
|
|
the prerequisites that have changed. For example, suppose that an archive
|
|
named <TT>`lib'</TT> is supposed to contain copies of several object files.
|
|
This rule copies just the changed object files into the archive:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
lib: foo.o bar.o lose.o win.o
|
|
ar r lib $?
|
|
</PRE>
|
|
|
|
<P>
|
|
Of the variables listed above, four have values that are single file
|
|
names, and three have values that are lists of file names. These seven
|
|
have variants that get just the file's directory name or just the file
|
|
name within the directory. The variant variables' names are formed by
|
|
appending <SAMP>`D'</SAMP> or <SAMP>`F'</SAMP>, respectively. These variants are
|
|
semi-obsolete in GNU <CODE>make</CODE> since the functions <CODE>dir</CODE> and
|
|
<CODE>notdir</CODE> can be used to get a similar effect (see section <A HREF="make.html#SEC78">Functions for File Names</A>). Note, however, that the
|
|
<SAMP>`F'</SAMP> variants all omit the trailing slash which always appears in
|
|
the output of the <CODE>dir</CODE> function. Here is a table of the variants:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><SAMP>`$(@D)'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX859"></A>
|
|
<A NAME="IDX860"></A>
|
|
|
|
The directory part of the file name of the target, with the trailing
|
|
slash removed. If the value of <SAMP>`$@'</SAMP> is <TT>`dir/foo.o'</TT> then
|
|
<SAMP>`$(@D)'</SAMP> is <TT>`dir'</TT>. This value is <TT>`.'</TT> if <SAMP>`$@'</SAMP> does
|
|
not contain a slash.
|
|
|
|
<A NAME="IDX861"></A>
|
|
<A NAME="IDX862"></A>
|
|
<DT><SAMP>`$(@F)'</SAMP>
|
|
<DD>
|
|
The file-within-directory part of the file name of the target. If the
|
|
value of <SAMP>`$@'</SAMP> is <TT>`dir/foo.o'</TT> then <SAMP>`$(@F)'</SAMP> is
|
|
<TT>`foo.o'</TT>. <SAMP>`$(@F)'</SAMP> is equivalent to <SAMP>`$(notdir $@)'</SAMP>.
|
|
|
|
<A NAME="IDX863"></A>
|
|
<A NAME="IDX864"></A>
|
|
<DT><SAMP>`$(*D)'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX865"></A>
|
|
<A NAME="IDX866"></A>
|
|
<DT><SAMP>`$(*F)'</SAMP>
|
|
<DD>
|
|
The directory part and the file-within-directory
|
|
part of the stem; <TT>`dir'</TT> and <TT>`foo'</TT> in this example.
|
|
|
|
<A NAME="IDX867"></A>
|
|
<A NAME="IDX868"></A>
|
|
<DT><SAMP>`$(%D)'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX869"></A>
|
|
<A NAME="IDX870"></A>
|
|
<DT><SAMP>`$(%F)'</SAMP>
|
|
<DD>
|
|
The directory part and the file-within-directory part of the target
|
|
archive member name. This makes sense only for archive member targets
|
|
of the form <TT>`<VAR>archive</VAR>(<VAR>member</VAR>)'</TT> and is useful only when
|
|
<VAR>member</VAR> may contain a directory name. (See section <A HREF="make.html#SEC109">Archive Members as Targets</A>.)
|
|
|
|
<A NAME="IDX871"></A>
|
|
<A NAME="IDX872"></A>
|
|
<DT><SAMP>`$(<D)'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX873"></A>
|
|
<A NAME="IDX874"></A>
|
|
<DT><SAMP>`$(<F)'</SAMP>
|
|
<DD>
|
|
The directory part and the file-within-directory
|
|
part of the first prerequisite.
|
|
|
|
<A NAME="IDX875"></A>
|
|
<A NAME="IDX876"></A>
|
|
<DT><SAMP>`$(^D)'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX877"></A>
|
|
<A NAME="IDX878"></A>
|
|
<DT><SAMP>`$(^F)'</SAMP>
|
|
<DD>
|
|
Lists of the directory parts and the file-within-directory
|
|
parts of all prerequisites.
|
|
|
|
<A NAME="IDX879"></A>
|
|
<A NAME="IDX880"></A>
|
|
<DT><SAMP>`$(?D)'</SAMP>
|
|
<DD>
|
|
<A NAME="IDX881"></A>
|
|
<A NAME="IDX882"></A>
|
|
<DT><SAMP>`$(?F)'</SAMP>
|
|
<DD>
|
|
Lists of the directory parts and the file-within-directory parts of
|
|
all prerequisites that are newer than the target.
|
|
</DL>
|
|
|
|
<P>
|
|
Note that we use a special stylistic convention when we talk about these
|
|
automatic variables; we write "the value of <SAMP>`$<'</SAMP>", rather than
|
|
"the variable <CODE><</CODE>" as we would write for ordinary variables
|
|
such as <CODE>objects</CODE> and <CODE>CFLAGS</CODE>. We think this convention
|
|
looks more natural in this special case. Please do not assume it has a
|
|
deep significance; <SAMP>`$<'</SAMP> refers to the variable named <CODE><</CODE> just
|
|
as <SAMP>`$(CFLAGS)'</SAMP> refers to the variable named <CODE>CFLAGS</CODE>.
|
|
You could just as well use <SAMP>`$(<)'</SAMP> in place of <SAMP>`$<'</SAMP>.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC102" HREF="make.html#TOC102">How Patterns Match</A></H3>
|
|
|
|
<P>
|
|
<A NAME="IDX883"></A>
|
|
A target pattern is composed of a <SAMP>`%'</SAMP> between a prefix and a suffix,
|
|
either or both of which may be empty. The pattern matches a file name only
|
|
if the file name starts with the prefix and ends with the suffix, without
|
|
overlap. The text between the prefix and the suffix is called the
|
|
<STRONG>stem</STRONG>. Thus, when the pattern <SAMP>`%.o'</SAMP> matches the file name
|
|
<TT>`test.o'</TT>, the stem is <SAMP>`test'</SAMP>. The pattern rule prerequisites are
|
|
turned into actual file names by substituting the stem for the character
|
|
<SAMP>`%'</SAMP>. Thus, if in the same example one of the prerequisites is written
|
|
as <SAMP>`%.c'</SAMP>, it expands to <SAMP>`test.c'</SAMP>.
|
|
</P>
|
|
<P>
|
|
When the target pattern does not contain a slash (and it usually does
|
|
not), directory names in the file names are removed from the file name
|
|
before it is compared with the target prefix and suffix. After the
|
|
comparison of the file name to the target pattern, the directory
|
|
names, along with the slash that ends them, are added on to the
|
|
prerequisite file names generated from the pattern rule's prerequisite
|
|
patterns and the file name. The directories are ignored only for the
|
|
purpose of finding an implicit rule to use, not in the application of
|
|
that rule. Thus, <SAMP>`e%t'</SAMP> matches the file name <TT>`src/eat'</TT>,
|
|
with <SAMP>`src/a'</SAMP> as the stem. When prerequisites are turned into file
|
|
names, the directories from the stem are added at the front, while the
|
|
rest of the stem is substituted for the <SAMP>`%'</SAMP>. The stem
|
|
<SAMP>`src/a'</SAMP> with a prerequisite pattern <SAMP>`c%r'</SAMP> gives the file name
|
|
<TT>`src/car'</TT>.
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC103" HREF="make.html#TOC103">Match-Anything Pattern Rules</A></H3>
|
|
|
|
<P>
|
|
<A NAME="IDX884"></A>
|
|
<A NAME="IDX885"></A>
|
|
When a pattern rule's target is just <SAMP>`%'</SAMP>, it matches any file name
|
|
whatever. We call these rules <STRONG>match-anything</STRONG> rules. They are very
|
|
useful, but it can take a lot of time for <CODE>make</CODE> to think about them,
|
|
because it must consider every such rule for each file name listed either
|
|
as a target or as a prerequisite.
|
|
|
|
</P>
|
|
<P>
|
|
Suppose the makefile mentions <TT>`foo.c'</TT>. For this target, <CODE>make</CODE>
|
|
would have to consider making it by linking an object file <TT>`foo.c.o'</TT>,
|
|
or by C compilation-and-linking in one step from <TT>`foo.c.c'</TT>, or by
|
|
Pascal compilation-and-linking from <TT>`foo.c.p'</TT>, and many other
|
|
possibilities.
|
|
|
|
</P>
|
|
<P>
|
|
We know these possibilities are ridiculous since <TT>`foo.c'</TT> is a C source
|
|
file, not an executable. If <CODE>make</CODE> did consider these possibilities,
|
|
it would ultimately reject them, because files such as <TT>`foo.c.o'</TT> and
|
|
<TT>`foo.c.p'</TT> would not exist. But these possibilities are so
|
|
numerous that <CODE>make</CODE> would run very slowly if it had to consider
|
|
them.
|
|
</P>
|
|
<P>
|
|
To gain speed, we have put various constraints on the way <CODE>make</CODE>
|
|
considers match-anything rules. There are two different constraints that
|
|
can be applied, and each time you define a match-anything rule you must
|
|
choose one or the other for that rule.
|
|
|
|
</P>
|
|
<P>
|
|
One choice is to mark the match-anything rule as <STRONG>terminal</STRONG> by defining
|
|
it with a double colon. When a rule is terminal, it does not apply unless
|
|
its prerequisites actually exist. Prerequisites that could be made with
|
|
other implicit rules are not good enough. In other words, no further
|
|
chaining is allowed beyond a terminal rule.
|
|
|
|
</P>
|
|
<P>
|
|
For example, the built-in implicit rules for extracting sources from RCS
|
|
and SCCS files are terminal; as a result, if the file <TT>`foo.c,v'</TT> does
|
|
not exist, <CODE>make</CODE> will not even consider trying to make it as an
|
|
intermediate file from <TT>`foo.c,v.o'</TT> or from <TT>`RCS/SCCS/s.foo.c,v'</TT>.
|
|
RCS and SCCS files are generally ultimate source files, which should not be
|
|
remade from any other files; therefore, <CODE>make</CODE> can save time by not
|
|
looking for ways to remake them.
|
|
</P>
|
|
<P>
|
|
If you do not mark the match-anything rule as terminal, then it is
|
|
nonterminal. A nonterminal match-anything rule cannot apply to a file name
|
|
that indicates a specific type of data. A file name indicates a specific
|
|
type of data if some non-match-anything implicit rule target matches it.
|
|
|
|
</P>
|
|
<P>
|
|
For example, the file name <TT>`foo.c'</TT> matches the target for the pattern
|
|
rule <SAMP>`%.c : %.y'</SAMP> (the rule to run Yacc). Regardless of whether this
|
|
rule is actually applicable (which happens only if there is a file
|
|
<TT>`foo.y'</TT>), the fact that its target matches is enough to prevent
|
|
consideration of any nonterminal match-anything rules for the file
|
|
<TT>`foo.c'</TT>. Thus, <CODE>make</CODE> will not even consider trying to make
|
|
<TT>`foo.c'</TT> as an executable file from <TT>`foo.c.o'</TT>, <TT>`foo.c.c'</TT>,
|
|
<TT>`foo.c.p'</TT>, etc.
|
|
</P>
|
|
<P>
|
|
The motivation for this constraint is that nonterminal match-anything
|
|
rules are used for making files containing specific types of data (such as
|
|
executable files) and a file name with a recognized suffix indicates some
|
|
other specific type of data (such as a C source file).
|
|
|
|
</P>
|
|
<P>
|
|
Special built-in dummy pattern rules are provided solely to recognize
|
|
certain file names so that nonterminal match-anything rules will not be
|
|
considered. These dummy rules have no prerequisites and no commands, and
|
|
they are ignored for all other purposes. For example, the built-in
|
|
implicit rule
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
%.p :
|
|
</PRE>
|
|
|
|
<P>
|
|
exists to make sure that Pascal source files such as <TT>`foo.p'</TT> match a
|
|
specific target pattern and thereby prevent time from being wasted looking
|
|
for <TT>`foo.p.o'</TT> or <TT>`foo.p.c'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
Dummy pattern rules such as the one for <SAMP>`%.p'</SAMP> are made for every
|
|
suffix listed as valid for use in suffix rules (see section <A HREF="make.html#SEC106">Old-Fashioned Suffix Rules</A>).
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC104" HREF="make.html#TOC104">Canceling Implicit Rules</A></H3>
|
|
|
|
<P>
|
|
You can override a built-in implicit rule (or one you have defined
|
|
yourself) by defining a new pattern rule with the same target and
|
|
prerequisites, but different commands. When the new rule is defined, the
|
|
built-in one is replaced. The new rule's position in the sequence of
|
|
implicit rules is determined by where you write the new rule.
|
|
|
|
</P>
|
|
<P>
|
|
You can cancel a built-in implicit rule by defining a pattern rule with the
|
|
same target and prerequisites, but no commands. For example, the following
|
|
would cancel the rule that runs the assembler:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
%.o : %.s
|
|
</PRE>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC105" HREF="make.html#TOC105">Defining Last-Resort Default Rules</A></H2>
|
|
<P>
|
|
<A NAME="IDX886"></A>
|
|
<A NAME="IDX887"></A>
|
|
|
|
</P>
|
|
<P>
|
|
You can define a last-resort implicit rule by writing a terminal
|
|
match-anything pattern rule with no prerequisites (see section <A HREF="make.html#SEC103">Match-Anything Pattern Rules</A>). This is just like any other pattern rule; the only thing
|
|
special about it is that it will match any target. So such a rule's
|
|
commands are used for all targets and prerequisites that have no commands
|
|
of their own and for which no other implicit rule applies.
|
|
|
|
</P>
|
|
<P>
|
|
For example, when testing a makefile, you might not care if the source
|
|
files contain real data, only that they exist. Then you might do this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
%::
|
|
touch $@
|
|
</PRE>
|
|
|
|
<P>
|
|
to cause all the source files needed (as prerequisites) to be created
|
|
automatically.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX888"></A>
|
|
You can instead define commands to be used for targets for which there
|
|
are no rules at all, even ones which don't specify commands. You do
|
|
this by writing a rule for the target <CODE>.DEFAULT</CODE>. Such a rule's
|
|
commands are used for all prerequisites which do not appear as targets in
|
|
any explicit rule, and for which no implicit rule applies. Naturally,
|
|
there is no <CODE>.DEFAULT</CODE> rule unless you write one.
|
|
|
|
</P>
|
|
<P>
|
|
If you use <CODE>.DEFAULT</CODE> with no commands or prerequisites:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
.DEFAULT:
|
|
</PRE>
|
|
|
|
<P>
|
|
the commands previously stored for <CODE>.DEFAULT</CODE> are cleared.
|
|
Then <CODE>make</CODE> acts as if you had never defined <CODE>.DEFAULT</CODE> at all.
|
|
|
|
</P>
|
|
<P>
|
|
If you do not want a target to get the commands from a match-anything
|
|
pattern rule or <CODE>.DEFAULT</CODE>, but you also do not want any commands
|
|
to be run for the target, you can give it empty commands (see section <A HREF="make.html#SEC56">Using Empty Commands</A>).
|
|
</P>
|
|
<P>
|
|
You can use a last-resort rule to override part of another makefile.
|
|
See section <A HREF="make.html#SEC18">Overriding Part of Another Makefile</A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC106" HREF="make.html#TOC106">Old-Fashioned Suffix Rules</A></H2>
|
|
<P>
|
|
<A NAME="IDX889"></A>
|
|
<A NAME="IDX890"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<STRONG>Suffix rules</STRONG> are the old-fashioned way of defining implicit rules for
|
|
<CODE>make</CODE>. Suffix rules are obsolete because pattern rules are more
|
|
general and clearer. They are supported in GNU <CODE>make</CODE> for
|
|
compatibility with old makefiles. They come in two kinds:
|
|
<STRONG>double-suffix</STRONG> and <STRONG>single-suffix</STRONG>.
|
|
</P>
|
|
<P>
|
|
A double-suffix rule is defined by a pair of suffixes: the target suffix
|
|
and the source suffix. It matches any file whose name ends with the
|
|
target suffix. The corresponding implicit prerequisite is made by
|
|
replacing the target suffix with the source suffix in the file name. A
|
|
two-suffix rule whose target and source suffixes are <SAMP>`.o'</SAMP> and
|
|
<SAMP>`.c'</SAMP> is equivalent to the pattern rule <SAMP>`%.o : %.c'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
A single-suffix rule is defined by a single suffix, which is the source
|
|
suffix. It matches any file name, and the corresponding implicit
|
|
prerequisite name is made by appending the source suffix. A single-suffix
|
|
rule whose source suffix is <SAMP>`.c'</SAMP> is equivalent to the pattern rule
|
|
<SAMP>`% : %.c'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
Suffix rule definitions are recognized by comparing each rule's target
|
|
against a defined list of known suffixes. When <CODE>make</CODE> sees a rule
|
|
whose target is a known suffix, this rule is considered a single-suffix
|
|
rule. When <CODE>make</CODE> sees a rule whose target is two known suffixes
|
|
concatenated, this rule is taken as a double-suffix rule.
|
|
|
|
</P>
|
|
<P>
|
|
For example, <SAMP>`.c'</SAMP> and <SAMP>`.o'</SAMP> are both on the default list of
|
|
known suffixes. Therefore, if you define a rule whose target is
|
|
<SAMP>`.c.o'</SAMP>, <CODE>make</CODE> takes it to be a double-suffix rule with source
|
|
suffix <SAMP>`.c'</SAMP> and target suffix <SAMP>`.o'</SAMP>. Here is the old-fashioned
|
|
way to define the rule for compiling a C source file:
|
|
</P>
|
|
|
|
<PRE>
|
|
.c.o:
|
|
$(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<
|
|
</PRE>
|
|
|
|
<P>
|
|
Suffix rules cannot have any prerequisites of their own. If they have any,
|
|
they are treated as normal files with funny names, not as suffix rules.
|
|
Thus, the rule:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
.c.o: foo.h
|
|
$(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<
|
|
</PRE>
|
|
|
|
<P>
|
|
tells how to make the file <TT>`.c.o'</TT> from the prerequisite file
|
|
<TT>`foo.h'</TT>, and is not at all like the pattern rule:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
%.o: %.c foo.h
|
|
$(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<
|
|
</PRE>
|
|
|
|
<P>
|
|
which tells how to make <SAMP>`.o'</SAMP> files from <SAMP>`.c'</SAMP> files, and makes all
|
|
<SAMP>`.o'</SAMP> files using this pattern rule also depend on <TT>`foo.h'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
Suffix rules with no commands are also meaningless. They do not remove
|
|
previous rules as do pattern rules with no commands (see section <A HREF="make.html#SEC104">Canceling Implicit Rules</A>). They simply enter the suffix or pair of suffixes concatenated as
|
|
a target in the data base.
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX891"></A>
|
|
The known suffixes are simply the names of the prerequisites of the special
|
|
target <CODE>.SUFFIXES</CODE>. You can add your own suffixes by writing a rule
|
|
for <CODE>.SUFFIXES</CODE> that adds more prerequisites, as in:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
.SUFFIXES: .hack .win
|
|
</PRE>
|
|
|
|
<P>
|
|
which adds <SAMP>`.hack'</SAMP> and <SAMP>`.win'</SAMP> to the end of the list of suffixes.
|
|
|
|
</P>
|
|
<P>
|
|
If you wish to eliminate the default known suffixes instead of just adding
|
|
to them, write a rule for <CODE>.SUFFIXES</CODE> with no prerequisites. By
|
|
special dispensation, this eliminates all existing prerequisites of
|
|
<CODE>.SUFFIXES</CODE>. You can then write another rule to add the suffixes you
|
|
want. For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
.SUFFIXES: # Delete the default suffixes
|
|
.SUFFIXES: .c .o .h # Define our suffix list
|
|
</PRE>
|
|
|
|
<P>
|
|
The <SAMP>`-r'</SAMP> or <SAMP>`--no-builtin-rules'</SAMP> flag causes the default
|
|
list of suffixes to be empty.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX892"></A>
|
|
The variable <CODE>SUFFIXES</CODE> is defined to the default list of suffixes
|
|
before <CODE>make</CODE> reads any makefiles. You can change the list of suffixes
|
|
with a rule for the special target <CODE>.SUFFIXES</CODE>, but that does not alter
|
|
this variable.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC107" HREF="make.html#TOC107">Implicit Rule Search Algorithm</A></H2>
|
|
<P>
|
|
<A NAME="IDX893"></A>
|
|
<A NAME="IDX894"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Here is the procedure <CODE>make</CODE> uses for searching for an implicit rule
|
|
for a target <VAR>t</VAR>. This procedure is followed for each double-colon
|
|
rule with no commands, for each target of ordinary rules none of which have
|
|
commands, and for each prerequisite that is not the target of any rule. It
|
|
is also followed recursively for prerequisites that come from implicit
|
|
rules, in the search for a chain of rules.
|
|
|
|
</P>
|
|
<P>
|
|
Suffix rules are not mentioned in this algorithm because suffix rules are
|
|
converted to equivalent pattern rules once the makefiles have been read in.
|
|
|
|
</P>
|
|
<P>
|
|
For an archive member target of the form
|
|
<SAMP>`<VAR>archive</VAR>(<VAR>member</VAR>)'</SAMP>, the following algorithm is run
|
|
twice, first using the entire target name <VAR>t</VAR>, and second using
|
|
<SAMP>`(<VAR>member</VAR>)'</SAMP> as the target <VAR>t</VAR> if the first run found no
|
|
rule.
|
|
</P>
|
|
|
|
<OL>
|
|
<LI>
|
|
|
|
Split <VAR>t</VAR> into a directory part, called <VAR>d</VAR>, and the rest,
|
|
called <VAR>n</VAR>. For example, if <VAR>t</VAR> is <SAMP>`src/foo.o'</SAMP>, then
|
|
<VAR>d</VAR> is <SAMP>`src/'</SAMP> and <VAR>n</VAR> is <SAMP>`foo.o'</SAMP>.
|
|
<LI>
|
|
|
|
Make a list of all the pattern rules one of whose targets matches
|
|
<VAR>t</VAR> or <VAR>n</VAR>. If the target pattern contains a slash, it is
|
|
matched against <VAR>t</VAR>; otherwise, against <VAR>n</VAR>.
|
|
|
|
<LI>
|
|
|
|
If any rule in that list is <EM>not</EM> a match-anything rule, then
|
|
remove all nonterminal match-anything rules from the list.
|
|
|
|
<LI>
|
|
|
|
Remove from the list all rules with no commands.
|
|
|
|
<LI>
|
|
|
|
For each pattern rule in the list:
|
|
|
|
|
|
<OL>
|
|
<LI>
|
|
|
|
Find the stem <VAR>s</VAR>, which is the nonempty part of <VAR>t</VAR> or <VAR>n</VAR>
|
|
matched by the <SAMP>`%'</SAMP> in the target pattern.
|
|
<LI>
|
|
|
|
Compute the prerequisite names by substituting <VAR>s</VAR> for <SAMP>`%'</SAMP>; if
|
|
the target pattern does not contain a slash, append <VAR>d</VAR> to
|
|
the front of each prerequisite name.
|
|
<LI>
|
|
|
|
Test whether all the prerequisites exist or ought to exist. (If a
|
|
file name is mentioned in the makefile as a target or as an explicit
|
|
prerequisite, then we say it ought to exist.)
|
|
|
|
If all prerequisites exist or ought to exist, or there are no prerequisites,
|
|
then this rule applies.
|
|
</OL>
|
|
|
|
<LI>
|
|
|
|
If no pattern rule has been found so far, try harder.
|
|
For each pattern rule in the list:
|
|
|
|
|
|
<OL>
|
|
<LI>
|
|
|
|
If the rule is terminal, ignore it and go on to the next rule.
|
|
|
|
<LI>
|
|
|
|
Compute the prerequisite names as before.
|
|
|
|
<LI>
|
|
|
|
Test whether all the prerequisites exist or ought to exist.
|
|
|
|
<LI>
|
|
|
|
For each prerequisite that does not exist, follow this algorithm
|
|
recursively to see if the prerequisite can be made by an implicit
|
|
rule.
|
|
|
|
<LI>
|
|
|
|
If all prerequisites exist, ought to exist, or can be
|
|
made by implicit rules, then this rule applies.
|
|
</OL>
|
|
|
|
<LI>
|
|
|
|
If no implicit rule applies, the rule for <CODE>.DEFAULT</CODE>, if any,
|
|
applies. In that case, give <VAR>t</VAR> the same commands that
|
|
<CODE>.DEFAULT</CODE> has. Otherwise, there are no commands for <VAR>t</VAR>.
|
|
</OL>
|
|
|
|
<P>
|
|
Once a rule that applies has been found, for each target pattern of the
|
|
rule other than the one that matched <VAR>t</VAR> or <VAR>n</VAR>, the <SAMP>`%'</SAMP> in
|
|
the pattern is replaced with <VAR>s</VAR> and the resultant file name is stored
|
|
until the commands to remake the target file <VAR>t</VAR> are executed. After
|
|
these commands are executed, each of these stored file names are entered
|
|
into the data base and marked as having been updated and having the same
|
|
update status as the file <VAR>t</VAR>.
|
|
|
|
</P>
|
|
<P>
|
|
When the commands of a pattern rule are executed for <VAR>t</VAR>, the automatic
|
|
variables are set corresponding to the target and prerequisites.
|
|
See section <A HREF="make.html#SEC101">Automatic Variables</A>.
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC108" HREF="make.html#TOC108">Using <CODE>make</CODE> to Update Archive Files</A></H1>
|
|
<P>
|
|
<A NAME="IDX895"></A>
|
|
|
|
</P>
|
|
<P>
|
|
<STRONG>Archive files</STRONG> are files containing named subfiles called
|
|
<STRONG>members</STRONG>; they are maintained with the program <CODE>ar</CODE> and their
|
|
main use is as subroutine libraries for linking.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC109" HREF="make.html#TOC109">Archive Members as Targets</A></H2>
|
|
<P>
|
|
<A NAME="IDX896"></A>
|
|
|
|
</P>
|
|
<P>
|
|
An individual member of an archive file can be used as a target or
|
|
prerequisite in <CODE>make</CODE>. You specify the member named <VAR>member</VAR> in
|
|
archive file <VAR>archive</VAR> as follows:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
<VAR>archive</VAR>(<VAR>member</VAR>)
|
|
</PRE>
|
|
|
|
<P>
|
|
This construct is available only in targets and prerequisites, not in
|
|
commands! Most programs that you might use in commands do not support this
|
|
syntax and cannot act directly on archive members. Only <CODE>ar</CODE> and
|
|
other programs specifically designed to operate on archives can do so.
|
|
Therefore, valid commands to update an archive member target probably must
|
|
use <CODE>ar</CODE>. For example, this rule says to create a member
|
|
<TT>`hack.o'</TT> in archive <TT>`foolib'</TT> by copying the file <TT>`hack.o'</TT>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foolib(hack.o) : hack.o
|
|
ar cr foolib hack.o
|
|
</PRE>
|
|
|
|
<P>
|
|
In fact, nearly all archive member targets are updated in just this way
|
|
and there is an implicit rule to do it for you. <STRONG>Note:</STRONG> The
|
|
<SAMP>`c'</SAMP> flag to <CODE>ar</CODE> is required if the archive file does not
|
|
already exist.
|
|
|
|
</P>
|
|
<P>
|
|
To specify several members in the same archive, you can write all the
|
|
member names together between the parentheses. For example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foolib(hack.o kludge.o)
|
|
</PRE>
|
|
|
|
<P>
|
|
is equivalent to:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foolib(hack.o) foolib(kludge.o)
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX897"></A>
|
|
You can also use shell-style wildcards in an archive member reference.
|
|
See section <A HREF="make.html#SEC22">Using Wildcard Characters in File Names</A>. For
|
|
example, <SAMP>`foolib(*.o)'</SAMP> expands to all existing members of the
|
|
<TT>`foolib'</TT> archive whose names end in <SAMP>`.o'</SAMP>; perhaps
|
|
<SAMP>`foolib(hack.o) foolib(kludge.o)'</SAMP>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC110" HREF="make.html#TOC110">Implicit Rule for Archive Member Targets</A></H2>
|
|
|
|
<P>
|
|
Recall that a target that looks like <TT>`<VAR>a</VAR>(<VAR>m</VAR>)'</TT> stands for the
|
|
member named <VAR>m</VAR> in the archive file <VAR>a</VAR>.
|
|
|
|
</P>
|
|
<P>
|
|
When <CODE>make</CODE> looks for an implicit rule for such a target, as a special
|
|
feature it considers implicit rules that match <TT>`(<VAR>m</VAR>)'</TT>, as well as
|
|
those that match the actual target <TT>`<VAR>a</VAR>(<VAR>m</VAR>)'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
This causes one special rule whose target is <TT>`(%)'</TT> to match. This
|
|
rule updates the target <TT>`<VAR>a</VAR>(<VAR>m</VAR>)'</TT> by copying the file <VAR>m</VAR>
|
|
into the archive. For example, it will update the archive member target
|
|
<TT>`foo.a(bar.o)'</TT> by copying the <EM>file</EM> <TT>`bar.o'</TT> into the
|
|
archive <TT>`foo.a'</TT> as a <EM>member</EM> named <TT>`bar.o'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
When this rule is chained with others, the result is very powerful.
|
|
Thus, <SAMP>`make "foo.a(bar.o)"'</SAMP> (the quotes are needed to protect the
|
|
<SAMP>`('</SAMP> and <SAMP>`)'</SAMP> from being interpreted specially by the shell) in
|
|
the presence of a file <TT>`bar.c'</TT> is enough to cause the following
|
|
commands to be run, even without a makefile:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
cc -c bar.c -o bar.o
|
|
ar r foo.a bar.o
|
|
rm -f bar.o
|
|
</PRE>
|
|
|
|
<P>
|
|
Here <CODE>make</CODE> has envisioned the file <TT>`bar.o'</TT> as an intermediate
|
|
file. See section <A HREF="make.html#SEC97">Chains of Implicit Rules</A>.
|
|
|
|
</P>
|
|
<P>
|
|
Implicit rules such as this one are written using the automatic variable
|
|
<SAMP>`$%'</SAMP>. See section <A HREF="make.html#SEC101">Automatic Variables</A>.
|
|
|
|
</P>
|
|
<P>
|
|
An archive member name in an archive cannot contain a directory name, but
|
|
it may be useful in a makefile to pretend that it does. If you write an
|
|
archive member target <TT>`foo.a(dir/file.o)'</TT>, <CODE>make</CODE> will perform
|
|
automatic updating with this command:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
ar r foo.a dir/file.o
|
|
</PRE>
|
|
|
|
<P>
|
|
which has the effect of copying the file <TT>`dir/file.o'</TT> into a member
|
|
named <TT>`file.o'</TT>. In connection with such usage, the automatic variables
|
|
<CODE>%D</CODE> and <CODE>%F</CODE> may be useful.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC111" HREF="make.html#TOC111">Updating Archive Symbol Directories</A></H3>
|
|
<P>
|
|
<A NAME="IDX898"></A>
|
|
<A NAME="IDX899"></A>
|
|
<A NAME="IDX900"></A>
|
|
<A NAME="IDX901"></A>
|
|
<A NAME="IDX902"></A>
|
|
|
|
</P>
|
|
<P>
|
|
An archive file that is used as a library usually contains a special member
|
|
named <TT>`__.SYMDEF'</TT> that contains a directory of the external symbol
|
|
names defined by all the other members. After you update any other
|
|
members, you need to update <TT>`__.SYMDEF'</TT> so that it will summarize the
|
|
other members properly. This is done by running the <CODE>ranlib</CODE> program:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
ranlib <VAR>archivefile</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
Normally you would put this command in the rule for the archive file,
|
|
and make all the members of the archive file prerequisites of that rule.
|
|
For example,
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
libfoo.a: libfoo.a(x.o) libfoo.a(y.o) ...
|
|
ranlib libfoo.a
|
|
</PRE>
|
|
|
|
<P>
|
|
The effect of this is to update archive members <TT>`x.o'</TT>, <TT>`y.o'</TT>,
|
|
etc., and then update the symbol directory member <TT>`__.SYMDEF'</TT> by
|
|
running <CODE>ranlib</CODE>. The rules for updating the members are not shown
|
|
here; most likely you can omit them and use the implicit rule which copies
|
|
files into the archive, as described in the preceding section.
|
|
|
|
</P>
|
|
<P>
|
|
This is not necessary when using the GNU <CODE>ar</CODE> program, which
|
|
updates the <TT>`__.SYMDEF'</TT> member automatically.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC112" HREF="make.html#TOC112">Dangers When Using Archives</A></H2>
|
|
<P>
|
|
<A NAME="IDX903"></A>
|
|
<A NAME="IDX904"></A>
|
|
<A NAME="IDX905"></A>
|
|
<A NAME="IDX906"></A>
|
|
|
|
</P>
|
|
<P>
|
|
It is important to be careful when using parallel execution (the
|
|
<CODE>-j</CODE> switch; see section <A HREF="make.html#SEC47">Parallel Execution</A>) and archives.
|
|
If multiple <CODE>ar</CODE> commands run at the same time on the same archive
|
|
file, they will not know about each other and can corrupt the file.
|
|
|
|
</P>
|
|
<P>
|
|
Possibly a future version of <CODE>make</CODE> will provide a mechanism to
|
|
circumvent this problem by serializing all commands that operate on the
|
|
same archive file. But for the time being, you must either write your
|
|
makefiles to avoid this problem in some other way, or not use <CODE>-j</CODE>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC113" HREF="make.html#TOC113">Suffix Rules for Archive Files</A></H2>
|
|
<P>
|
|
<A NAME="IDX907"></A>
|
|
<A NAME="IDX908"></A>
|
|
<A NAME="IDX909"></A>
|
|
<A NAME="IDX910"></A>
|
|
|
|
</P>
|
|
<P>
|
|
You can write a special kind of suffix rule for dealing with archive
|
|
files. See section <A HREF="make.html#SEC106">Old-Fashioned Suffix Rules</A>, for a full explanation of suffix rules.
|
|
Archive suffix rules are obsolete in GNU <CODE>make</CODE>, because pattern
|
|
rules for archives are a more general mechanism (see section <A HREF="make.html#SEC110">Implicit Rule for Archive Member Targets</A>). But they are retained for compatibility with other
|
|
<CODE>make</CODE>s.
|
|
|
|
</P>
|
|
<P>
|
|
To write a suffix rule for archives, you simply write a suffix rule
|
|
using the target suffix <SAMP>`.a'</SAMP> (the usual suffix for archive files).
|
|
For example, here is the old-fashioned suffix rule to update a library
|
|
archive from C source files:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
.c.a:
|
|
$(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $*.o
|
|
$(AR) r $@ $*.o
|
|
$(RM) $*.o
|
|
</PRE>
|
|
|
|
<P>
|
|
This works just as if you had written the pattern rule:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
(%.o): %.c
|
|
$(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $*.o
|
|
$(AR) r $@ $*.o
|
|
$(RM) $*.o
|
|
</PRE>
|
|
|
|
<P>
|
|
In fact, this is just what <CODE>make</CODE> does when it sees a suffix rule
|
|
with <SAMP>`.a'</SAMP> as the target suffix. Any double-suffix rule
|
|
<SAMP>`.<VAR>x</VAR>.a'</SAMP> is converted to a pattern rule with the target
|
|
pattern <SAMP>`(%.o)'</SAMP> and a prerequisite pattern of <SAMP>`%.<VAR>x</VAR>'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
Since you might want to use <SAMP>`.a'</SAMP> as the suffix for some other kind
|
|
of file, <CODE>make</CODE> also converts archive suffix rules to pattern rules
|
|
in the normal way (see section <A HREF="make.html#SEC106">Old-Fashioned Suffix Rules</A>). Thus a double-suffix rule
|
|
<SAMP>`.<VAR>x</VAR>.a'</SAMP> produces two pattern rules: <SAMP>`(%.o):
|
|
%.<VAR>x</VAR>'</SAMP> and <SAMP>`%.a: %.<VAR>x</VAR>'</SAMP>.
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC114" HREF="make.html#TOC114">Features of GNU <CODE>make</CODE></A></H1>
|
|
<P>
|
|
<A NAME="IDX911"></A>
|
|
<A NAME="IDX912"></A>
|
|
<A NAME="IDX913"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Here is a summary of the features of GNU <CODE>make</CODE>, for comparison
|
|
with and credit to other versions of <CODE>make</CODE>. We consider the
|
|
features of <CODE>make</CODE> in 4.2 BSD systems as a baseline. If you are
|
|
concerned with writing portable makefiles, you should not use the
|
|
features of <CODE>make</CODE> listed here, nor the ones in section <A HREF="make.html#SEC115">Incompatibilities and Missing Features</A>.
|
|
|
|
</P>
|
|
<P>
|
|
Many features come from the version of <CODE>make</CODE> in System V.
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
The <CODE>VPATH</CODE> variable and its special meaning.
|
|
See section <A HREF="make.html#SEC26">Searching Directories for Prerequisites</A>.
|
|
This feature exists in System V <CODE>make</CODE>, but is undocumented.
|
|
It is documented in 4.3 BSD <CODE>make</CODE> (which says it mimics System V's
|
|
<CODE>VPATH</CODE> feature).
|
|
<LI>
|
|
|
|
Included makefiles. See section <A HREF="make.html#SEC15">Including Other Makefiles</A>.
|
|
Allowing multiple files to be included with a single directive is a GNU
|
|
extension.
|
|
|
|
<LI>
|
|
|
|
Variables are read from and communicated via the environment.
|
|
See section <A HREF="make.html#SEC68">Variables from the Environment</A>.
|
|
|
|
<LI>
|
|
|
|
Options passed through the variable <CODE>MAKEFLAGS</CODE> to recursive
|
|
invocations of <CODE>make</CODE>.
|
|
See section <A HREF="make.html#SEC53">Communicating Options to a Sub-<CODE>make</CODE></A>.
|
|
|
|
<LI>
|
|
|
|
The automatic variable <CODE>$%</CODE> is set to the member name
|
|
in an archive reference. See section <A HREF="make.html#SEC101">Automatic Variables</A>.
|
|
|
|
<LI>
|
|
|
|
The automatic variables <CODE>$@</CODE>, <CODE>$*</CODE>, <CODE>$<</CODE>, <CODE>$%</CODE>,
|
|
and <CODE>$?</CODE> have corresponding forms like <CODE>$(@F)</CODE> and
|
|
<CODE>$(@D)</CODE>. We have generalized this to <CODE>$^</CODE> as an obvious
|
|
extension. See section <A HREF="make.html#SEC101">Automatic Variables</A>.
|
|
<LI>
|
|
|
|
Substitution variable references.
|
|
See section <A HREF="make.html#SEC58">Basics of Variable References</A>.
|
|
|
|
<LI>
|
|
|
|
The command-line options <SAMP>`-b'</SAMP> and <SAMP>`-m'</SAMP>, accepted and
|
|
ignored. In System V <CODE>make</CODE>, these options actually do something.
|
|
|
|
<LI>
|
|
|
|
Execution of recursive commands to run <CODE>make</CODE> via the variable
|
|
<CODE>MAKE</CODE> even if <SAMP>`-n'</SAMP>, <SAMP>`-q'</SAMP> or <SAMP>`-t'</SAMP> is specified.
|
|
See section <A HREF="make.html#SEC50">Recursive Use of <CODE>make</CODE></A>.
|
|
|
|
<LI>
|
|
|
|
Support for suffix <SAMP>`.a'</SAMP> in suffix rules. See section <A HREF="make.html#SEC113">Suffix Rules for Archive Files</A>. This feature is obsolete in GNU <CODE>make</CODE>, because the
|
|
general feature of rule chaining (see section <A HREF="make.html#SEC97">Chains of Implicit Rules</A>) allows one pattern rule for installing members in an
|
|
archive (see section <A HREF="make.html#SEC110">Implicit Rule for Archive Member Targets</A>) to be sufficient.
|
|
|
|
<LI>
|
|
|
|
The arrangement of lines and backslash-newline combinations in
|
|
commands is retained when the commands are printed, so they appear as
|
|
they do in the makefile, except for the stripping of initial
|
|
whitespace.
|
|
</UL>
|
|
|
|
<P>
|
|
The following features were inspired by various other versions of
|
|
<CODE>make</CODE>. In some cases it is unclear exactly which versions inspired
|
|
which others.
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
Pattern rules using <SAMP>`%'</SAMP>.
|
|
This has been implemented in several versions of <CODE>make</CODE>.
|
|
We're not sure who invented it first, but it's been spread around a bit.
|
|
See section <A HREF="make.html#SEC98">Defining and Redefining Pattern Rules</A>.
|
|
<LI>
|
|
|
|
Rule chaining and implicit intermediate files.
|
|
This was implemented by Stu Feldman in his version of <CODE>make</CODE>
|
|
for AT&T Eighth Edition Research Unix, and later by Andrew Hume of
|
|
AT&T Bell Labs in his <CODE>mk</CODE> program (where he terms it
|
|
"transitive closure"). We do not really know if
|
|
we got this from either of them or thought it up ourselves at the
|
|
same time. See section <A HREF="make.html#SEC97">Chains of Implicit Rules</A>.
|
|
|
|
<LI>
|
|
|
|
The automatic variable <CODE>$^</CODE> containing a list of all prerequisites
|
|
of the current target. We did not invent this, but we have no idea who
|
|
did. See section <A HREF="make.html#SEC101">Automatic Variables</A>. The automatic variable
|
|
<CODE>$+</CODE> is a simple extension of <CODE>$^</CODE>.
|
|
|
|
<LI>
|
|
|
|
The "what if" flag (<SAMP>`-W'</SAMP> in GNU <CODE>make</CODE>) was (as far as we know)
|
|
invented by Andrew Hume in <CODE>mk</CODE>.
|
|
See section <A HREF="make.html#SEC88">Instead of Executing the Commands</A>.
|
|
|
|
<LI>
|
|
|
|
The concept of doing several things at once (parallelism) exists in
|
|
many incarnations of <CODE>make</CODE> and similar programs, though not in the
|
|
System V or BSD implementations. See section <A HREF="make.html#SEC46">Command Execution</A>.
|
|
|
|
<LI>
|
|
|
|
Modified variable references using pattern substitution come from
|
|
SunOS 4. See section <A HREF="make.html#SEC58">Basics of Variable References</A>.
|
|
This functionality was provided in GNU <CODE>make</CODE> by the
|
|
<CODE>patsubst</CODE> function before the alternate syntax was implemented
|
|
for compatibility with SunOS 4. It is not altogether clear who
|
|
inspired whom, since GNU <CODE>make</CODE> had <CODE>patsubst</CODE> before SunOS
|
|
4 was released.
|
|
<LI>
|
|
|
|
The special significance of <SAMP>`+'</SAMP> characters preceding command lines
|
|
(see section <A HREF="make.html#SEC88">Instead of Executing the Commands</A>) is
|
|
mandated by
|
|
<CITE>IEEE Standard 1003.2-1992</CITE> (POSIX.2).
|
|
|
|
<LI>
|
|
|
|
The <SAMP>`+='</SAMP> syntax to append to the value of a variable comes from SunOS
|
|
4 <CODE>make</CODE>. See section <A HREF="make.html#SEC65">Appending More Text to Variables</A>.
|
|
|
|
<LI>
|
|
|
|
The syntax <SAMP>`<VAR>archive</VAR>(<VAR>mem1</VAR> <VAR>mem2</VAR>...)'</SAMP> to list
|
|
multiple members in a single archive file comes from SunOS 4 <CODE>make</CODE>.
|
|
See section <A HREF="make.html#SEC109">Archive Members as Targets</A>.
|
|
|
|
<LI>
|
|
|
|
The <CODE>-include</CODE> directive to include makefiles with no error for a
|
|
nonexistent file comes from SunOS 4 <CODE>make</CODE>. (But note that SunOS 4
|
|
<CODE>make</CODE> does not allow multiple makefiles to be specified in one
|
|
<CODE>-include</CODE> directive.) The same feature appears with the name
|
|
<CODE>sinclude</CODE> in SGI <CODE>make</CODE> and perhaps others.
|
|
</UL>
|
|
|
|
<P>
|
|
The remaining features are inventions new in GNU <CODE>make</CODE>:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
Use the <SAMP>`-v'</SAMP> or <SAMP>`--version'</SAMP> option to print version and
|
|
copyright information.
|
|
|
|
<LI>
|
|
|
|
Use the <SAMP>`-h'</SAMP> or <SAMP>`--help'</SAMP> option to summarize the options to
|
|
<CODE>make</CODE>.
|
|
|
|
<LI>
|
|
|
|
Simply-expanded variables. See section <A HREF="make.html#SEC59">The Two Flavors of Variables</A>.
|
|
|
|
<LI>
|
|
|
|
Pass command-line variable assignments automatically through the
|
|
variable <CODE>MAKE</CODE> to recursive <CODE>make</CODE> invocations.
|
|
See section <A HREF="make.html#SEC50">Recursive Use of <CODE>make</CODE></A>.
|
|
|
|
<LI>
|
|
|
|
Use the <SAMP>`-C'</SAMP> or <SAMP>`--directory'</SAMP> command option to change
|
|
directory. See section <A HREF="make.html#SEC92">Summary of Options</A>.
|
|
|
|
<LI>
|
|
|
|
Make verbatim variable definitions with <CODE>define</CODE>.
|
|
See section <A HREF="make.html#SEC67">Defining Variables Verbatim</A>.
|
|
|
|
<LI>
|
|
|
|
Declare phony targets with the special target <CODE>.PHONY</CODE>.
|
|
|
|
Andrew Hume of AT&T Bell Labs implemented a similar feature with a
|
|
different syntax in his <CODE>mk</CODE> program. This seems to be a case of
|
|
parallel discovery. See section <A HREF="make.html#SEC33">Phony Targets</A>.
|
|
|
|
<LI>
|
|
|
|
Manipulate text by calling functions.
|
|
See section <A HREF="make.html#SEC75">Functions for Transforming Text</A>.
|
|
|
|
<LI>
|
|
|
|
Use the <SAMP>`-o'</SAMP> or <SAMP>`--old-file'</SAMP>
|
|
option to pretend a file's modification-time is old.
|
|
See section <A HREF="make.html#SEC89">Avoiding Recompilation of Some Files</A>.
|
|
|
|
<LI>
|
|
|
|
Conditional execution.
|
|
|
|
This feature has been implemented numerous times in various versions
|
|
of <CODE>make</CODE>; it seems a natural extension derived from the features
|
|
of the C preprocessor and similar macro languages and is not a
|
|
revolutionary concept. See section <A HREF="make.html#SEC71">Conditional Parts of Makefiles</A>.
|
|
|
|
<LI>
|
|
|
|
Specify a search path for included makefiles.
|
|
See section <A HREF="make.html#SEC15">Including Other Makefiles</A>.
|
|
|
|
<LI>
|
|
|
|
Specify extra makefiles to read with an environment variable.
|
|
See section <A HREF="make.html#SEC16">The Variable <CODE>MAKEFILES</CODE></A>.
|
|
|
|
<LI>
|
|
|
|
Strip leading sequences of <SAMP>`./'</SAMP> from file names, so that
|
|
<TT>`./<VAR>file</VAR>'</TT> and <TT>`<VAR>file</VAR>'</TT> are considered to be the
|
|
same file.
|
|
<LI>
|
|
|
|
Use a special search method for library prerequisites written in the
|
|
form <SAMP>`-l<VAR>name</VAR>'</SAMP>.
|
|
See section <A HREF="make.html#SEC32">Directory Search for Link Libraries</A>.
|
|
|
|
<LI>
|
|
|
|
Allow suffixes for suffix rules
|
|
(see section <A HREF="make.html#SEC106">Old-Fashioned Suffix Rules</A>) to contain any
|
|
characters. In other versions of <CODE>make</CODE>, they must begin with
|
|
<SAMP>`.'</SAMP> and not contain any <SAMP>`/'</SAMP> characters.
|
|
|
|
<LI>
|
|
|
|
Keep track of the current level of <CODE>make</CODE> recursion using the
|
|
variable <CODE>MAKELEVEL</CODE>. See section <A HREF="make.html#SEC50">Recursive Use of <CODE>make</CODE></A>.
|
|
|
|
<LI>
|
|
|
|
Provide any goals given on the command line in the variable
|
|
<CODE>MAKECMDGOALS</CODE>. See section <A HREF="make.html#SEC87">Arguments to Specify the Goals</A>.
|
|
|
|
<LI>
|
|
|
|
Specify static pattern rules. See section <A HREF="make.html#SEC39">Static Pattern Rules</A>.
|
|
|
|
<LI>
|
|
|
|
Provide selective <CODE>vpath</CODE> search.
|
|
See section <A HREF="make.html#SEC26">Searching Directories for Prerequisites</A>.
|
|
|
|
<LI>
|
|
|
|
Provide computed variable references.
|
|
See section <A HREF="make.html#SEC58">Basics of Variable References</A>.
|
|
|
|
<LI>
|
|
|
|
Update makefiles. See section <A HREF="make.html#SEC17">How Makefiles Are Remade</A>.
|
|
System V <CODE>make</CODE> has a very, very limited form of this
|
|
functionality in that it will check out SCCS files for makefiles.
|
|
|
|
<LI>
|
|
|
|
Various new built-in implicit rules.
|
|
See section <A HREF="make.html#SEC95">Catalogue of Implicit Rules</A>.
|
|
|
|
<LI>
|
|
|
|
The built-in variable <SAMP>`MAKE_VERSION'</SAMP> gives the version number of
|
|
<CODE>make</CODE>.
|
|
</UL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC115" HREF="make.html#TOC115">Incompatibilities and Missing Features</A></H1>
|
|
<P>
|
|
<A NAME="IDX914"></A>
|
|
<A NAME="IDX915"></A>
|
|
<A NAME="IDX916"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>make</CODE> programs in various other systems support a few features
|
|
that are not implemented in GNU <CODE>make</CODE>. The POSIX.2 standard
|
|
(<CITE>IEEE Standard 1003.2-1992</CITE>) which specifies <CODE>make</CODE> does not
|
|
require any of these features.
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
A target of the form <SAMP>`<VAR>file</VAR>((<VAR>entry</VAR>))'</SAMP> stands for a member
|
|
of archive file <VAR>file</VAR>. The member is chosen, not by name, but by
|
|
being an object file which defines the linker symbol <VAR>entry</VAR>.
|
|
This feature was not put into GNU <CODE>make</CODE> because of the
|
|
nonmodularity of putting knowledge into <CODE>make</CODE> of the internal
|
|
format of archive file symbol tables.
|
|
See section <A HREF="make.html#SEC111">Updating Archive Symbol Directories</A>.
|
|
|
|
<LI>
|
|
|
|
Suffixes (used in suffix rules) that end with the character <SAMP>`~'</SAMP>
|
|
have a special meaning to System V <CODE>make</CODE>;
|
|
they refer to the SCCS file that corresponds
|
|
to the file one would get without the <SAMP>`~'</SAMP>. For example, the
|
|
suffix rule <SAMP>`.c~.o'</SAMP> would make the file <TT>`<VAR>n</VAR>.o'</TT> from
|
|
the SCCS file <TT>`s.<VAR>n</VAR>.c'</TT>. For complete coverage, a whole
|
|
series of such suffix rules is required.
|
|
See section <A HREF="make.html#SEC106">Old-Fashioned Suffix Rules</A>.
|
|
|
|
In GNU <CODE>make</CODE>, this entire series of cases is handled by two
|
|
pattern rules for extraction from SCCS, in combination with the
|
|
general feature of rule chaining.
|
|
See section <A HREF="make.html#SEC97">Chains of Implicit Rules</A>.
|
|
|
|
<LI>
|
|
|
|
In System V <CODE>make</CODE>, the string <SAMP>`$$@'</SAMP> has the strange meaning
|
|
that, in the prerequisites of a rule with multiple targets, it stands
|
|
for the particular target that is being processed.
|
|
|
|
This is not defined in GNU <CODE>make</CODE> because <SAMP>`$$'</SAMP> should always
|
|
stand for an ordinary <SAMP>`$'</SAMP>.
|
|
|
|
It is possible to get portions of this functionality through the use of
|
|
static pattern rules (see section <A HREF="make.html#SEC39">Static Pattern Rules</A>).
|
|
The System V <CODE>make</CODE> rule:
|
|
|
|
|
|
<PRE>
|
|
$(targets): $$@.o lib.a
|
|
</PRE>
|
|
|
|
can be replaced with the GNU <CODE>make</CODE> static pattern rule:
|
|
|
|
|
|
<PRE>
|
|
$(targets): %: %.o lib.a
|
|
</PRE>
|
|
|
|
<LI>
|
|
|
|
In System V and 4.3 BSD <CODE>make</CODE>, files found by <CODE>VPATH</CODE> search
|
|
(see section <A HREF="make.html#SEC26">Searching Directories for Prerequisites</A>) have their names changed inside command
|
|
strings. We feel it is much cleaner to always use automatic variables
|
|
and thus make this feature obsolete.
|
|
<LI>
|
|
|
|
In some Unix <CODE>make</CODE>s, the automatic variable <CODE>$*</CODE> appearing in
|
|
the prerequisites of a rule has the amazingly strange "feature" of
|
|
expanding to the full name of the <EM>target of that rule</EM>. We cannot
|
|
imagine what went on in the minds of Unix <CODE>make</CODE> developers to do
|
|
this; it is utterly inconsistent with the normal definition of <CODE>$*</CODE>.
|
|
<A NAME="IDX917"></A>
|
|
|
|
<LI>
|
|
|
|
In some Unix <CODE>make</CODE>s, implicit rule search
|
|
(see section <A HREF="make.html#SEC93">Using Implicit Rules</A>) is apparently done for
|
|
<EM>all</EM> targets, not just those without commands. This means you can
|
|
do:
|
|
|
|
<PRE>
|
|
foo.o:
|
|
cc -c foo.c
|
|
</PRE>
|
|
|
|
and Unix <CODE>make</CODE> will intuit that <TT>`foo.o'</TT> depends on
|
|
<TT>`foo.c'</TT>.
|
|
We feel that such usage is broken. The prerequisite properties of
|
|
<CODE>make</CODE> are well-defined (for GNU <CODE>make</CODE>, at least),
|
|
and doing such a thing simply does not fit the model.
|
|
<LI>
|
|
|
|
GNU <CODE>make</CODE> does not include any built-in implicit rules for
|
|
compiling or preprocessing EFL programs. If we hear of anyone who is
|
|
using EFL, we will gladly add them.
|
|
|
|
<LI>
|
|
|
|
It appears that in SVR4 <CODE>make</CODE>, a suffix rule can be specified with
|
|
no commands, and it is treated as if it had empty commands
|
|
(see section <A HREF="make.html#SEC56">Using Empty Commands</A>). For example:
|
|
|
|
|
|
<PRE>
|
|
.c.a:
|
|
</PRE>
|
|
|
|
will override the built-in <TT>`.c.a'</TT> suffix rule.
|
|
|
|
We feel that it is cleaner for a rule without commands to always simply
|
|
add to the prerequisite list for the target. The above example can be
|
|
easily rewritten to get the desired behavior in GNU <CODE>make</CODE>:
|
|
|
|
|
|
<PRE>
|
|
.c.a: ;
|
|
</PRE>
|
|
|
|
<LI>
|
|
|
|
Some versions of <CODE>make</CODE> invoke the shell with the <SAMP>`-e'</SAMP> flag,
|
|
except under <SAMP>`-k'</SAMP> (see section <A HREF="make.html#SEC91">Testing the Compilation of a Program</A>). The <SAMP>`-e'</SAMP> flag tells the shell to exit as soon as any
|
|
program it runs returns a nonzero status. We feel it is cleaner to
|
|
write each shell command line to stand on its own and not require this
|
|
special treatment.
|
|
</UL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC116" HREF="make.html#TOC116">Makefile Conventions</A></H1>
|
|
<P>
|
|
<A NAME="IDX918"></A>
|
|
<A NAME="IDX919"></A>
|
|
<A NAME="IDX920"></A>
|
|
|
|
</P>
|
|
<P>
|
|
This
|
|
chapter
|
|
describes conventions for writing the Makefiles for GNU programs.
|
|
Using Automake will help you write a Makefile that follows these
|
|
conventions.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC117" HREF="make.html#TOC117">General Conventions for Makefiles</A></H2>
|
|
|
|
<P>
|
|
Every Makefile should contain this line:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
SHELL = /bin/sh
|
|
</PRE>
|
|
|
|
<P>
|
|
to avoid trouble on systems where the <CODE>SHELL</CODE> variable might be
|
|
inherited from the environment. (This is never a problem with GNU
|
|
<CODE>make</CODE>.)
|
|
|
|
</P>
|
|
<P>
|
|
Different <CODE>make</CODE> programs have incompatible suffix lists and
|
|
implicit rules, and this sometimes creates confusion or misbehavior. So
|
|
it is a good idea to set the suffix list explicitly using only the
|
|
suffixes you need in the particular Makefile, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
.SUFFIXES:
|
|
.SUFFIXES: .c .o
|
|
</PRE>
|
|
|
|
<P>
|
|
The first line clears out the suffix list, the second introduces all
|
|
suffixes which may be subject to implicit rules in this Makefile.
|
|
|
|
</P>
|
|
<P>
|
|
Don't assume that <TT>`.'</TT> is in the path for command execution. When
|
|
you need to run programs that are a part of your package during the
|
|
make, please make sure that it uses <TT>`./'</TT> if the program is built as
|
|
part of the make or <TT>`$(srcdir)/'</TT> if the file is an unchanging part
|
|
of the source code. Without one of these prefixes, the current search
|
|
path is used.
|
|
|
|
</P>
|
|
<P>
|
|
The distinction between <TT>`./'</TT> (the <STRONG>build directory</STRONG>) and
|
|
<TT>`$(srcdir)/'</TT> (the <STRONG>source directory</STRONG>) is important because
|
|
users can build in a separate directory using the <SAMP>`--srcdir'</SAMP> option
|
|
to <TT>`configure'</TT>. A rule of the form:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo.1 : foo.man sedscript
|
|
sed -e sedscript foo.man > foo.1
|
|
</PRE>
|
|
|
|
<P>
|
|
will fail when the build directory is not the source directory, because
|
|
<TT>`foo.man'</TT> and <TT>`sedscript'</TT> are in the the source directory.
|
|
|
|
</P>
|
|
<P>
|
|
When using GNU <CODE>make</CODE>, relying on <SAMP>`VPATH'</SAMP> to find the source
|
|
file will work in the case where there is a single dependency file,
|
|
since the <CODE>make</CODE> automatic variable <SAMP>`$<'</SAMP> will represent the
|
|
source file wherever it is. (Many versions of <CODE>make</CODE> set <SAMP>`$<'</SAMP>
|
|
only in implicit rules.) A Makefile target like
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo.o : bar.c
|
|
$(CC) -I. -I$(srcdir) $(CFLAGS) -c bar.c -o foo.o
|
|
</PRE>
|
|
|
|
<P>
|
|
should instead be written as
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo.o : bar.c
|
|
$(CC) -I. -I$(srcdir) $(CFLAGS) -c $< -o $@
|
|
</PRE>
|
|
|
|
<P>
|
|
in order to allow <SAMP>`VPATH'</SAMP> to work correctly. When the target has
|
|
multiple dependencies, using an explicit <SAMP>`$(srcdir)'</SAMP> is the easiest
|
|
way to make the rule work well. For example, the target above for
|
|
<TT>`foo.1'</TT> is best written as:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
foo.1 : foo.man sedscript
|
|
sed -e $(srcdir)/sedscript $(srcdir)/foo.man > $@
|
|
</PRE>
|
|
|
|
<P>
|
|
GNU distributions usually contain some files which are not source
|
|
files--for example, Info files, and the output from Autoconf, Automake,
|
|
Bison or Flex. Since these files normally appear in the source
|
|
directory, they should always appear in the source directory, not in the
|
|
build directory. So Makefile rules to update them should put the
|
|
updated files in the source directory.
|
|
|
|
</P>
|
|
<P>
|
|
However, if a file does not appear in the distribution, then the
|
|
Makefile should not put it in the source directory, because building a
|
|
program in ordinary circumstances should not modify the source directory
|
|
in any way.
|
|
|
|
</P>
|
|
<P>
|
|
Try to make the build and installation targets, at least (and all their
|
|
subtargets) work correctly with a parallel <CODE>make</CODE>.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC118" HREF="make.html#TOC118">Utilities in Makefiles</A></H2>
|
|
|
|
<P>
|
|
Write the Makefile commands (and any shell scripts, such as
|
|
<CODE>configure</CODE>) to run in <CODE>sh</CODE>, not in <CODE>csh</CODE>. Don't use any
|
|
special features of <CODE>ksh</CODE> or <CODE>bash</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>configure</CODE> script and the Makefile rules for building and
|
|
installation should not use any utilities directly except these:
|
|
|
|
</P>
|
|
|
|
|
|
<PRE>
|
|
cat cmp cp diff echo egrep expr false grep install-info
|
|
ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch true
|
|
</PRE>
|
|
|
|
<P>
|
|
The compression program <CODE>gzip</CODE> can be used in the <CODE>dist</CODE> rule.
|
|
|
|
</P>
|
|
<P>
|
|
Stick to the generally supported options for these programs. For
|
|
example, don't use <SAMP>`mkdir -p'</SAMP>, convenient as it may be, because
|
|
most systems don't support it.
|
|
|
|
</P>
|
|
<P>
|
|
It is a good idea to avoid creating symbolic links in makefiles, since a
|
|
few systems don't support them.
|
|
|
|
</P>
|
|
<P>
|
|
The Makefile rules for building and installation can also use compilers
|
|
and related programs, but should do so via <CODE>make</CODE> variables so that the
|
|
user can substitute alternatives. Here are some of the programs we
|
|
mean:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
ar bison cc flex install ld ldconfig lex
|
|
make makeinfo ranlib texi2dvi yacc
|
|
</PRE>
|
|
|
|
<P>
|
|
Use the following <CODE>make</CODE> variables to run those programs:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$(AR) $(BISON) $(CC) $(FLEX) $(INSTALL) $(LD) $(LDCONFIG) $(LEX)
|
|
$(MAKE) $(MAKEINFO) $(RANLIB) $(TEXI2DVI) $(YACC)
|
|
</PRE>
|
|
|
|
<P>
|
|
When you use <CODE>ranlib</CODE> or <CODE>ldconfig</CODE>, you should make sure
|
|
nothing bad happens if the system does not have the program in question.
|
|
Arrange to ignore an error from that command, and print a message before
|
|
the command to tell the user that failure of this command does not mean
|
|
a problem. (The Autoconf <SAMP>`AC_PROG_RANLIB'</SAMP> macro can help with
|
|
this.)
|
|
|
|
</P>
|
|
<P>
|
|
If you use symbolic links, you should implement a fallback for systems
|
|
that don't have symbolic links.
|
|
|
|
</P>
|
|
<P>
|
|
Additional utilities that can be used via Make variables are:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
chgrp chmod chown mknod
|
|
</PRE>
|
|
|
|
<P>
|
|
It is ok to use other utilities in Makefile portions (or scripts)
|
|
intended only for particular systems where you know those utilities
|
|
exist.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC119" HREF="make.html#TOC119">Variables for Specifying Commands</A></H2>
|
|
|
|
<P>
|
|
Makefiles should provide variables for overriding certain commands, options,
|
|
and so on.
|
|
|
|
</P>
|
|
<P>
|
|
In particular, you should run most utility programs via variables.
|
|
Thus, if you use Bison, have a variable named <CODE>BISON</CODE> whose default
|
|
value is set with <SAMP>`BISON = bison'</SAMP>, and refer to it with
|
|
<CODE>$(BISON)</CODE> whenever you need to use Bison.
|
|
|
|
</P>
|
|
<P>
|
|
File management utilities such as <CODE>ln</CODE>, <CODE>rm</CODE>, <CODE>mv</CODE>, and
|
|
so on, need not be referred to through variables in this way, since users
|
|
don't need to replace them with other programs.
|
|
|
|
</P>
|
|
<P>
|
|
Each program-name variable should come with an options variable that is
|
|
used to supply options to the program. Append <SAMP>`FLAGS'</SAMP> to the
|
|
program-name variable name to get the options variable name--for
|
|
example, <CODE>BISONFLAGS</CODE>. (The names <CODE>CFLAGS</CODE> for the C
|
|
compiler, <CODE>YFLAGS</CODE> for yacc, and <CODE>LFLAGS</CODE> for lex, are
|
|
exceptions to this rule, but we keep them because they are standard.)
|
|
Use <CODE>CPPFLAGS</CODE> in any compilation command that runs the
|
|
preprocessor, and use <CODE>LDFLAGS</CODE> in any compilation command that
|
|
does linking as well as in any direct use of <CODE>ld</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
If there are C compiler options that <EM>must</EM> be used for proper
|
|
compilation of certain files, do not include them in <CODE>CFLAGS</CODE>.
|
|
Users expect to be able to specify <CODE>CFLAGS</CODE> freely themselves.
|
|
Instead, arrange to pass the necessary options to the C compiler
|
|
independently of <CODE>CFLAGS</CODE>, by writing them explicitly in the
|
|
compilation commands or by defining an implicit rule, like this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
CFLAGS = -g
|
|
ALL_CFLAGS = -I. $(CFLAGS)
|
|
.c.o:
|
|
$(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<
|
|
</PRE>
|
|
|
|
<P>
|
|
Do include the <SAMP>`-g'</SAMP> option in <CODE>CFLAGS</CODE>, because that is not
|
|
<EM>required</EM> for proper compilation. You can consider it a default
|
|
that is only recommended. If the package is set up so that it is
|
|
compiled with GCC by default, then you might as well include <SAMP>`-O'</SAMP>
|
|
in the default value of <CODE>CFLAGS</CODE> as well.
|
|
|
|
</P>
|
|
<P>
|
|
Put <CODE>CFLAGS</CODE> last in the compilation command, after other variables
|
|
containing compiler options, so the user can use <CODE>CFLAGS</CODE> to
|
|
override the others.
|
|
|
|
</P>
|
|
<P>
|
|
<CODE>CFLAGS</CODE> should be used in every invocation of the C compiler,
|
|
both those which do compilation and those which do linking.
|
|
|
|
</P>
|
|
<P>
|
|
Every Makefile should define the variable <CODE>INSTALL</CODE>, which is the
|
|
basic command for installing a file into the system.
|
|
|
|
</P>
|
|
<P>
|
|
Every Makefile should also define the variables <CODE>INSTALL_PROGRAM</CODE>
|
|
and <CODE>INSTALL_DATA</CODE>. (The default for each of these should be
|
|
<CODE>$(INSTALL)</CODE>.) Then it should use those variables as the commands
|
|
for actual installation, for executables and nonexecutables
|
|
respectively. Use these variables as follows:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$(INSTALL_PROGRAM) foo $(bindir)/foo
|
|
$(INSTALL_DATA) libfoo.a $(libdir)/libfoo.a
|
|
</PRE>
|
|
|
|
<P>
|
|
Optionally, you may prepend the value of <CODE>DESTDIR</CODE> to the target
|
|
filename. Doing this allows the installer to create a snapshot of the
|
|
installation to be copied onto the real target filesystem later. Do not
|
|
set the value of <CODE>DESTDIR</CODE> in your Makefile, and do not include it
|
|
in any installed files. With support for <CODE>DESTDIR</CODE>, the above
|
|
examples become:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$(INSTALL_PROGRAM) foo $(DESTDIR)$(bindir)/foo
|
|
$(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.a
|
|
</PRE>
|
|
|
|
<P>
|
|
Always use a file name, not a directory name, as the second argument of
|
|
the installation commands. Use a separate command for each file to be
|
|
installed.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC120" HREF="make.html#TOC120">Variables for Installation Directories</A></H2>
|
|
|
|
<P>
|
|
Installation directories should always be named by variables, so it is
|
|
easy to install in a nonstandard place. The standard names for these
|
|
variables are described below. They are based on a standard filesystem
|
|
layout; variants of it are used in SVR4, 4.4BSD, Linux, Ultrix v4, and
|
|
other modern operating systems.
|
|
|
|
</P>
|
|
<P>
|
|
These two variables set the root for the installation. All the other
|
|
installation directories should be subdirectories of one of these two,
|
|
and nothing should be directly installed into these two directories.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><SAMP>`prefix'</SAMP>
|
|
<DD>
|
|
A prefix used in constructing the default values of the variables listed
|
|
below. The default value of <CODE>prefix</CODE> should be <TT>`/usr/local'</TT>.
|
|
When building the complete GNU system, the prefix will be empty and
|
|
<TT>`/usr'</TT> will be a symbolic link to <TT>`/'</TT>.
|
|
(If you are using Autoconf, write it as <SAMP>`@prefix@'</SAMP>.)
|
|
|
|
Running <SAMP>`make install'</SAMP> with a different value of <CODE>prefix</CODE>
|
|
from the one used to build the program should <VAR>not</VAR> recompile
|
|
the program.
|
|
|
|
<DT><SAMP>`exec_prefix'</SAMP>
|
|
<DD>
|
|
A prefix used in constructing the default values of some of the
|
|
variables listed below. The default value of <CODE>exec_prefix</CODE> should
|
|
be <CODE>$(prefix)</CODE>.
|
|
(If you are using Autoconf, write it as <SAMP>`@exec_prefix@'</SAMP>.)
|
|
|
|
Generally, <CODE>$(exec_prefix)</CODE> is used for directories that contain
|
|
machine-specific files (such as executables and subroutine libraries),
|
|
while <CODE>$(prefix)</CODE> is used directly for other directories.
|
|
|
|
Running <SAMP>`make install'</SAMP> with a different value of <CODE>exec_prefix</CODE>
|
|
from the one used to build the program should <VAR>not</VAR> recompile the
|
|
program.
|
|
</DL>
|
|
|
|
<P>
|
|
Executable programs are installed in one of the following directories.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><SAMP>`bindir'</SAMP>
|
|
<DD>
|
|
The directory for installing executable programs that users can run.
|
|
This should normally be <TT>`/usr/local/bin'</TT>, but write it as
|
|
<TT>`$(exec_prefix)/bin'</TT>.
|
|
(If you are using Autoconf, write it as <SAMP>`@bindir@'</SAMP>.)
|
|
|
|
<DT><SAMP>`sbindir'</SAMP>
|
|
<DD>
|
|
The directory for installing executable programs that can be run from
|
|
the shell, but are only generally useful to system administrators. This
|
|
should normally be <TT>`/usr/local/sbin'</TT>, but write it as
|
|
<TT>`$(exec_prefix)/sbin'</TT>.
|
|
(If you are using Autoconf, write it as <SAMP>`@sbindir@'</SAMP>.)
|
|
|
|
<DT><SAMP>`libexecdir'</SAMP>
|
|
<DD>
|
|
The directory for installing executable programs to be run by other
|
|
programs rather than by users. This directory should normally be
|
|
<TT>`/usr/local/libexec'</TT>, but write it as <TT>`$(exec_prefix)/libexec'</TT>.
|
|
(If you are using Autoconf, write it as <SAMP>`@libexecdir@'</SAMP>.)
|
|
</DL>
|
|
|
|
<P>
|
|
Data files used by the program during its execution are divided into
|
|
categories in two ways.
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
Some files are normally modified by programs; others are never normally
|
|
modified (though users may edit some of these).
|
|
|
|
<LI>
|
|
|
|
Some files are architecture-independent and can be shared by all
|
|
machines at a site; some are architecture-dependent and can be shared
|
|
only by machines of the same kind and operating system; others may never
|
|
be shared between two machines.
|
|
</UL>
|
|
|
|
<P>
|
|
This makes for six different possibilities. However, we want to
|
|
discourage the use of architecture-dependent files, aside from object
|
|
files and libraries. It is much cleaner to make other data files
|
|
architecture-independent, and it is generally not hard.
|
|
|
|
</P>
|
|
<P>
|
|
Therefore, here are the variables Makefiles should use to specify
|
|
directories:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><SAMP>`datadir'</SAMP>
|
|
<DD>
|
|
The directory for installing read-only architecture independent data
|
|
files. This should normally be <TT>`/usr/local/share'</TT>, but write it as
|
|
<TT>`$(prefix)/share'</TT>.
|
|
(If you are using Autoconf, write it as <SAMP>`@datadir@'</SAMP>.)
|
|
As a special exception, see <TT>`$(infodir)'</TT>
|
|
and <TT>`$(includedir)'</TT> below.
|
|
|
|
<DT><SAMP>`sysconfdir'</SAMP>
|
|
<DD>
|
|
The directory for installing read-only data files that pertain to a
|
|
single machine--that is to say, files for configuring a host. Mailer
|
|
and network configuration files, <TT>`/etc/passwd'</TT>, and so forth belong
|
|
here. All the files in this directory should be ordinary ASCII text
|
|
files. This directory should normally be <TT>`/usr/local/etc'</TT>, but
|
|
write it as <TT>`$(prefix)/etc'</TT>.
|
|
(If you are using Autoconf, write it as <SAMP>`@sysconfdir@'</SAMP>.)
|
|
|
|
Do not install executables here in this directory (they probably belong
|
|
in <TT>`$(libexecdir)'</TT> or <TT>`$(sbindir)'</TT>). Also do not install
|
|
files that are modified in the normal course of their use (programs
|
|
whose purpose is to change the configuration of the system excluded).
|
|
Those probably belong in <TT>`$(localstatedir)'</TT>.
|
|
|
|
<DT><SAMP>`sharedstatedir'</SAMP>
|
|
<DD>
|
|
The directory for installing architecture-independent data files which
|
|
the programs modify while they run. This should normally be
|
|
<TT>`/usr/local/com'</TT>, but write it as <TT>`$(prefix)/com'</TT>.
|
|
(If you are using Autoconf, write it as <SAMP>`@sharedstatedir@'</SAMP>.)
|
|
|
|
<DT><SAMP>`localstatedir'</SAMP>
|
|
<DD>
|
|
The directory for installing data files which the programs modify while
|
|
they run, and that pertain to one specific machine. Users should never
|
|
need to modify files in this directory to configure the package's
|
|
operation; put such configuration information in separate files that go
|
|
in <TT>`$(datadir)'</TT> or <TT>`$(sysconfdir)'</TT>. <TT>`$(localstatedir)'</TT>
|
|
should normally be <TT>`/usr/local/var'</TT>, but write it as
|
|
<TT>`$(prefix)/var'</TT>.
|
|
(If you are using Autoconf, write it as <SAMP>`@localstatedir@'</SAMP>.)
|
|
|
|
<DT><SAMP>`libdir'</SAMP>
|
|
<DD>
|
|
The directory for object files and libraries of object code. Do not
|
|
install executables here, they probably ought to go in <TT>`$(libexecdir)'</TT>
|
|
instead. The value of <CODE>libdir</CODE> should normally be
|
|
<TT>`/usr/local/lib'</TT>, but write it as <TT>`$(exec_prefix)/lib'</TT>.
|
|
(If you are using Autoconf, write it as <SAMP>`@libdir@'</SAMP>.)
|
|
|
|
<DT><SAMP>`infodir'</SAMP>
|
|
<DD>
|
|
The directory for installing the Info files for this package. By
|
|
default, it should be <TT>`/usr/local/info'</TT>, but it should be written
|
|
as <TT>`$(prefix)/info'</TT>.
|
|
(If you are using Autoconf, write it as <SAMP>`@infodir@'</SAMP>.)
|
|
|
|
<DT><SAMP>`lispdir'</SAMP>
|
|
<DD>
|
|
The directory for installing any Emacs Lisp files in this package. By
|
|
default, it should be <TT>`/usr/local/share/emacs/site-lisp'</TT>, but it
|
|
should be written as <TT>`$(prefix)/share/emacs/site-lisp'</TT>.
|
|
|
|
If you are using Autoconf, write the default as <SAMP>`@lispdir@'</SAMP>.
|
|
In order to make <SAMP>`@lispdir@'</SAMP> work, you need the following lines
|
|
in your <TT>`configure.in'</TT> file:
|
|
|
|
|
|
<PRE>
|
|
lispdir='${datadir}/emacs/site-lisp'
|
|
AC_SUBST(lispdir)
|
|
</PRE>
|
|
|
|
<DT><SAMP>`includedir'</SAMP>
|
|
<DD>
|
|
The directory for installing header files to be included by user
|
|
programs with the C <SAMP>`#include'</SAMP> preprocessor directive. This
|
|
should normally be <TT>`/usr/local/include'</TT>, but write it as
|
|
<TT>`$(prefix)/include'</TT>.
|
|
(If you are using Autoconf, write it as <SAMP>`@includedir@'</SAMP>.)
|
|
|
|
Most compilers other than GCC do not look for header files in directory
|
|
<TT>`/usr/local/include'</TT>. So installing the header files this way is
|
|
only useful with GCC. Sometimes this is not a problem because some
|
|
libraries are only really intended to work with GCC. But some libraries
|
|
are intended to work with other compilers. They should install their
|
|
header files in two places, one specified by <CODE>includedir</CODE> and one
|
|
specified by <CODE>oldincludedir</CODE>.
|
|
|
|
<DT><SAMP>`oldincludedir'</SAMP>
|
|
<DD>
|
|
The directory for installing <SAMP>`#include'</SAMP> header files for use with
|
|
compilers other than GCC. This should normally be <TT>`/usr/include'</TT>.
|
|
(If you are using Autoconf, you can write it as <SAMP>`@oldincludedir@'</SAMP>.)
|
|
|
|
The Makefile commands should check whether the value of
|
|
<CODE>oldincludedir</CODE> is empty. If it is, they should not try to use
|
|
it; they should cancel the second installation of the header files.
|
|
|
|
A package should not replace an existing header in this directory unless
|
|
the header came from the same package. Thus, if your Foo package
|
|
provides a header file <TT>`foo.h'</TT>, then it should install the header
|
|
file in the <CODE>oldincludedir</CODE> directory if either (1) there is no
|
|
<TT>`foo.h'</TT> there or (2) the <TT>`foo.h'</TT> that exists came from the Foo
|
|
package.
|
|
|
|
To tell whether <TT>`foo.h'</TT> came from the Foo package, put a magic
|
|
string in the file--part of a comment--and <CODE>grep</CODE> for that string.
|
|
</DL>
|
|
|
|
<P>
|
|
Unix-style man pages are installed in one of the following:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><SAMP>`mandir'</SAMP>
|
|
<DD>
|
|
The top-level directory for installing the man pages (if any) for this
|
|
package. It will normally be <TT>`/usr/local/man'</TT>, but you should
|
|
write it as <TT>`$(prefix)/man'</TT>.
|
|
(If you are using Autoconf, write it as <SAMP>`@mandir@'</SAMP>.)
|
|
|
|
<DT><SAMP>`man1dir'</SAMP>
|
|
<DD>
|
|
The directory for installing section 1 man pages. Write it as
|
|
<TT>`$(mandir)/man1'</TT>.
|
|
<DT><SAMP>`man2dir'</SAMP>
|
|
<DD>
|
|
The directory for installing section 2 man pages. Write it as
|
|
<TT>`$(mandir)/man2'</TT>
|
|
<DT><SAMP>`...'</SAMP>
|
|
<DD>
|
|
<STRONG>Don't make the primary documentation for any GNU software be a
|
|
man page. Write a manual in Texinfo instead. Man pages are just for
|
|
the sake of people running GNU software on Unix, which is a secondary
|
|
application only.</STRONG>
|
|
|
|
<DT><SAMP>`manext'</SAMP>
|
|
<DD>
|
|
The file name extension for the installed man page. This should contain
|
|
a period followed by the appropriate digit; it should normally be <SAMP>`.1'</SAMP>.
|
|
|
|
<DT><SAMP>`man1ext'</SAMP>
|
|
<DD>
|
|
The file name extension for installed section 1 man pages.
|
|
<DT><SAMP>`man2ext'</SAMP>
|
|
<DD>
|
|
The file name extension for installed section 2 man pages.
|
|
<DT><SAMP>`...'</SAMP>
|
|
<DD>
|
|
Use these names instead of <SAMP>`manext'</SAMP> if the package needs to install man
|
|
pages in more than one section of the manual.
|
|
</DL>
|
|
|
|
<P>
|
|
And finally, you should set the following variable:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><SAMP>`srcdir'</SAMP>
|
|
<DD>
|
|
The directory for the sources being compiled. The value of this
|
|
variable is normally inserted by the <CODE>configure</CODE> shell script.
|
|
(If you are using Autconf, use <SAMP>`srcdir = @srcdir@'</SAMP>.)
|
|
</DL>
|
|
|
|
<P>
|
|
For example:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
# Common prefix for installation directories.
|
|
# NOTE: This directory must exist when you start the install.
|
|
prefix = /usr/local
|
|
exec_prefix = $(prefix)
|
|
# Where to put the executable for the command `gcc'.
|
|
bindir = $(exec_prefix)/bin
|
|
# Where to put the directories used by the compiler.
|
|
libexecdir = $(exec_prefix)/libexec
|
|
# Where to put the Info files.
|
|
infodir = $(prefix)/info
|
|
</PRE>
|
|
|
|
<P>
|
|
If your program installs a large number of files into one of the
|
|
standard user-specified directories, it might be useful to group them
|
|
into a subdirectory particular to that program. If you do this, you
|
|
should write the <CODE>install</CODE> rule to create these subdirectories.
|
|
|
|
</P>
|
|
<P>
|
|
Do not expect the user to include the subdirectory name in the value of
|
|
any of the variables listed above. The idea of having a uniform set of
|
|
variable names for installation directories is to enable the user to
|
|
specify the exact same values for several different GNU packages. In
|
|
order for this to be useful, all the packages must be designed so that
|
|
they will work sensibly when the user does so.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC121" HREF="make.html#TOC121">Standard Targets for Users</A></H2>
|
|
|
|
<P>
|
|
All GNU programs should have the following targets in their Makefiles:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><SAMP>`all'</SAMP>
|
|
<DD>
|
|
Compile the entire program. This should be the default target. This
|
|
target need not rebuild any documentation files; Info files should
|
|
normally be included in the distribution, and DVI files should be made
|
|
only when explicitly asked for.
|
|
|
|
By default, the Make rules should compile and link with <SAMP>`-g'</SAMP>, so
|
|
that executable programs have debugging symbols. Users who don't mind
|
|
being helpless can strip the executables later if they wish.
|
|
|
|
<DT><SAMP>`install'</SAMP>
|
|
<DD>
|
|
Compile the program and copy the executables, libraries, and so on to
|
|
the file names where they should reside for actual use. If there is a
|
|
simple test to verify that a program is properly installed, this target
|
|
should run that test.
|
|
|
|
Do not strip executables when installing them. Devil-may-care users can
|
|
use the <CODE>install-strip</CODE> target to do that.
|
|
|
|
If possible, write the <CODE>install</CODE> target rule so that it does not
|
|
modify anything in the directory where the program was built, provided
|
|
<SAMP>`make all'</SAMP> has just been done. This is convenient for building the
|
|
program under one user name and installing it under another.
|
|
|
|
The commands should create all the directories in which files are to be
|
|
installed, if they don't already exist. This includes the directories
|
|
specified as the values of the variables <CODE>prefix</CODE> and
|
|
<CODE>exec_prefix</CODE>, as well as all subdirectories that are needed.
|
|
One way to do this is by means of an <CODE>installdirs</CODE> target
|
|
as described below.
|
|
|
|
Use <SAMP>`-'</SAMP> before any command for installing a man page, so that
|
|
<CODE>make</CODE> will ignore any errors. This is in case there are systems
|
|
that don't have the Unix man page documentation system installed.
|
|
|
|
The way to install Info files is to copy them into <TT>`$(infodir)'</TT>
|
|
with <CODE>$(INSTALL_DATA)</CODE> (see section <A HREF="make.html#SEC119">Variables for Specifying Commands</A>), and then run
|
|
the <CODE>install-info</CODE> program if it is present. <CODE>install-info</CODE>
|
|
is a program that edits the Info <TT>`dir'</TT> file to add or update the
|
|
menu entry for the given Info file; it is part of the Texinfo package.
|
|
Here is a sample rule to install an Info file:
|
|
|
|
|
|
<PRE>
|
|
$(DESTDIR)$(infodir)/foo.info: foo.info
|
|
$(POST_INSTALL)
|
|
# There may be a newer info file in . than in srcdir.
|
|
-if test -f foo.info; then d=.; \
|
|
else d=$(srcdir); fi; \
|
|
$(INSTALL_DATA) $$d/foo.info $(DESTDIR)$@; \
|
|
# Run install-info only if it exists.
|
|
# Use `if' instead of just prepending `-' to the
|
|
# line so we notice real errors from install-info.
|
|
# We use `$(SHELL) -c' because some shells do not
|
|
# fail gracefully when there is an unknown command.
|
|
if $(SHELL) -c 'install-info --version' \
|
|
>/dev/null 2>&1; then \
|
|
install-info --dir-file=$(DESTDIR)$(infodir)/dir \
|
|
$(DESTDIR)$(infodir)/foo.info; \
|
|
else true; fi
|
|
</PRE>
|
|
|
|
When writing the <CODE>install</CODE> target, you must classify all the
|
|
commands into three categories: normal ones, <STRONG>pre-installation</STRONG>
|
|
commands and <STRONG>post-installation</STRONG> commands. See section <A HREF="make.html#SEC122">Install Command Categories</A>.
|
|
|
|
<DT><SAMP>`uninstall'</SAMP>
|
|
<DD>
|
|
Delete all the installed files--the copies that the <SAMP>`install'</SAMP>
|
|
target creates.
|
|
|
|
This rule should not modify the directories where compilation is done,
|
|
only the directories where files are installed.
|
|
|
|
The uninstallation commands are divided into three categories, just like
|
|
the installation commands. See section <A HREF="make.html#SEC122">Install Command Categories</A>.
|
|
|
|
<DT><SAMP>`install-strip'</SAMP>
|
|
<DD>
|
|
Like <CODE>install</CODE>, but strip the executable files while installing
|
|
them. In many cases, the definition of this target can be very simple:
|
|
|
|
|
|
<PRE>
|
|
install-strip:
|
|
$(MAKE) INSTALL_PROGRAM='$(INSTALL_PROGRAM) -s' \
|
|
install
|
|
</PRE>
|
|
|
|
Normally we do not recommend stripping an executable unless you are sure
|
|
the program has no bugs. However, it can be reasonable to install a
|
|
stripped executable for actual execution while saving the unstripped
|
|
executable elsewhere in case there is a bug.
|
|
|
|
<DT><SAMP>`clean'</SAMP>
|
|
<DD>
|
|
Delete all files from the current directory that are normally created by
|
|
building the program. Don't delete the files that record the
|
|
configuration. Also preserve files that could be made by building, but
|
|
normally aren't because the distribution comes with them.
|
|
|
|
Delete <TT>`.dvi'</TT> files here if they are not part of the distribution.
|
|
|
|
<DT><SAMP>`distclean'</SAMP>
|
|
<DD>
|
|
Delete all files from the current directory that are created by
|
|
configuring or building the program. If you have unpacked the source
|
|
and built the program without creating any other files, <SAMP>`make
|
|
distclean'</SAMP> should leave only the files that were in the distribution.
|
|
|
|
<DT><SAMP>`mostlyclean'</SAMP>
|
|
<DD>
|
|
Like <SAMP>`clean'</SAMP>, but may refrain from deleting a few files that people
|
|
normally don't want to recompile. For example, the <SAMP>`mostlyclean'</SAMP>
|
|
target for GCC does not delete <TT>`libgcc.a'</TT>, because recompiling it
|
|
is rarely necessary and takes a lot of time.
|
|
|
|
<DT><SAMP>`maintainer-clean'</SAMP>
|
|
<DD>
|
|
Delete almost everything from the current directory that can be
|
|
reconstructed with this Makefile. This typically includes everything
|
|
deleted by <CODE>distclean</CODE>, plus more: C source files produced by
|
|
Bison, tags tables, Info files, and so on.
|
|
|
|
The reason we say "almost everything" is that running the command
|
|
<SAMP>`make maintainer-clean'</SAMP> should not delete <TT>`configure'</TT> even if
|
|
<TT>`configure'</TT> can be remade using a rule in the Makefile. More generally,
|
|
<SAMP>`make maintainer-clean'</SAMP> should not delete anything that needs to
|
|
exist in order to run <TT>`configure'</TT> and then begin to build the
|
|
program. This is the only exception; <CODE>maintainer-clean</CODE> should
|
|
delete everything else that can be rebuilt.
|
|
|
|
The <SAMP>`maintainer-clean'</SAMP> target is intended to be used by a maintainer of
|
|
the package, not by ordinary users. You may need special tools to
|
|
reconstruct some of the files that <SAMP>`make maintainer-clean'</SAMP> deletes.
|
|
Since these files are normally included in the distribution, we don't
|
|
take care to make them easy to reconstruct. If you find you need to
|
|
unpack the full distribution again, don't blame us.
|
|
|
|
To help make users aware of this, the commands for the special
|
|
<CODE>maintainer-clean</CODE> target should start with these two:
|
|
|
|
|
|
<PRE>
|
|
@echo 'This command is intended for maintainers to use; it'
|
|
@echo 'deletes files that may need special tools to rebuild.'
|
|
</PRE>
|
|
|
|
<DT><SAMP>`TAGS'</SAMP>
|
|
<DD>
|
|
Update a tags table for this program.
|
|
|
|
<DT><SAMP>`info'</SAMP>
|
|
<DD>
|
|
Generate any Info files needed. The best way to write the rules is as
|
|
follows:
|
|
|
|
|
|
<PRE>
|
|
info: foo.info
|
|
|
|
foo.info: foo.texi chap1.texi chap2.texi
|
|
$(MAKEINFO) $(srcdir)/foo.texi
|
|
</PRE>
|
|
|
|
You must define the variable <CODE>MAKEINFO</CODE> in the Makefile. It should
|
|
run the <CODE>makeinfo</CODE> program, which is part of the Texinfo
|
|
distribution.
|
|
|
|
Normally a GNU distribution comes with Info files, and that means the
|
|
Info files are present in the source directory. Therefore, the Make
|
|
rule for an info file should update it in the source directory. When
|
|
users build the package, ordinarily Make will not update the Info files
|
|
because they will already be up to date.
|
|
|
|
<DT><SAMP>`dvi'</SAMP>
|
|
<DD>
|
|
Generate DVI files for all Texinfo documentation.
|
|
For example:
|
|
|
|
|
|
<PRE>
|
|
dvi: foo.dvi
|
|
|
|
foo.dvi: foo.texi chap1.texi chap2.texi
|
|
$(TEXI2DVI) $(srcdir)/foo.texi
|
|
</PRE>
|
|
|
|
You must define the variable <CODE>TEXI2DVI</CODE> in the Makefile. It should
|
|
run the program <CODE>texi2dvi</CODE>, which is part of the Texinfo
|
|
distribution.<A NAME="DOCF3" HREF="make.html#FOOT3">(3)</A> Alternatively,
|
|
write just the dependencies, and allow GNU <CODE>make</CODE> to provide the command.
|
|
|
|
<DT><SAMP>`dist'</SAMP>
|
|
<DD>
|
|
Create a distribution tar file for this program. The tar file should be
|
|
set up so that the file names in the tar file start with a subdirectory
|
|
name which is the name of the package it is a distribution for. This
|
|
name can include the version number.
|
|
|
|
For example, the distribution tar file of GCC version 1.40 unpacks into
|
|
a subdirectory named <TT>`gcc-1.40'</TT>.
|
|
|
|
The easiest way to do this is to create a subdirectory appropriately
|
|
named, use <CODE>ln</CODE> or <CODE>cp</CODE> to install the proper files in it, and
|
|
then <CODE>tar</CODE> that subdirectory.
|
|
|
|
Compress the tar file file with <CODE>gzip</CODE>. For example, the actual
|
|
distribution file for GCC version 1.40 is called <TT>`gcc-1.40.tar.gz'</TT>.
|
|
|
|
The <CODE>dist</CODE> target should explicitly depend on all non-source files
|
|
that are in the distribution, to make sure they are up to date in the
|
|
distribution.
|
|
See section `Making Releases' in <CITE>GNU Coding Standards</CITE>.
|
|
|
|
<DT><SAMP>`check'</SAMP>
|
|
<DD>
|
|
Perform self-tests (if any). The user must build the program before
|
|
running the tests, but need not install the program; you should write
|
|
the self-tests so that they work when the program is built but not
|
|
installed.
|
|
</DL>
|
|
|
|
<P>
|
|
The following targets are suggested as conventional names, for programs
|
|
in which they are useful.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>installcheck</CODE>
|
|
<DD>
|
|
Perform installation tests (if any). The user must build and install
|
|
the program before running the tests. You should not assume that
|
|
<TT>`$(bindir)'</TT> is in the search path.
|
|
|
|
<DT><CODE>installdirs</CODE>
|
|
<DD>
|
|
It's useful to add a target named <SAMP>`installdirs'</SAMP> to create the
|
|
directories where files are installed, and their parent directories.
|
|
There is a script called <TT>`mkinstalldirs'</TT> which is convenient for
|
|
this; you can find it in the Texinfo package.
|
|
You can use a rule like this:
|
|
|
|
|
|
<PRE>
|
|
# Make sure all installation directories (e.g. $(bindir))
|
|
# actually exist by making them if necessary.
|
|
installdirs: mkinstalldirs
|
|
$(srcdir)/mkinstalldirs $(bindir) $(datadir) \
|
|
$(libdir) $(infodir) \
|
|
$(mandir)
|
|
</PRE>
|
|
|
|
This rule should not modify the directories where compilation is done.
|
|
It should do nothing but create installation directories.
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC122" HREF="make.html#TOC122">Install Command Categories</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX921"></A>
|
|
<A NAME="IDX922"></A>
|
|
When writing the <CODE>install</CODE> target, you must classify all the
|
|
commands into three categories: normal ones, <STRONG>pre-installation</STRONG>
|
|
commands and <STRONG>post-installation</STRONG> commands.
|
|
|
|
</P>
|
|
<P>
|
|
Normal commands move files into their proper places, and set their
|
|
modes. They may not alter any files except the ones that come entirely
|
|
from the package they belong to.
|
|
|
|
</P>
|
|
<P>
|
|
Pre-installation and post-installation commands may alter other files;
|
|
in particular, they can edit global configuration files or data bases.
|
|
|
|
</P>
|
|
<P>
|
|
Pre-installation commands are typically executed before the normal
|
|
commands, and post-installation commands are typically run after the
|
|
normal commands.
|
|
|
|
</P>
|
|
<P>
|
|
The most common use for a post-installation command is to run
|
|
<CODE>install-info</CODE>. This cannot be done with a normal command, since
|
|
it alters a file (the Info directory) which does not come entirely and
|
|
solely from the package being installed. It is a post-installation
|
|
command because it needs to be done after the normal command which
|
|
installs the package's Info files.
|
|
|
|
</P>
|
|
<P>
|
|
Most programs don't need any pre-installation commands, but we have the
|
|
feature just in case it is needed.
|
|
|
|
</P>
|
|
<P>
|
|
To classify the commands in the <CODE>install</CODE> rule into these three
|
|
categories, insert <STRONG>category lines</STRONG> among them. A category line
|
|
specifies the category for the commands that follow.
|
|
|
|
</P>
|
|
<P>
|
|
A category line consists of a tab and a reference to a special Make
|
|
variable, plus an optional comment at the end. There are three
|
|
variables you can use, one for each category; the variable name
|
|
specifies the category. Category lines are no-ops in ordinary execution
|
|
because these three Make variables are normally undefined (and you
|
|
<EM>should not</EM> define them in the makefile).
|
|
|
|
</P>
|
|
<P>
|
|
Here are the three possible category lines, each with a comment that
|
|
explains what it means:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$(PRE_INSTALL) # Pre-install commands follow.
|
|
$(POST_INSTALL) # Post-install commands follow.
|
|
$(NORMAL_INSTALL) # Normal commands follow.
|
|
</PRE>
|
|
|
|
<P>
|
|
If you don't use a category line at the beginning of the <CODE>install</CODE>
|
|
rule, all the commands are classified as normal until the first category
|
|
line. If you don't use any category lines, all the commands are
|
|
classified as normal.
|
|
|
|
</P>
|
|
<P>
|
|
These are the category lines for <CODE>uninstall</CODE>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$(PRE_UNINSTALL) # Pre-uninstall commands follow.
|
|
$(POST_UNINSTALL) # Post-uninstall commands follow.
|
|
$(NORMAL_UNINSTALL) # Normal commands follow.
|
|
</PRE>
|
|
|
|
<P>
|
|
Typically, a pre-uninstall command would be used for deleting entries
|
|
from the Info directory.
|
|
|
|
</P>
|
|
<P>
|
|
If the <CODE>install</CODE> or <CODE>uninstall</CODE> target has any dependencies
|
|
which act as subroutines of installation, then you should start
|
|
<EM>each</EM> dependency's commands with a category line, and start the
|
|
main target's commands with a category line also. This way, you can
|
|
ensure that each command is placed in the right category regardless of
|
|
which of the dependencies actually run.
|
|
|
|
</P>
|
|
<P>
|
|
Pre-installation and post-installation commands should not run any
|
|
programs except for these:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
[ basename bash cat chgrp chmod chown cmp cp dd diff echo
|
|
egrep expand expr false fgrep find getopt grep gunzip gzip
|
|
hostname install install-info kill ldconfig ln ls md5sum
|
|
mkdir mkfifo mknod mv printenv pwd rm rmdir sed sort tee
|
|
test touch true uname xargs yes
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX923"></A>
|
|
The reason for distinguishing the commands in this way is for the sake
|
|
of making binary packages. Typically a binary package contains all the
|
|
executables and other files that need to be installed, and has its own
|
|
method of installing them--so it does not need to run the normal
|
|
installation commands. But installing the binary package does need to
|
|
execute the pre-installation and post-installation commands.
|
|
|
|
</P>
|
|
<P>
|
|
Programs to build binary packages work by extracting the
|
|
pre-installation and post-installation commands. Here is one way of
|
|
extracting the pre-installation commands:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
make -n install -o all \
|
|
PRE_INSTALL=pre-install \
|
|
POST_INSTALL=post-install \
|
|
NORMAL_INSTALL=normal-install \
|
|
| gawk -f pre-install.awk
|
|
</PRE>
|
|
|
|
<P>
|
|
where the file <TT>`pre-install.awk'</TT> could contain this:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
$0 ~ /^\t[ \t]*(normal_install|post_install)[ \t]*$/ {on = 0}
|
|
on {print $0}
|
|
$0 ~ /^\t[ \t]*pre_install[ \t]*$/ {on = 1}
|
|
</PRE>
|
|
|
|
<P>
|
|
The resulting file of pre-installation commands is executed as a shell
|
|
script as part of installing the binary package.
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC123" HREF="make.html#TOC123">Quick Reference</A></H1>
|
|
|
|
<P>
|
|
This appendix summarizes the directives, text manipulation functions,
|
|
and special variables which GNU <CODE>make</CODE> understands.
|
|
See section <A HREF="make.html#SEC36">Special Built-in Target Names</A>, section <A HREF="make.html#SEC95">Catalogue of Implicit Rules</A>,
|
|
and section <A HREF="make.html#SEC92">Summary of Options</A>,
|
|
for other summaries.
|
|
|
|
</P>
|
|
<P>
|
|
Here is a summary of the directives GNU <CODE>make</CODE> recognizes:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>define <VAR>variable</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>endef</CODE>
|
|
<DD>
|
|
Define a multi-line, recursively-expanded variable.<BR>
|
|
See section <A HREF="make.html#SEC55">Defining Canned Command Sequences</A>.
|
|
|
|
<DT><CODE>ifdef <VAR>variable</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>ifndef <VAR>variable</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>ifeq (<VAR>a</VAR>,<VAR>b</VAR>)</CODE>
|
|
<DD>
|
|
<DT><CODE>ifeq "<VAR>a</VAR>" "<VAR>b</VAR>"</CODE>
|
|
<DD>
|
|
<DT><CODE>ifeq '<VAR>a</VAR>' '<VAR>b</VAR>'</CODE>
|
|
<DD>
|
|
<DT><CODE>ifneq (<VAR>a</VAR>,<VAR>b</VAR>)</CODE>
|
|
<DD>
|
|
<DT><CODE>ifneq "<VAR>a</VAR>" "<VAR>b</VAR>"</CODE>
|
|
<DD>
|
|
<DT><CODE>ifneq '<VAR>a</VAR>' '<VAR>b</VAR>'</CODE>
|
|
<DD>
|
|
<DT><CODE>else</CODE>
|
|
<DD>
|
|
<DT><CODE>endif</CODE>
|
|
<DD>
|
|
Conditionally evaluate part of the makefile.<BR>
|
|
See section <A HREF="make.html#SEC71">Conditional Parts of Makefiles</A>.
|
|
|
|
<DT><CODE>include <VAR>file</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>-include <VAR>file</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>sinclude <VAR>file</VAR></CODE>
|
|
<DD>
|
|
Include another makefile.<BR>
|
|
See section <A HREF="make.html#SEC15">Including Other Makefiles</A>.
|
|
|
|
<DT><CODE>override <VAR>variable</VAR> = <VAR>value</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>override <VAR>variable</VAR> := <VAR>value</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>override <VAR>variable</VAR> += <VAR>value</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>override <VAR>variable</VAR> ?= <VAR>value</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>override define <VAR>variable</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>endef</CODE>
|
|
<DD>
|
|
Define a variable, overriding any previous definition, even one from
|
|
the command line.<BR>
|
|
See section <A HREF="make.html#SEC66">The <CODE>override</CODE> Directive</A>.
|
|
|
|
<DT><CODE>export</CODE>
|
|
<DD>
|
|
Tell <CODE>make</CODE> to export all variables to child processes by default.<BR>
|
|
See section <A HREF="make.html#SEC52">Communicating Variables to a Sub-<CODE>make</CODE></A>.
|
|
|
|
<DT><CODE>export <VAR>variable</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>export <VAR>variable</VAR> = <VAR>value</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>export <VAR>variable</VAR> := <VAR>value</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>export <VAR>variable</VAR> += <VAR>value</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>export <VAR>variable</VAR> ?= <VAR>value</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>unexport <VAR>variable</VAR></CODE>
|
|
<DD>
|
|
Tell <CODE>make</CODE> whether or not to export a particular variable to child
|
|
processes.<BR>
|
|
See section <A HREF="make.html#SEC52">Communicating Variables to a Sub-<CODE>make</CODE></A>.
|
|
|
|
<DT><CODE>vpath <VAR>pattern</VAR> <VAR>path</VAR></CODE>
|
|
<DD>
|
|
Specify a search path for files matching a <SAMP>`%'</SAMP> pattern.<BR>
|
|
See section <A HREF="make.html#SEC28">The <CODE>vpath</CODE> Directive</A>.
|
|
|
|
<DT><CODE>vpath <VAR>pattern</VAR></CODE>
|
|
<DD>
|
|
Remove all search paths previously specified for <VAR>pattern</VAR>.
|
|
|
|
<DT><CODE>vpath</CODE>
|
|
<DD>
|
|
Remove all search paths previously specified in any <CODE>vpath</CODE>
|
|
directive.
|
|
</DL>
|
|
|
|
<P>
|
|
Here is a summary of the text manipulation functions (see section <A HREF="make.html#SEC75">Functions for Transforming Text</A>):
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>$(subst <VAR>from</VAR>,<VAR>to</VAR>,<VAR>text</VAR>)</CODE>
|
|
<DD>
|
|
Replace <VAR>from</VAR> with <VAR>to</VAR> in <VAR>text</VAR>.<BR>
|
|
See section <A HREF="make.html#SEC77">Functions for String Substitution and Analysis</A>.
|
|
|
|
<DT><CODE>$(patsubst <VAR>pattern</VAR>,<VAR>replacement</VAR>,<VAR>text</VAR>)</CODE>
|
|
<DD>
|
|
Replace words matching <VAR>pattern</VAR> with <VAR>replacement</VAR> in <VAR>text</VAR>.<BR>
|
|
See section <A HREF="make.html#SEC77">Functions for String Substitution and Analysis</A>.
|
|
|
|
<DT><CODE>$(strip <VAR>string</VAR>)</CODE>
|
|
<DD>
|
|
Remove excess whitespace characters from <VAR>string</VAR>.<BR>
|
|
See section <A HREF="make.html#SEC77">Functions for String Substitution and Analysis</A>.
|
|
|
|
<DT><CODE>$(findstring <VAR>find</VAR>,<VAR>text</VAR>)</CODE>
|
|
<DD>
|
|
Locate <VAR>find</VAR> in <VAR>text</VAR>.<BR>
|
|
See section <A HREF="make.html#SEC77">Functions for String Substitution and Analysis</A>.
|
|
|
|
<DT><CODE>$(filter <VAR>pattern</VAR>...,<VAR>text</VAR>)</CODE>
|
|
<DD>
|
|
Select words in <VAR>text</VAR> that match one of the <VAR>pattern</VAR> words.<BR>
|
|
See section <A HREF="make.html#SEC77">Functions for String Substitution and Analysis</A>.
|
|
|
|
<DT><CODE>$(filter-out <VAR>pattern</VAR>...,<VAR>text</VAR>)</CODE>
|
|
<DD>
|
|
Select words in <VAR>text</VAR> that <EM>do not</EM> match any of the <VAR>pattern</VAR> words.<BR>
|
|
See section <A HREF="make.html#SEC77">Functions for String Substitution and Analysis</A>.
|
|
|
|
<DT><CODE>$(sort <VAR>list</VAR>)</CODE>
|
|
<DD>
|
|
Sort the words in <VAR>list</VAR> lexicographically, removing duplicates.<BR>
|
|
See section <A HREF="make.html#SEC77">Functions for String Substitution and Analysis</A>.
|
|
|
|
<DT><CODE>$(dir <VAR>names</VAR>...)</CODE>
|
|
<DD>
|
|
Extract the directory part of each file name.<BR>
|
|
See section <A HREF="make.html#SEC78">Functions for File Names</A>.
|
|
|
|
<DT><CODE>$(notdir <VAR>names</VAR>...)</CODE>
|
|
<DD>
|
|
Extract the non-directory part of each file name.<BR>
|
|
See section <A HREF="make.html#SEC78">Functions for File Names</A>.
|
|
|
|
<DT><CODE>$(suffix <VAR>names</VAR>...)</CODE>
|
|
<DD>
|
|
Extract the suffix (the last <SAMP>`.'</SAMP> and following characters) of each file name.<BR>
|
|
See section <A HREF="make.html#SEC78">Functions for File Names</A>.
|
|
|
|
<DT><CODE>$(basename <VAR>names</VAR>...)</CODE>
|
|
<DD>
|
|
Extract the base name (name without suffix) of each file name.<BR>
|
|
See section <A HREF="make.html#SEC78">Functions for File Names</A>.
|
|
|
|
<DT><CODE>$(addsuffix <VAR>suffix</VAR>,<VAR>names</VAR>...)</CODE>
|
|
<DD>
|
|
Append <VAR>suffix</VAR> to each word in <VAR>names</VAR>.<BR>
|
|
See section <A HREF="make.html#SEC78">Functions for File Names</A>.
|
|
|
|
<DT><CODE>$(addprefix <VAR>prefix</VAR>,<VAR>names</VAR>...)</CODE>
|
|
<DD>
|
|
Prepend <VAR>prefix</VAR> to each word in <VAR>names</VAR>.<BR>
|
|
See section <A HREF="make.html#SEC78">Functions for File Names</A>.
|
|
|
|
<DT><CODE>$(join <VAR>list1</VAR>,<VAR>list2</VAR>)</CODE>
|
|
<DD>
|
|
Join two parallel lists of words.<BR>
|
|
See section <A HREF="make.html#SEC78">Functions for File Names</A>.
|
|
|
|
<DT><CODE>$(word <VAR>n</VAR>,<VAR>text</VAR>)</CODE>
|
|
<DD>
|
|
Extract the <VAR>n</VAR>th word (one-origin) of <VAR>text</VAR>.<BR>
|
|
See section <A HREF="make.html#SEC78">Functions for File Names</A>.
|
|
|
|
<DT><CODE>$(words <VAR>text</VAR>)</CODE>
|
|
<DD>
|
|
Count the number of words in <VAR>text</VAR>.<BR>
|
|
See section <A HREF="make.html#SEC78">Functions for File Names</A>.
|
|
|
|
<DT><CODE>$(wordlist <VAR>s</VAR>,<VAR>e</VAR>,<VAR>text</VAR>)</CODE>
|
|
<DD>
|
|
Returns the list of words in <VAR>text</VAR> from <VAR>s</VAR> to <VAR>e</VAR>.<BR>
|
|
See section <A HREF="make.html#SEC78">Functions for File Names</A>.
|
|
|
|
<DT><CODE>$(firstword <VAR>names</VAR>...)</CODE>
|
|
<DD>
|
|
Extract the first word of <VAR>names</VAR>.<BR>
|
|
See section <A HREF="make.html#SEC78">Functions for File Names</A>.
|
|
|
|
<DT><CODE>$(wildcard <VAR>pattern</VAR>...)</CODE>
|
|
<DD>
|
|
Find file names matching a shell file name pattern (<EM>not</EM> a
|
|
<SAMP>`%'</SAMP> pattern).<BR>
|
|
See section <A HREF="make.html#SEC25">The Function <CODE>wildcard</CODE></A>.
|
|
|
|
<DT><CODE>$(error <VAR>text</VAR>...)</CODE>
|
|
<DD>
|
|
When this function is evaluated, <CODE>make</CODE> generates a fatal error
|
|
with the message <VAR>text</VAR>.<BR>
|
|
See section <A HREF="make.html#SEC84">Functions That Control Make</A>.
|
|
|
|
<DT><CODE>$(warning <VAR>text</VAR>...)</CODE>
|
|
<DD>
|
|
When this function is evaluated, <CODE>make</CODE> generates a warning with
|
|
the message <VAR>text</VAR>.<BR>
|
|
See section <A HREF="make.html#SEC84">Functions That Control Make</A>.
|
|
|
|
<DT><CODE>$(shell <VAR>command</VAR>)</CODE>
|
|
<DD>
|
|
Execute a shell command and return its output.<BR>
|
|
See section <A HREF="make.html#SEC83">The <CODE>shell</CODE> Function</A>.
|
|
|
|
<DT><CODE>$(origin <VAR>variable</VAR>)</CODE>
|
|
<DD>
|
|
Return a string describing how the <CODE>make</CODE> variable <VAR>variable</VAR> was
|
|
defined.<BR>
|
|
See section <A HREF="make.html#SEC82">The <CODE>origin</CODE> Function</A>.
|
|
|
|
<DT><CODE>$(foreach <VAR>var</VAR>,<VAR>words</VAR>,<VAR>text</VAR>)</CODE>
|
|
<DD>
|
|
Evaluate <VAR>text</VAR> with <VAR>var</VAR> bound to each word in <VAR>words</VAR>,
|
|
and concatenate the results.<BR>
|
|
See section <A HREF="make.html#SEC79">The <CODE>foreach</CODE> Function</A>.
|
|
|
|
<DT><CODE>$(call <VAR>var</VAR>,<VAR>param</VAR>,...)</CODE>
|
|
<DD>
|
|
Evaluate the variable <VAR>var</VAR> replacing any references to <CODE>$(1)</CODE>,
|
|
<CODE>$(2)</CODE> with the first, second, etc. <VAR>param</VAR> values.<BR>
|
|
See section <A HREF="make.html#SEC81">The <CODE>call</CODE> Function</A>.
|
|
</DL>
|
|
|
|
<P>
|
|
Here is a summary of the automatic variables.
|
|
See section <A HREF="make.html#SEC101">Automatic Variables</A>,
|
|
for full information.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>$@</CODE>
|
|
<DD>
|
|
The file name of the target.
|
|
|
|
<DT><CODE>$%</CODE>
|
|
<DD>
|
|
The target member name, when the target is an archive member.
|
|
|
|
<DT><CODE>$<</CODE>
|
|
<DD>
|
|
The name of the first prerequisite.
|
|
|
|
<DT><CODE>$?</CODE>
|
|
<DD>
|
|
The names of all the prerequisites that are
|
|
newer than the target, with spaces between them.
|
|
For prerequisites which are archive members, only
|
|
the member named is used (see section <A HREF="make.html#SEC108">Using <CODE>make</CODE> to Update Archive Files</A>).
|
|
|
|
<DT><CODE>$^</CODE>
|
|
<DD>
|
|
<DT><CODE>$+</CODE>
|
|
<DD>
|
|
The names of all the prerequisites, with spaces between them. For
|
|
prerequisites which are archive members, only the member named is used
|
|
(see section <A HREF="make.html#SEC108">Using <CODE>make</CODE> to Update Archive Files</A>). The value of <CODE>$^</CODE> omits duplicate
|
|
prerequisites, while <CODE>$+</CODE> retains them and preserves their order.
|
|
|
|
<DT><CODE>$*</CODE>
|
|
<DD>
|
|
The stem with which an implicit rule matches
|
|
(see section <A HREF="make.html#SEC102">How Patterns Match</A>).
|
|
|
|
<DT><CODE>$(@D)</CODE>
|
|
<DD>
|
|
<DT><CODE>$(@F)</CODE>
|
|
<DD>
|
|
The directory part and the file-within-directory part of <CODE>$@</CODE>.
|
|
|
|
<DT><CODE>$(*D)</CODE>
|
|
<DD>
|
|
<DT><CODE>$(*F)</CODE>
|
|
<DD>
|
|
The directory part and the file-within-directory part of <CODE>$*</CODE>.
|
|
|
|
<DT><CODE>$(%D)</CODE>
|
|
<DD>
|
|
<DT><CODE>$(%F)</CODE>
|
|
<DD>
|
|
The directory part and the file-within-directory part of <CODE>$%</CODE>.
|
|
|
|
<DT><CODE>$(<D)</CODE>
|
|
<DD>
|
|
<DT><CODE>$(<F)</CODE>
|
|
<DD>
|
|
The directory part and the file-within-directory part of <CODE>$<</CODE>.
|
|
|
|
<DT><CODE>$(^D)</CODE>
|
|
<DD>
|
|
<DT><CODE>$(^F)</CODE>
|
|
<DD>
|
|
The directory part and the file-within-directory part of <CODE>$^</CODE>.
|
|
|
|
<DT><CODE>$(+D)</CODE>
|
|
<DD>
|
|
<DT><CODE>$(+F)</CODE>
|
|
<DD>
|
|
The directory part and the file-within-directory part of <CODE>$+</CODE>.
|
|
|
|
<DT><CODE>$(?D)</CODE>
|
|
<DD>
|
|
<DT><CODE>$(?F)</CODE>
|
|
<DD>
|
|
The directory part and the file-within-directory part of <CODE>$?</CODE>.
|
|
</DL>
|
|
|
|
<P>
|
|
These variables are used specially by GNU <CODE>make</CODE>:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>MAKEFILES</CODE>
|
|
<DD>
|
|
Makefiles to be read on every invocation of <CODE>make</CODE>.<BR>
|
|
See section <A HREF="make.html#SEC16">The Variable <CODE>MAKEFILES</CODE></A>.
|
|
|
|
<DT><CODE>VPATH</CODE>
|
|
<DD>
|
|
Directory search path for files not found in the current directory.<BR>
|
|
See section <A HREF="make.html#SEC27"><CODE>VPATH</CODE>: Search Path for All Prerequisites</A>.
|
|
|
|
<DT><CODE>SHELL</CODE>
|
|
<DD>
|
|
The name of the system default command interpreter, usually <TT>`/bin/sh'</TT>.
|
|
You can set <CODE>SHELL</CODE> in the makefile to change the shell used to run
|
|
commands. See section <A HREF="make.html#SEC46">Command Execution</A>.
|
|
|
|
<DT><CODE>MAKESHELL</CODE>
|
|
<DD>
|
|
On MS-DOS only, the name of the command interpreter that is to be used
|
|
by <CODE>make</CODE>. This value takes precedence over the value of
|
|
<CODE>SHELL</CODE>. See section <A HREF="make.html#SEC46">Command Execution</A>.
|
|
|
|
<DT><CODE>MAKE</CODE>
|
|
<DD>
|
|
The name with which <CODE>make</CODE> was invoked.
|
|
Using this variable in commands has special meaning.
|
|
See section <A HREF="make.html#SEC51">How the <CODE>MAKE</CODE> Variable Works</A>.
|
|
|
|
<DT><CODE>MAKELEVEL</CODE>
|
|
<DD>
|
|
The number of levels of recursion (sub-<CODE>make</CODE>s).<BR>
|
|
See section <A HREF="make.html#SEC52">Communicating Variables to a Sub-<CODE>make</CODE></A>.
|
|
|
|
<DT><CODE>MAKEFLAGS</CODE>
|
|
<DD>
|
|
The flags given to <CODE>make</CODE>. You can set this in the environment or
|
|
a makefile to set flags.<BR>
|
|
See section <A HREF="make.html#SEC53">Communicating Options to a Sub-<CODE>make</CODE></A>.
|
|
|
|
It is <EM>never</EM> appropriate to use <CODE>MAKEFLAGS</CODE> directly on a
|
|
command line: its contents may not be quoted correctly for use in the
|
|
shell. Always allow recursive <CODE>make</CODE>'s to obtain these values
|
|
through the environment from its parent.
|
|
|
|
<DT><CODE>MAKECMDGOALS</CODE>
|
|
<DD>
|
|
The targets given to <CODE>make</CODE> on the command line. Setting this
|
|
variable has no effect on the operation of <CODE>make</CODE>.<BR>
|
|
See section <A HREF="make.html#SEC87">Arguments to Specify the Goals</A>.
|
|
|
|
<DT><CODE>CURDIR</CODE>
|
|
<DD>
|
|
Set to the pathname of the current working directory (after all
|
|
<CODE>-C</CODE> options are processed, if any). Setting this variable has no
|
|
effect on the operation of <CODE>make</CODE>.<BR>
|
|
See section <A HREF="make.html#SEC50">Recursive Use of <CODE>make</CODE></A>.
|
|
|
|
<DT><CODE>SUFFIXES</CODE>
|
|
<DD>
|
|
The default list of suffixes before <CODE>make</CODE> reads any makefiles.
|
|
|
|
<DT><CODE>.LIBPATTERNS</CODE>
|
|
<DD>
|
|
Defines the naming of the libraries <CODE>make</CODE> searches for, and their
|
|
order.<BR>
|
|
See section <A HREF="make.html#SEC32">Directory Search for Link Libraries</A>.
|
|
</DL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC124" HREF="make.html#TOC124">Errors Generated by Make</A></H1>
|
|
|
|
<P>
|
|
Here is a list of the more common errors you might see generated by
|
|
<CODE>make</CODE>, and some information about what they mean and how to fix
|
|
them.
|
|
|
|
</P>
|
|
<P>
|
|
Sometimes <CODE>make</CODE> errors are not fatal, especially in the presence
|
|
of a <CODE>-</CODE> prefix on a command script line, or the <CODE>-k</CODE> command
|
|
line option. Errors that are fatal are prefixed with the string
|
|
<CODE>***</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
Error messages are all either prefixed with the name of the program
|
|
(usually <SAMP>`make'</SAMP>), or, if the error is found in a makefile, the name
|
|
of the file and linenumber containing the problem.
|
|
|
|
</P>
|
|
<P>
|
|
In the table below, these common prefixes are left off.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><SAMP>`[<VAR>foo</VAR>] Error <VAR>NN</VAR>'</SAMP>
|
|
<DD>
|
|
<DT><SAMP>`[<VAR>foo</VAR>] <VAR>signal description</VAR>'</SAMP>
|
|
<DD>
|
|
These errors are not really <CODE>make</CODE> errors at all. They mean that a
|
|
program that <CODE>make</CODE> invoked as part of a command script returned a
|
|
non-0 error code (<SAMP>`Error <VAR>NN</VAR>'</SAMP>), which <CODE>make</CODE> interprets
|
|
as failure, or it exited in some other abnormal fashion (with a
|
|
signal of some type). See section <A HREF="make.html#SEC48">Errors in Commands</A>.
|
|
|
|
If no <CODE>***</CODE> is attached to the message, then the subprocess failed
|
|
but the rule in the makefile was prefixed with the <CODE>-</CODE> special
|
|
character, so <CODE>make</CODE> ignored the error.
|
|
|
|
<DT><SAMP>`missing separator. Stop.'</SAMP>
|
|
<DD>
|
|
<DT><SAMP>`missing separator (did you mean TAB instead of 8 spaces?). Stop.'</SAMP>
|
|
<DD>
|
|
This means that <CODE>make</CODE> could not understand much of anything about
|
|
the command line it just read. GNU <CODE>make</CODE> looks for various kinds
|
|
of separators (<CODE>:</CODE>, <CODE>=</CODE>, TAB characters, etc.) to help it
|
|
decide what kind of commandline it's seeing. This means it couldn't
|
|
find a valid one.
|
|
|
|
One of the most common reasons for this message is that you (or perhaps
|
|
your oh-so-helpful editor, as is the case with many MS-Windows editors)
|
|
have attempted to indent your command scripts with spaces instead of a
|
|
TAB character. In this case, <CODE>make</CODE> will use the second form of
|
|
the error above. Remember that every line in the command script must
|
|
begin with a TAB character. Eight spaces do not count. See section <A HREF="make.html#SEC21">Rule Syntax</A>.
|
|
|
|
<DT><SAMP>`commands commence before first target. Stop.'</SAMP>
|
|
<DD>
|
|
<DT><SAMP>`missing rule before commands. Stop.'</SAMP>
|
|
<DD>
|
|
This means the first thing in the makefile seems to be part of a command
|
|
script: it begins with a TAB character and doesn't appear to be a legal
|
|
<CODE>make</CODE> command (such as a variable assignment). Command scripts
|
|
must always be associated with a target.
|
|
|
|
The second form is generated if the line has a semicolon as the first
|
|
non-whitespace character; <CODE>make</CODE> interprets this to mean you left
|
|
out the "target: prerequisite" section of a rule. See section <A HREF="make.html#SEC21">Rule Syntax</A>.
|
|
|
|
<DT><SAMP>`No rule to make target `<VAR>xxx</VAR>'.'</SAMP>
|
|
<DD>
|
|
<DT><SAMP>`No rule to make target `<VAR>xxx</VAR>', needed by `<VAR>yyy</VAR>'.'</SAMP>
|
|
<DD>
|
|
This means that <CODE>make</CODE> decided it needed to build a target, but
|
|
then couldn't find any instructions in the makefile on how to do that,
|
|
either explicit or implicit (including in the default rules database).
|
|
|
|
If you want that file to be built, you will need to add a rule to your
|
|
makefile describing how that target can be built. Other possible
|
|
sources of this problem are typos in the makefile (if that filename is
|
|
wrong) or a corrupted source tree (if that file is not supposed to be
|
|
built, but rather only a prerequisite).
|
|
|
|
<DT><SAMP>`No targets specified and no makefile found. Stop.'</SAMP>
|
|
<DD>
|
|
<DT><SAMP>`No targets. Stop.'</SAMP>
|
|
<DD>
|
|
The former means that you didn't provide any targets to be built on the
|
|
command line, and <CODE>make</CODE> couldn't find any makefiles to read in.
|
|
The latter means that some makefile was found, but it didn't contain any
|
|
default target and none was given on the command line. GNU <CODE>make</CODE>
|
|
has nothing to do in these situations.
|
|
See section <A HREF="make.html#SEC86">Arguments to Specify the Makefile</A>.
|
|
<DT><SAMP>`Makefile `<VAR>xxx</VAR>' was not found.'</SAMP>
|
|
<DD>
|
|
<DT><SAMP>`Included makefile `<VAR>xxx</VAR>' was not found.'</SAMP>
|
|
<DD>
|
|
A makefile specified on the command line (first form) or included
|
|
(second form) was not found.
|
|
|
|
<DT><SAMP>`warning: overriding commands for target `<VAR>xxx</VAR>''</SAMP>
|
|
<DD>
|
|
<DT><SAMP>`warning: ignoring old commands for target `<VAR>xxx</VAR>''</SAMP>
|
|
<DD>
|
|
GNU <CODE>make</CODE> allows commands to be specified only once per target
|
|
(except for double-colon rules). If you give commands for a target
|
|
which already has been defined to have commands, this warning is issued
|
|
and the second set of commands will overwrite the first set.
|
|
See section <A HREF="make.html#SEC38">Multiple Rules for One Target</A>.
|
|
|
|
<DT><SAMP>`Circular <VAR>xxx</VAR> <- <VAR>yyy</VAR> dependency dropped.'</SAMP>
|
|
<DD>
|
|
This means that <CODE>make</CODE> detected a loop in the dependency graph:
|
|
after tracing the prerequisite <VAR>yyy</VAR> of target <VAR>xxx</VAR>, and its
|
|
prerequisites, etc., one of them depended on <VAR>xxx</VAR> again.
|
|
|
|
<DT><SAMP>`Recursive variable `<VAR>xxx</VAR>' references itself (eventually). Stop.'</SAMP>
|
|
<DD>
|
|
This means you've defined a normal (recursive) <CODE>make</CODE> variable
|
|
<VAR>xxx</VAR> that, when it's expanded, will refer to itself (<VAR>xxx</VAR>).
|
|
This is not allowed; either use simply-expanded variables (<CODE>:=</CODE>) or
|
|
use the append operator (<CODE>+=</CODE>). See section <A HREF="make.html#SEC57">How to Use Variables</A>.
|
|
|
|
<DT><SAMP>`Unterminated variable reference. Stop.'</SAMP>
|
|
<DD>
|
|
This means you forgot to provide the proper closing parenthesis
|
|
or brace in your variable or function reference.
|
|
|
|
<DT><SAMP>`insufficient arguments to function `<VAR>xxx</VAR>'. Stop.'</SAMP>
|
|
<DD>
|
|
This means you haven't provided the requisite number of arguments for
|
|
this function. See the documentation of the function for a description
|
|
of its arguments. See section <A HREF="make.html#SEC75">Functions for Transforming Text</A>.
|
|
|
|
<DT><SAMP>`missing target pattern. Stop.'</SAMP>
|
|
<DD>
|
|
<DT><SAMP>`multiple target patterns. Stop.'</SAMP>
|
|
<DD>
|
|
<DT><SAMP>`target pattern contains no `%'. Stop.'</SAMP>
|
|
<DD>
|
|
These are generated for malformed static pattern rules. The first means
|
|
there's no pattern in the target section of the rule, the second means
|
|
there are multiple patterns in the target section, and the third means
|
|
the target doesn't contain a pattern character (<CODE>%</CODE>). See section <A HREF="make.html#SEC40">Syntax of Static Pattern Rules</A>.
|
|
|
|
<DT><SAMP>`warning: -jN forced in submake: disabling jobserver mode.'</SAMP>
|
|
<DD>
|
|
This warning and the next are generated if <CODE>make</CODE> detects error
|
|
conditions related to parallel processing on systems where
|
|
sub-<CODE>make</CODE>s can communicate (see section <A HREF="make.html#SEC53">Communicating Options to a Sub-<CODE>make</CODE></A>). This warning is
|
|
generated if a recursive invocation of a <CODE>make</CODE> process is forced
|
|
to have <SAMP>`-j<VAR>N</VAR>'</SAMP> in its argument list (where <VAR>N</VAR> is greater
|
|
than one). This could happen, for example, if you set the <CODE>MAKE</CODE>
|
|
environment variable to <SAMP>`make -j2'</SAMP>. In this case, the
|
|
sub-<CODE>make</CODE> doesn't communicate with other <CODE>make</CODE> processes and
|
|
will simply pretend it has two jobs of its own.
|
|
|
|
<DT><SAMP>`warning: jobserver unavailable: using -j1. Add `+' to parent make rule.'</SAMP>
|
|
<DD>
|
|
In order for <CODE>make</CODE> processes to communicate, the parent will pass
|
|
information to the child. Since this could result in problems if the
|
|
child process isn't actually a <CODE>make</CODE>, the parent will only do this
|
|
if it thinks the child is a <CODE>make</CODE>. The parent uses the normal
|
|
algorithms to determine this (see section <A HREF="make.html#SEC51">How the <CODE>MAKE</CODE> Variable Works</A>). If the makefile is constructed such that the parent
|
|
doesn't know the child is a <CODE>make</CODE> process, then the child will
|
|
receive only part of the information necessary. In this case, the child
|
|
will generate this warning message and proceed with its build in a
|
|
sequential manner.
|
|
|
|
</DL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC125" HREF="make.html#TOC125">Complex Makefile Example</A></H1>
|
|
|
|
<P>
|
|
Here is the makefile for the GNU <CODE>tar</CODE> program. This is a
|
|
moderately complex makefile.
|
|
|
|
</P>
|
|
<P>
|
|
Because it is the first target, the default goal is <SAMP>`all'</SAMP>. An
|
|
interesting feature of this makefile is that <TT>`testpad.h'</TT> is a
|
|
source file automatically created by the <CODE>testpad</CODE> program,
|
|
itself compiled from <TT>`testpad.c'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
If you type <SAMP>`make'</SAMP> or <SAMP>`make all'</SAMP>, then <CODE>make</CODE> creates
|
|
the <TT>`tar'</TT> executable, the <TT>`rmt'</TT> daemon that provides
|
|
remote tape access, and the <TT>`tar.info'</TT> Info file.
|
|
|
|
</P>
|
|
<P>
|
|
If you type <SAMP>`make install'</SAMP>, then <CODE>make</CODE> not only creates
|
|
<TT>`tar'</TT>, <TT>`rmt'</TT>, and <TT>`tar.info'</TT>, but also installs
|
|
them.
|
|
|
|
</P>
|
|
<P>
|
|
If you type <SAMP>`make clean'</SAMP>, then <CODE>make</CODE> removes the <SAMP>`.o'</SAMP>
|
|
files, and the <TT>`tar'</TT>, <TT>`rmt'</TT>, <TT>`testpad'</TT>,
|
|
<TT>`testpad.h'</TT>, and <TT>`core'</TT> files.
|
|
|
|
</P>
|
|
<P>
|
|
If you type <SAMP>`make distclean'</SAMP>, then <CODE>make</CODE> not only removes
|
|
the same files as does <SAMP>`make clean'</SAMP> but also the
|
|
<TT>`TAGS'</TT>, <TT>`Makefile'</TT>, and <TT>`config.status'</TT> files.
|
|
(Although it is not evident, this makefile (and
|
|
<TT>`config.status'</TT>) is generated by the user with the
|
|
<CODE>configure</CODE> program, which is provided in the <CODE>tar</CODE>
|
|
distribution, but is not shown here.)
|
|
|
|
</P>
|
|
<P>
|
|
If you type <SAMP>`make realclean'</SAMP>, then <CODE>make</CODE> removes the same
|
|
files as does <SAMP>`make distclean'</SAMP> and also removes the Info files
|
|
generated from <TT>`tar.texinfo'</TT>.
|
|
|
|
</P>
|
|
<P>
|
|
In addition, there are targets <CODE>shar</CODE> and <CODE>dist</CODE> that create
|
|
distribution kits.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
# Generated automatically from Makefile.in by configure.
|
|
# Un*x Makefile for GNU tar program.
|
|
# Copyright (C) 1991 Free Software Foundation, Inc.
|
|
|
|
# This program is free software; you can redistribute
|
|
# it and/or modify it under the terms of the GNU
|
|
# General Public License ...
|
|
...
|
|
...
|
|
|
|
SHELL = /bin/sh
|
|
|
|
#### Start of system configuration section. ####
|
|
|
|
srcdir = .
|
|
|
|
# If you use gcc, you should either run the
|
|
# fixincludes script that comes with it or else use
|
|
# gcc with the -traditional option. Otherwise ioctl
|
|
# calls will be compiled incorrectly on some systems.
|
|
CC = gcc -O
|
|
YACC = bison -y
|
|
INSTALL = /usr/local/bin/install -c
|
|
INSTALLDATA = /usr/local/bin/install -c -m 644
|
|
|
|
# Things you might add to DEFS:
|
|
# -DSTDC_HEADERS If you have ANSI C headers and
|
|
# libraries.
|
|
# -DPOSIX If you have POSIX.1 headers and
|
|
# libraries.
|
|
# -DBSD42 If you have sys/dir.h (unless
|
|
# you use -DPOSIX), sys/file.h,
|
|
# and st_blocks in `struct stat'.
|
|
# -DUSG If you have System V/ANSI C
|
|
# string and memory functions
|
|
# and headers, sys/sysmacros.h,
|
|
# fcntl.h, getcwd, no valloc,
|
|
# and ndir.h (unless
|
|
# you use -DDIRENT).
|
|
# -DNO_MEMORY_H If USG or STDC_HEADERS but do not
|
|
# include memory.h.
|
|
# -DDIRENT If USG and you have dirent.h
|
|
# instead of ndir.h.
|
|
# -DSIGTYPE=int If your signal handlers
|
|
# return int, not void.
|
|
# -DNO_MTIO If you lack sys/mtio.h
|
|
# (magtape ioctls).
|
|
# -DNO_REMOTE If you do not have a remote shell
|
|
# or rexec.
|
|
# -DUSE_REXEC To use rexec for remote tape
|
|
# operations instead of
|
|
# forking rsh or remsh.
|
|
# -DVPRINTF_MISSING If you lack vprintf function
|
|
# (but have _doprnt).
|
|
# -DDOPRNT_MISSING If you lack _doprnt function.
|
|
# Also need to define
|
|
# -DVPRINTF_MISSING.
|
|
# -DFTIME_MISSING If you lack ftime system call.
|
|
# -DSTRSTR_MISSING If you lack strstr function.
|
|
# -DVALLOC_MISSING If you lack valloc function.
|
|
# -DMKDIR_MISSING If you lack mkdir and
|
|
# rmdir system calls.
|
|
# -DRENAME_MISSING If you lack rename system call.
|
|
# -DFTRUNCATE_MISSING If you lack ftruncate
|
|
# system call.
|
|
# -DV7 On Version 7 Unix (not
|
|
# tested in a long time).
|
|
# -DEMUL_OPEN3 If you lack a 3-argument version
|
|
# of open, and want to emulate it
|
|
# with system calls you do have.
|
|
# -DNO_OPEN3 If you lack the 3-argument open
|
|
# and want to disable the tar -k
|
|
# option instead of emulating open.
|
|
# -DXENIX If you have sys/inode.h
|
|
# and need it 94 to be included.
|
|
|
|
DEFS = -DSIGTYPE=int -DDIRENT -DSTRSTR_MISSING \
|
|
-DVPRINTF_MISSING -DBSD42
|
|
# Set this to rtapelib.o unless you defined NO_REMOTE,
|
|
# in which case make it empty.
|
|
RTAPELIB = rtapelib.o
|
|
LIBS =
|
|
DEF_AR_FILE = /dev/rmt8
|
|
DEFBLOCKING = 20
|
|
|
|
CDEBUG = -g
|
|
CFLAGS = $(CDEBUG) -I. -I$(srcdir) $(DEFS) \
|
|
-DDEF_AR_FILE=\"$(DEF_AR_FILE)\" \
|
|
-DDEFBLOCKING=$(DEFBLOCKING)
|
|
LDFLAGS = -g
|
|
|
|
prefix = /usr/local
|
|
# Prefix for each installed program,
|
|
# normally empty or `g'.
|
|
binprefix =
|
|
|
|
# The directory to install tar in.
|
|
bindir = $(prefix)/bin
|
|
|
|
# The directory to install the info files in.
|
|
infodir = $(prefix)/info
|
|
|
|
#### End of system configuration section. ####
|
|
|
|
SRC1 = tar.c create.c extract.c buffer.c \
|
|
getoldopt.c update.c gnu.c mangle.c
|
|
SRC2 = version.c list.c names.c diffarch.c \
|
|
port.c wildmat.c getopt.c
|
|
SRC3 = getopt1.c regex.c getdate.y
|
|
SRCS = $(SRC1) $(SRC2) $(SRC3)
|
|
OBJ1 = tar.o create.o extract.o buffer.o \
|
|
getoldopt.o update.o gnu.o mangle.o
|
|
OBJ2 = version.o list.o names.o diffarch.o \
|
|
port.o wildmat.o getopt.o
|
|
OBJ3 = getopt1.o regex.o getdate.o $(RTAPELIB)
|
|
OBJS = $(OBJ1) $(OBJ2) $(OBJ3)
|
|
AUX = README COPYING ChangeLog Makefile.in \
|
|
makefile.pc configure configure.in \
|
|
tar.texinfo tar.info* texinfo.tex \
|
|
tar.h port.h open3.h getopt.h regex.h \
|
|
rmt.h rmt.c rtapelib.c alloca.c \
|
|
msd_dir.h msd_dir.c tcexparg.c \
|
|
level-0 level-1 backup-specs testpad.c
|
|
|
|
all: tar rmt tar.info
|
|
|
|
tar: $(OBJS)
|
|
$(CC) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)
|
|
|
|
rmt: rmt.c
|
|
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ rmt.c
|
|
|
|
tar.info: tar.texinfo
|
|
makeinfo tar.texinfo
|
|
|
|
install: all
|
|
$(INSTALL) tar $(bindir)/$(binprefix)tar
|
|
-test ! -f rmt || $(INSTALL) rmt /etc/rmt
|
|
$(INSTALLDATA) $(srcdir)/tar.info* $(infodir)
|
|
|
|
$(OBJS): tar.h port.h testpad.h
|
|
regex.o buffer.o tar.o: regex.h
|
|
# getdate.y has 8 shift/reduce conflicts.
|
|
|
|
testpad.h: testpad
|
|
./testpad
|
|
|
|
testpad: testpad.o
|
|
$(CC) -o $@ testpad.o
|
|
|
|
TAGS: $(SRCS)
|
|
etags $(SRCS)
|
|
|
|
clean:
|
|
rm -f *.o tar rmt testpad testpad.h core
|
|
|
|
distclean: clean
|
|
rm -f TAGS Makefile config.status
|
|
|
|
realclean: distclean
|
|
rm -f tar.info*
|
|
|
|
shar: $(SRCS) $(AUX)
|
|
shar $(SRCS) $(AUX) | compress \
|
|
> tar-`sed -e '/version_string/!d' \
|
|
-e 's/[^0-9.]*\([0-9.]*\).*/\1/' \
|
|
-e q
|
|
version.c`.shar.Z
|
|
|
|
dist: $(SRCS) $(AUX)
|
|
echo tar-`sed \
|
|
-e '/version_string/!d' \
|
|
-e 's/[^0-9.]*\([0-9.]*\).*/\1/' \
|
|
-e q
|
|
version.c` > .fname
|
|
-rm -rf `cat .fname`
|
|
mkdir `cat .fname`
|
|
ln $(SRCS) $(AUX) `cat .fname`
|
|
tar chZf `cat .fname`.tar.Z `cat .fname`
|
|
-rm -rf `cat .fname` .fname
|
|
|
|
tar.zoo: $(SRCS) $(AUX)
|
|
-rm -rf tmp.dir
|
|
-mkdir tmp.dir
|
|
-rm tar.zoo
|
|
for X in $(SRCS) $(AUX) ; do \
|
|
echo $$X ; \
|
|
sed 's/$$/^M/' $$X \
|
|
> tmp.dir/$$X ; done
|
|
cd tmp.dir ; zoo aM ../tar.zoo *
|
|
-rm -rf tmp.dir
|
|
</PRE>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC126" HREF="make.html#TOC126">Index of Concepts</A></H1>
|
|
|
|
<P>
|
|
<H2>#</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX269"><CODE>#</CODE> (comments), in commands</A>
|
|
<LI><A HREF="make.html#IDX56"><CODE>#</CODE> (comments), in makefile</A>
|
|
<LI><A HREF="make.html#IDX257"><CODE>#include</CODE></A>
|
|
</DIR>
|
|
<H2>$</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX489"><CODE>$</CODE>, in function call</A>
|
|
<LI><A HREF="make.html#IDX127"><CODE>$</CODE>, in rules</A>
|
|
<LI><A HREF="make.html#IDX455"><CODE>$</CODE>, in variable name</A>
|
|
<LI><A HREF="make.html#IDX421"><CODE>$</CODE>, in variable reference</A>
|
|
</DIR>
|
|
<H2>%</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX831"><CODE>%</CODE>, in pattern rules</A>
|
|
<LI><A HREF="make.html#IDX242"><CODE>%</CODE>, quoting in static pattern</A>
|
|
<LI><A HREF="make.html#IDX496"><CODE>%</CODE>, quoting in <CODE>patsubst</CODE></A>
|
|
<LI><A HREF="make.html#IDX159"><CODE>%</CODE>, quoting in <CODE>vpath</CODE></A>
|
|
<LI><A HREF="make.html#IDX160"><CODE>%</CODE>, quoting with <CODE>\</CODE> (backslash)</A>, <A HREF="make.html#IDX243"><CODE>%</CODE>, quoting with <CODE>\</CODE> (backslash)</A>, <A HREF="make.html#IDX497"><CODE>%</CODE>, quoting with <CODE>\</CODE> (backslash)</A>
|
|
</DIR>
|
|
<H2>*</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX134"><CODE>*</CODE> (wildcard character)</A>
|
|
</DIR>
|
|
<H2>+</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX410">+, and <CODE>define</CODE></A>
|
|
<LI><A HREF="make.html#IDX464">+=</A>
|
|
<LI><A HREF="make.html#IDX100">+=, expansion</A>, <A HREF="make.html#IDX103">+=, expansion</A>
|
|
</DIR>
|
|
<H2>,</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX761">,v (RCS file extension)</A>
|
|
</DIR>
|
|
<H2>-</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX315"><CODE>-</CODE> (in commands)</A>
|
|
<LI><A HREF="make.html#IDX409">-, and <CODE>define</CODE></A>
|
|
<LI><A HREF="make.html#IDX612"><CODE>--assume-new</CODE></A>, <A HREF="make.html#IDX690"><CODE>--assume-new</CODE></A>
|
|
<LI><A HREF="make.html#IDX372"><CODE>--assume-new</CODE>, and recursion</A>
|
|
<LI><A HREF="make.html#IDX618"><CODE>--assume-old</CODE></A>, <A HREF="make.html#IDX663"><CODE>--assume-old</CODE></A>
|
|
<LI><A HREF="make.html#IDX371"><CODE>--assume-old</CODE>, and recursion</A>
|
|
<LI><A HREF="make.html#IDX638"><CODE>--debug</CODE></A>
|
|
<LI><A HREF="make.html#IDX337"><CODE>--directory</CODE></A>, <A HREF="make.html#IDX636"><CODE>--directory</CODE></A>
|
|
<LI><A HREF="make.html#IDX368"><CODE>--directory</CODE>, and recursion</A>
|
|
<LI><A HREF="make.html#IDX396"><CODE>--directory</CODE>, and <CODE>--print-directory</CODE></A>
|
|
<LI><A HREF="make.html#IDX277"><CODE>--dry-run</CODE></A>, <A HREF="make.html#IDX600"><CODE>--dry-run</CODE></A>, <A HREF="make.html#IDX659"><CODE>--dry-run</CODE></A>
|
|
<LI><A HREF="make.html#IDX640"><CODE>--environment-overrides</CODE></A>
|
|
<LI><A HREF="make.html#IDX66"><CODE>--file</CODE></A>, <A HREF="make.html#IDX577"><CODE>--file</CODE></A>, <A HREF="make.html#IDX642"><CODE>--file</CODE></A>
|
|
<LI><A HREF="make.html#IDX369"><CODE>--file</CODE>, and recursion</A>
|
|
<LI><A HREF="make.html#IDX645"><CODE>--help</CODE></A>
|
|
<LI><A HREF="make.html#IDX318"><CODE>--ignore-errors</CODE></A>, <A HREF="make.html#IDX647"><CODE>--ignore-errors</CODE></A>
|
|
<LI><A HREF="make.html#IDX82"><CODE>--include-dir</CODE></A>, <A HREF="make.html#IDX649"><CODE>--include-dir</CODE></A>
|
|
<LI><A HREF="make.html#IDX303"><CODE>--jobs</CODE></A>, <A HREF="make.html#IDX651"><CODE>--jobs</CODE></A>
|
|
<LI><A HREF="make.html#IDX379"><CODE>--jobs</CODE>, and recursion</A>
|
|
<LI><A HREF="make.html#IDX276"><CODE>--just-print</CODE></A>, <A HREF="make.html#IDX599"><CODE>--just-print</CODE></A>, <A HREF="make.html#IDX658"><CODE>--just-print</CODE></A>
|
|
<LI><A HREF="make.html#IDX321"><CODE>--keep-going</CODE></A>, <A HREF="make.html#IDX629"><CODE>--keep-going</CODE></A>, <A HREF="make.html#IDX653"><CODE>--keep-going</CODE></A>
|
|
<LI><A HREF="make.html#IDX311"><CODE>--load-average</CODE></A>, <A HREF="make.html#IDX655"><CODE>--load-average</CODE></A>
|
|
<LI><A HREF="make.html#IDX67"><CODE>--makefile</CODE></A>, <A HREF="make.html#IDX578"><CODE>--makefile</CODE></A>, <A HREF="make.html#IDX643"><CODE>--makefile</CODE></A>
|
|
<LI><A HREF="make.html#IDX310"><CODE>--max-load</CODE></A>, <A HREF="make.html#IDX656"><CODE>--max-load</CODE></A>
|
|
<LI><A HREF="make.html#IDX613"><CODE>--new-file</CODE></A>, <A HREF="make.html#IDX689"><CODE>--new-file</CODE></A>
|
|
<LI><A HREF="make.html#IDX373"><CODE>--new-file</CODE>, and recursion</A>
|
|
<LI><A HREF="make.html#IDX671"><CODE>--no-builtin-rules</CODE></A>
|
|
<LI><A HREF="make.html#IDX673"><CODE>--no-builtin-variables</CODE></A>
|
|
<LI><A HREF="make.html#IDX678"><CODE>--no-keep-going</CODE></A>
|
|
<LI><A HREF="make.html#IDX402"><CODE>--no-print-directory</CODE></A>, <A HREF="make.html#IDX686"><CODE>--no-print-directory</CODE></A>
|
|
<LI><A HREF="make.html#IDX617"><CODE>--old-file</CODE></A>, <A HREF="make.html#IDX662"><CODE>--old-file</CODE></A>
|
|
<LI><A HREF="make.html#IDX370"><CODE>--old-file</CODE>, and recursion</A>
|
|
<LI><A HREF="make.html#IDX665"><CODE>--print-data-base</CODE></A>
|
|
<LI><A HREF="make.html#IDX685"><CODE>--print-directory</CODE></A>
|
|
<LI><A HREF="make.html#IDX401"><CODE>--print-directory</CODE>, and recursion</A>
|
|
<LI><A HREF="make.html#IDX403"><CODE>--print-directory</CODE>, disabling</A>
|
|
<LI><A HREF="make.html#IDX400"><CODE>--print-directory</CODE>, and <CODE>--directory</CODE></A>
|
|
<LI><A HREF="make.html#IDX607"><CODE>--question</CODE></A>, <A HREF="make.html#IDX669"><CODE>--question</CODE></A>
|
|
<LI><A HREF="make.html#IDX281"><CODE>--quiet</CODE></A>, <A HREF="make.html#IDX676"><CODE>--quiet</CODE></A>
|
|
<LI><A HREF="make.html#IDX278"><CODE>--recon</CODE></A>, <A HREF="make.html#IDX601"><CODE>--recon</CODE></A>, <A HREF="make.html#IDX660"><CODE>--recon</CODE></A>
|
|
<LI><A HREF="make.html#IDX280"><CODE>--silent</CODE></A>, <A HREF="make.html#IDX675"><CODE>--silent</CODE></A>
|
|
<LI><A HREF="make.html#IDX679"><CODE>--stop</CODE></A>
|
|
<LI><A HREF="make.html#IDX603"><CODE>--touch</CODE></A>, <A HREF="make.html#IDX681"><CODE>--touch</CODE></A>
|
|
<LI><A HREF="make.html#IDX343"><CODE>--touch</CODE>, and recursion</A>
|
|
<LI><A HREF="make.html#IDX683"><CODE>--version</CODE></A>
|
|
<LI><A HREF="make.html#IDX691"><CODE>--warn-undefined-variables</CODE></A>
|
|
<LI><A HREF="make.html#IDX610"><CODE>--what-if</CODE></A>, <A HREF="make.html#IDX688"><CODE>--what-if</CODE></A>
|
|
<LI><A HREF="make.html#IDX633"><CODE>-b</CODE></A>
|
|
<LI><A HREF="make.html#IDX336"><CODE>-C</CODE></A>, <A HREF="make.html#IDX635"><CODE>-C</CODE></A>
|
|
<LI><A HREF="make.html#IDX364"><CODE>-C</CODE>, and recursion</A>
|
|
<LI><A HREF="make.html#IDX395"><CODE>-C</CODE>, and <CODE>-w</CODE></A>
|
|
<LI><A HREF="make.html#IDX637"><CODE>-d</CODE></A>
|
|
<LI><A HREF="make.html#IDX639"><CODE>-e</CODE></A>
|
|
<LI><A HREF="make.html#IDX260"><CODE>-e</CODE> (shell flag)</A>
|
|
<LI><A HREF="make.html#IDX65"><CODE>-f</CODE></A>, <A HREF="make.html#IDX579"><CODE>-f</CODE></A>, <A HREF="make.html#IDX641"><CODE>-f</CODE></A>
|
|
<LI><A HREF="make.html#IDX365"><CODE>-f</CODE>, and recursion</A>
|
|
<LI><A HREF="make.html#IDX644"><CODE>-h</CODE></A>
|
|
<LI><A HREF="make.html#IDX81"><CODE>-I</CODE></A>, <A HREF="make.html#IDX648"><CODE>-I</CODE></A>
|
|
<LI><A HREF="make.html#IDX317"><CODE>-i</CODE></A>, <A HREF="make.html#IDX646"><CODE>-i</CODE></A>
|
|
<LI><A HREF="make.html#IDX302"><CODE>-j</CODE></A>, <A HREF="make.html#IDX650"><CODE>-j</CODE></A>
|
|
<LI><A HREF="make.html#IDX906"><CODE>-j</CODE>, and archive update</A>
|
|
<LI><A HREF="make.html#IDX378"><CODE>-j</CODE>, and recursion</A>
|
|
<LI><A HREF="make.html#IDX320"><CODE>-k</CODE></A>, <A HREF="make.html#IDX628"><CODE>-k</CODE></A>, <A HREF="make.html#IDX652"><CODE>-k</CODE></A>
|
|
<LI><A HREF="make.html#IDX654"><CODE>-l</CODE></A>
|
|
<LI><A HREF="make.html#IDX183"><CODE>-l</CODE> (library search)</A>
|
|
<LI><A HREF="make.html#IDX309"><CODE>-l</CODE> (load average)</A>
|
|
<LI><A HREF="make.html#IDX634"><CODE>-m</CODE></A>
|
|
<LI><A HREF="make.html#IDX258"><CODE>-M</CODE> (to compiler)</A>
|
|
<LI><A HREF="make.html#IDX261"><CODE>-MM</CODE> (to GNU compiler)</A>
|
|
<LI><A HREF="make.html#IDX275"><CODE>-n</CODE></A>, <A HREF="make.html#IDX602"><CODE>-n</CODE></A>, <A HREF="make.html#IDX657"><CODE>-n</CODE></A>
|
|
<LI><A HREF="make.html#IDX616"><CODE>-o</CODE></A>, <A HREF="make.html#IDX661"><CODE>-o</CODE></A>
|
|
<LI><A HREF="make.html#IDX366"><CODE>-o</CODE>, and recursion</A>
|
|
<LI><A HREF="make.html#IDX664"><CODE>-p</CODE></A>
|
|
<LI><A HREF="make.html#IDX608"><CODE>-q</CODE></A>, <A HREF="make.html#IDX668"><CODE>-q</CODE></A>
|
|
<LI><A HREF="make.html#IDX672"><CODE>-R</CODE></A>
|
|
<LI><A HREF="make.html#IDX670"><CODE>-r</CODE></A>
|
|
<LI><A HREF="make.html#IDX677"><CODE>-S</CODE></A>
|
|
<LI><A HREF="make.html#IDX279"><CODE>-s</CODE></A>, <A HREF="make.html#IDX674"><CODE>-s</CODE></A>
|
|
<LI><A HREF="make.html#IDX606"><CODE>-t</CODE></A>, <A HREF="make.html#IDX680"><CODE>-t</CODE></A>
|
|
<LI><A HREF="make.html#IDX341"><CODE>-t</CODE>, and recursion</A>
|
|
<LI><A HREF="make.html#IDX682"><CODE>-v</CODE></A>
|
|
<LI><A HREF="make.html#IDX611"><CODE>-W</CODE></A>, <A HREF="make.html#IDX687"><CODE>-W</CODE></A>
|
|
<LI><A HREF="make.html#IDX684"><CODE>-w</CODE></A>
|
|
<LI><A HREF="make.html#IDX367"><CODE>-W</CODE>, and recursion</A>
|
|
<LI><A HREF="make.html#IDX399"><CODE>-w</CODE>, and recursion</A>
|
|
<LI><A HREF="make.html#IDX404"><CODE>-w</CODE>, disabling</A>
|
|
<LI><A HREF="make.html#IDX398"><CODE>-w</CODE>, and <CODE>-C</CODE></A>
|
|
</DIR>
|
|
<H2>.</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX910"><CODE>.a</CODE> (archives)</A>
|
|
<LI><A HREF="make.html#IDX707">.C</A>
|
|
<LI><A HREF="make.html#IDX704">.c</A>
|
|
<LI><A HREF="make.html#IDX708">.cc</A>
|
|
<LI><A HREF="make.html#IDX750">.ch</A>
|
|
<LI><A HREF="make.html#IDX263"><CODE>.d</CODE></A>
|
|
<LI><A HREF="make.html#IDX721">.def</A>
|
|
<LI><A HREF="make.html#IDX746">.dvi</A>
|
|
<LI><A HREF="make.html#IDX717">.F</A>
|
|
<LI><A HREF="make.html#IDX715">.f</A>
|
|
<LI><A HREF="make.html#IDX756">.info</A>
|
|
<LI><A HREF="make.html#IDX735">.l</A>
|
|
<LI><A HREF="make.html#IDX185"><CODE>.LIBPATTERNS</CODE>, and link libraries</A>
|
|
<LI><A HREF="make.html#IDX738">.ln</A>
|
|
<LI><A HREF="make.html#IDX722">.mod</A>
|
|
<LI><A HREF="make.html#IDX703">.o</A>, <A HREF="make.html#IDX729">.o</A>
|
|
<LI><A HREF="make.html#IDX711">.p</A>
|
|
<LI><A HREF="make.html#IDX827"><CODE>.PRECIOUS</CODE> intermediate files</A>
|
|
<LI><A HREF="make.html#IDX716">.r</A>
|
|
<LI><A HREF="make.html#IDX726">.S</A>
|
|
<LI><A HREF="make.html#IDX725">.s</A>
|
|
<LI><A HREF="make.html#IDX765">.sh</A>
|
|
<LI><A HREF="make.html#IDX720">.sym</A>
|
|
<LI><A HREF="make.html#IDX747">.tex</A>
|
|
<LI><A HREF="make.html#IDX757">.texi</A>
|
|
<LI><A HREF="make.html#IDX755">.texinfo</A>
|
|
<LI><A HREF="make.html#IDX758">.txinfo</A>
|
|
<LI><A HREF="make.html#IDX749">.w</A>
|
|
<LI><A HREF="make.html#IDX748">.web</A>
|
|
<LI><A HREF="make.html#IDX732">.y</A>
|
|
</DIR>
|
|
<H2>:</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX253"><CODE>::</CODE> rules (double-colon)</A>
|
|
<LI><A HREF="make.html#IDX433">:=</A>, <A HREF="make.html#IDX462">:=</A>
|
|
</DIR>
|
|
<H2>=</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX428">=</A>, <A HREF="make.html#IDX461">=</A>
|
|
<LI><A HREF="make.html#IDX101">=, expansion</A>
|
|
</DIR>
|
|
<H2>?</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX135"><CODE>?</CODE> (wildcard character)</A>
|
|
<LI><A HREF="make.html#IDX441">?=</A>, <A HREF="make.html#IDX463">?=</A>
|
|
<LI><A HREF="make.html#IDX102">?=, expansion</A>
|
|
</DIR>
|
|
<H2>@</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX272"><CODE>@</CODE> (in commands)</A>
|
|
<LI><A HREF="make.html#IDX408">@, and <CODE>define</CODE></A>
|
|
</DIR>
|
|
<H2>[</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX136"><CODE>[...]</CODE> (wildcard characters)</A>
|
|
</DIR>
|
|
<H2>\</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX20"><CODE>\</CODE> (backslash), for continuation lines</A>
|
|
<LI><A HREF="make.html#IDX291"><CODE>\</CODE> (backslash), in commands</A>
|
|
<LI><A HREF="make.html#IDX161"><CODE>\</CODE> (backslash), to quote <CODE>%</CODE></A>, <A HREF="make.html#IDX244"><CODE>\</CODE> (backslash), to quote <CODE>%</CODE></A>, <A HREF="make.html#IDX498"><CODE>\</CODE> (backslash), to quote <CODE>%</CODE></A>
|
|
</DIR>
|
|
<H2>_</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX898"><CODE>__.SYMDEF</CODE></A>
|
|
</DIR>
|
|
<H2>a</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX164">algorithm for directory search</A>
|
|
<LI><A HREF="make.html#IDX583"><CODE>all</CODE> (standard target)</A>
|
|
<LI><A HREF="make.html#IDX465">appending to variables</A>
|
|
<LI><A HREF="make.html#IDX769">ar</A>
|
|
<LI><A HREF="make.html#IDX895">archive</A>
|
|
<LI><A HREF="make.html#IDX896">archive member targets</A>
|
|
<LI><A HREF="make.html#IDX900">archive symbol directory updating</A>
|
|
<LI><A HREF="make.html#IDX905">archive, and <CODE>-j</CODE></A>
|
|
<LI><A HREF="make.html#IDX903">archive, and parallel execution</A>
|
|
<LI><A HREF="make.html#IDX908">archive, suffix rule for</A>
|
|
<LI><A HREF="make.html#IDX383">Arg list too long</A>
|
|
<LI><A HREF="make.html#IDX491">arguments of functions</A>
|
|
<LI><A HREF="make.html#IDX724">as</A>, <A HREF="make.html#IDX771">as</A>
|
|
<LI><A HREF="make.html#IDX723">assembly, rule to compile</A>
|
|
<LI><A HREF="make.html#IDX79">automatic generation of prerequisites</A>, <A HREF="make.html#IDX255">automatic generation of prerequisites</A>
|
|
<LI><A HREF="make.html#IDX837">automatic variables</A>
|
|
</DIR>
|
|
<H2>b</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX567">backquotes</A>
|
|
<LI><A HREF="make.html#IDX21">backslash (<CODE>\</CODE>), for continuation lines</A>
|
|
<LI><A HREF="make.html#IDX290">backslash (<CODE>\</CODE>), in commands</A>
|
|
<LI><A HREF="make.html#IDX162">backslash (<CODE>\</CODE>), to quote <CODE>%</CODE></A>, <A HREF="make.html#IDX245">backslash (<CODE>\</CODE>), to quote <CODE>%</CODE></A>, <A HREF="make.html#IDX499">backslash (<CODE>\</CODE>), to quote <CODE>%</CODE></A>
|
|
<LI><A HREF="make.html#IDX150">backslashes in pathnames and wildcard expansion</A>
|
|
<LI><A HREF="make.html#IDX532">basename</A>
|
|
<LI><A HREF="make.html#IDX923">binary packages</A>
|
|
<LI><A HREF="make.html#IDX304">broken pipe</A>
|
|
<LI><A HREF="make.html#IDX5">bugs, reporting</A>
|
|
<LI><A HREF="make.html#IDX203">built-in special targets</A>
|
|
</DIR>
|
|
<H2>c</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX705">C++, rule to compile</A>
|
|
<LI><A HREF="make.html#IDX700">C, rule to compile</A>
|
|
<LI><A HREF="make.html#IDX701">cc</A>, <A HREF="make.html#IDX773">cc</A>
|
|
<LI><A HREF="make.html#IDX287"><CODE>cd</CODE> (shell command)</A>, <A HREF="make.html#IDX340"><CODE>cd</CODE> (shell command)</A>
|
|
<LI><A HREF="make.html#IDX819">chains of rules</A>
|
|
<LI><A HREF="make.html#IDX595"><CODE>check</CODE> (standard target)</A>
|
|
<LI><A HREF="make.html#IDX584"><CODE>clean</CODE> (standard target)</A>
|
|
<LI><A HREF="make.html#IDX25"><CODE>clean</CODE> target</A>, <A HREF="make.html#IDX47"><CODE>clean</CODE> target</A>
|
|
<LI><A HREF="make.html#IDX45">cleaning up</A>
|
|
<LI><A HREF="make.html#IDX588"><CODE>clobber</CODE> (standard target)</A>
|
|
<LI><A HREF="make.html#IDX760">co</A>, <A HREF="make.html#IDX777">co</A>
|
|
<LI><A HREF="make.html#IDX44">combining rules by prerequisite</A>
|
|
<LI><A HREF="make.html#IDX361">command line variable definitions, and recursion</A>
|
|
<LI><A HREF="make.html#IDX624">command line variables</A>
|
|
<LI><A HREF="make.html#IDX124">commands</A>
|
|
<LI><A HREF="make.html#IDX288">commands, backslash (<CODE>\</CODE>) in</A>
|
|
<LI><A HREF="make.html#IDX268">commands, comments in</A>
|
|
<LI><A HREF="make.html#IDX273">commands, echoing</A>
|
|
<LI><A HREF="make.html#IDX412">commands, empty</A>
|
|
<LI><A HREF="make.html#IDX313">commands, errors in</A>
|
|
<LI><A HREF="make.html#IDX283">commands, execution</A>
|
|
<LI><A HREF="make.html#IDX298">commands, execution in parallel</A>
|
|
<LI><A HREF="make.html#IDX566">commands, expansion</A>
|
|
<LI><A HREF="make.html#IDX264">commands, how to write</A>
|
|
<LI><A HREF="make.html#IDX598">commands, instead of executing</A>
|
|
<LI><A HREF="make.html#IDX15">commands, introduction to</A>
|
|
<LI><A HREF="make.html#IDX289">commands, quoting newlines in</A>
|
|
<LI><A HREF="make.html#IDX406">commands, sequences of</A>
|
|
<LI><A HREF="make.html#IDX267">comments, in commands</A>
|
|
<LI><A HREF="make.html#IDX55">comments, in makefile</A>
|
|
<LI><A HREF="make.html#IDX913">compatibility</A>
|
|
<LI><A HREF="make.html#IDX354">compatibility in exporting</A>
|
|
<LI><A HREF="make.html#IDX627">compilation, testing</A>
|
|
<LI><A HREF="make.html#IDX451">computed variable name</A>
|
|
<LI><A HREF="make.html#IDX558">conditional expansion</A>
|
|
<LI><A HREF="make.html#IDX439">conditional variable assignment</A>
|
|
<LI><A HREF="make.html#IDX481">conditionals</A>
|
|
<LI><A HREF="make.html#IDX19">continuation lines</A>
|
|
<LI><A HREF="make.html#IDX570">controlling make</A>
|
|
<LI><A HREF="make.html#IDX919">conventions for makefiles</A>
|
|
<LI><A HREF="make.html#IDX745">ctangle</A>, <A HREF="make.html#IDX803">ctangle</A>
|
|
<LI><A HREF="make.html#IDX742">cweave</A>, <A HREF="make.html#IDX799">cweave</A>
|
|
</DIR>
|
|
<H2>d</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX666">data base of <CODE>make</CODE> rules</A>
|
|
<LI><A HREF="make.html#IDX41">deducing commands (implicit rules)</A>
|
|
<LI><A HREF="make.html#IDX84">default directries for included makefiles</A>
|
|
<LI><A HREF="make.html#IDX29">default goal</A>, <A HREF="make.html#IDX118">default goal</A>
|
|
<LI><A HREF="make.html#IDX59">default makefile name</A>
|
|
<LI><A HREF="make.html#IDX887">default rules, last-resort</A>
|
|
<LI><A HREF="make.html#IDX104">define, expansion</A>
|
|
<LI><A HREF="make.html#IDX473">defining variables verbatim</A>
|
|
<LI><A HREF="make.html#IDX324">deletion of target files</A>, <A HREF="make.html#IDX329">deletion of target files</A>
|
|
<LI><A HREF="make.html#IDX54">directive</A>
|
|
<LI><A HREF="make.html#IDX392">directories, printing them</A>
|
|
<LI><A HREF="make.html#IDX902">directories, updating archive symbol</A>
|
|
<LI><A HREF="make.html#IDX523">directory part</A>
|
|
<LI><A HREF="make.html#IDX156">directory search (<CODE>VPATH</CODE>)</A>
|
|
<LI><A HREF="make.html#IDX172">directory search (<CODE>VPATH</CODE>), and implicit rules</A>
|
|
<LI><A HREF="make.html#IDX180">directory search (<CODE>VPATH</CODE>), and link libraries</A>
|
|
<LI><A HREF="make.html#IDX170">directory search (<CODE>VPATH</CODE>), and shell commands</A>
|
|
<LI><A HREF="make.html#IDX165">directory search algorithm</A>
|
|
<LI><A HREF="make.html#IDX167">directory search, traditional</A>
|
|
<LI><A HREF="make.html#IDX593"><CODE>dist</CODE> (standard target)</A>
|
|
<LI><A HREF="make.html#IDX586"><CODE>distclean</CODE> (standard target)</A>
|
|
<LI><A HREF="make.html#IDX490">dollar sign (<CODE>$</CODE>), in function call</A>
|
|
<LI><A HREF="make.html#IDX126">dollar sign (<CODE>$</CODE>), in rules</A>
|
|
<LI><A HREF="make.html#IDX456">dollar sign (<CODE>$</CODE>), in variable name</A>
|
|
<LI><A HREF="make.html#IDX422">dollar sign (<CODE>$</CODE>), in variable reference</A>
|
|
<LI><A HREF="make.html#IDX250">double-colon rules</A>
|
|
<LI><A HREF="make.html#IDX518">duplicate words, removing</A>
|
|
</DIR>
|
|
<H2>e</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX384">E2BIG</A>
|
|
<LI><A HREF="make.html#IDX270">echoing of commands</A>
|
|
<LI><A HREF="make.html#IDX9">editor</A>
|
|
<LI><A HREF="make.html#IDX322">Emacs (<CODE>M-x compile</CODE>)</A>
|
|
<LI><A HREF="make.html#IDX411">empty commands</A>
|
|
<LI><A HREF="make.html#IDX196">empty targets</A>
|
|
<LI><A HREF="make.html#IDX476">environment</A>
|
|
<LI><A HREF="make.html#IDX345">environment, and recursion</A>
|
|
<LI><A HREF="make.html#IDX297">environment, <CODE>SHELL</CODE> in</A>
|
|
<LI><A HREF="make.html#IDX572">error, stopping on</A>
|
|
<LI><A HREF="make.html#IDX312">errors (in commands)</A>
|
|
<LI><A HREF="make.html#IDX147">errors with wildcards</A>
|
|
<LI><A HREF="make.html#IDX300">execution, in parallel</A>
|
|
<LI><A HREF="make.html#IDX597">execution, instead of</A>
|
|
<LI><A HREF="make.html#IDX284">execution, of commands</A>
|
|
<LI><A HREF="make.html#IDX314">exit status (errors)</A>
|
|
<LI><A HREF="make.html#IDX50">explicit rule, definition of</A>
|
|
<LI><A HREF="make.html#IDX113">explicit rule, expansion</A>
|
|
<LI><A HREF="make.html#IDX346">exporting variables</A>
|
|
</DIR>
|
|
<H2>f</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX714">f77</A>, <A HREF="make.html#IDX780">f77</A>
|
|
<LI><A HREF="make.html#IDX911">features of GNU <CODE>make</CODE></A>
|
|
<LI><A HREF="make.html#IDX916">features, missing</A>
|
|
<LI><A HREF="make.html#IDX521">file name functions</A>
|
|
<LI><A HREF="make.html#IDX60">file name of makefile</A>
|
|
<LI><A HREF="make.html#IDX71">file name of makefile, how to specify</A>
|
|
<LI><A HREF="make.html#IDX539">file name prefix, adding</A>
|
|
<LI><A HREF="make.html#IDX530">file name suffix</A>
|
|
<LI><A HREF="make.html#IDX536">file name suffix, adding</A>
|
|
<LI><A HREF="make.html#IDX132">file name with wildcards</A>
|
|
<LI><A HREF="make.html#IDX533">file name, basename of</A>
|
|
<LI><A HREF="make.html#IDX524">file name, directory part</A>
|
|
<LI><A HREF="make.html#IDX526">file name, nondirectory part</A>
|
|
<LI><A HREF="make.html#IDX615">files, assuming new</A>
|
|
<LI><A HREF="make.html#IDX619">files, assuming old</A>
|
|
<LI><A HREF="make.html#IDX620">files, avoiding recompilation of</A>
|
|
<LI><A HREF="make.html#IDX822">files, intermediate</A>
|
|
<LI><A HREF="make.html#IDX513">filtering out words</A>
|
|
<LI><A HREF="make.html#IDX510">filtering words</A>
|
|
<LI><A HREF="make.html#IDX507">finding strings</A>
|
|
<LI><A HREF="make.html#IDX631">flags</A>
|
|
<LI><A HREF="make.html#IDX767">flags for compilers</A>
|
|
<LI><A HREF="make.html#IDX423">flavors of variables</A>
|
|
<LI><A HREF="make.html#IDX194"><CODE>FORCE</CODE></A>
|
|
<LI><A HREF="make.html#IDX192">force targets</A>
|
|
<LI><A HREF="make.html#IDX712">Fortran, rule to compile</A>
|
|
<LI><A HREF="make.html#IDX488">functions</A>
|
|
<LI><A HREF="make.html#IDX569">functions, for controlling make</A>
|
|
<LI><A HREF="make.html#IDX520">functions, for file names</A>
|
|
<LI><A HREF="make.html#IDX493">functions, for text</A>
|
|
<LI><A HREF="make.html#IDX492">functions, syntax of</A>
|
|
<LI><A HREF="make.html#IDX560">functions, user defined</A>
|
|
</DIR>
|
|
<H2>g</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX706">g++</A>, <A HREF="make.html#IDX775">g++</A>
|
|
<LI><A HREF="make.html#IDX702">gcc</A>
|
|
<LI><A HREF="make.html#IDX80">generating prerequisites automatically</A>, <A HREF="make.html#IDX256">generating prerequisites automatically</A>
|
|
<LI><A HREF="make.html#IDX763">get</A>, <A HREF="make.html#IDX782">get</A>
|
|
<LI><A HREF="make.html#IDX133">globbing (wildcards)</A>
|
|
<LI><A HREF="make.html#IDX31">goal</A>
|
|
<LI><A HREF="make.html#IDX30">goal, default</A>, <A HREF="make.html#IDX119">goal, default</A>
|
|
<LI><A HREF="make.html#IDX580">goal, how to specify</A>
|
|
</DIR>
|
|
<H2>h</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX139">home directory</A>
|
|
</DIR>
|
|
<H2>i</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX2">IEEE Standard 1003.2</A>
|
|
<LI><A HREF="make.html#IDX105">ifdef, expansion</A>
|
|
<LI><A HREF="make.html#IDX106">ifeq, expansion</A>
|
|
<LI><A HREF="make.html#IDX107">ifndef, expansion</A>
|
|
<LI><A HREF="make.html#IDX108">ifneq, expansion</A>
|
|
<LI><A HREF="make.html#IDX694">implicit rule</A>
|
|
<LI><A HREF="make.html#IDX174">implicit rule, and directory search</A>
|
|
<LI><A HREF="make.html#IDX175">implicit rule, and <CODE>VPATH</CODE></A>
|
|
<LI><A HREF="make.html#IDX52">implicit rule, definition of</A>
|
|
<LI><A HREF="make.html#IDX111">implicit rule, expansion</A>
|
|
<LI><A HREF="make.html#IDX696">implicit rule, how to use</A>
|
|
<LI><A HREF="make.html#IDX42">implicit rule, introduction to</A>
|
|
<LI><A HREF="make.html#IDX698">implicit rule, predefined</A>
|
|
<LI><A HREF="make.html#IDX893">implicit rule, search algorithm</A>
|
|
<LI><A HREF="make.html#IDX83">included makefiles, default directries</A>
|
|
<LI><A HREF="make.html#IDX89">including (<CODE>MAKEFILES</CODE> variable)</A>
|
|
<LI><A HREF="make.html#IDX72">including other makefiles</A>
|
|
<LI><A HREF="make.html#IDX914">incompatibilities</A>
|
|
<LI><A HREF="make.html#IDX752">Info, rule to format</A>
|
|
<LI><A HREF="make.html#IDX589"><CODE>install</CODE> (standard target)</A>
|
|
<LI><A HREF="make.html#IDX821">intermediate files</A>
|
|
<LI><A HREF="make.html#IDX823">intermediate files, preserving</A>
|
|
<LI><A HREF="make.html#IDX212">intermediate targets, explicit</A>
|
|
<LI><A HREF="make.html#IDX327">interrupt</A>
|
|
</DIR>
|
|
<H2>j</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX301">job slots</A>
|
|
<LI><A HREF="make.html#IDX381">job slots, and recursion</A>
|
|
<LI><A HREF="make.html#IDX308">jobs, limiting based on load</A>
|
|
<LI><A HREF="make.html#IDX541">joining lists of words</A>
|
|
</DIR>
|
|
<H2>k</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX332">killing (interruption)</A>
|
|
</DIR>
|
|
<H2>l</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX886">last-resort default rules</A>
|
|
<LI><A HREF="make.html#IDX728">ld</A>
|
|
<LI><A HREF="make.html#IDX733">lex</A>, <A HREF="make.html#IDX784">lex</A>
|
|
<LI><A HREF="make.html#IDX734">Lex, rule to run</A>
|
|
<LI><A HREF="make.html#IDX179">libraries for linking, directory search</A>
|
|
<LI><A HREF="make.html#IDX909">library archive, suffix rule for</A>
|
|
<LI><A HREF="make.html#IDX307">limiting jobs based on load</A>
|
|
<LI><A HREF="make.html#IDX178">link libraries, and directory search</A>
|
|
<LI><A HREF="make.html#IDX184">link libraries, patterns matching</A>
|
|
<LI><A HREF="make.html#IDX727">linking, predefined rule for</A>
|
|
<LI><A HREF="make.html#IDX736">lint</A>
|
|
<LI><A HREF="make.html#IDX737"><CODE>lint</CODE>, rule to run</A>
|
|
<LI><A HREF="make.html#IDX853">list of all prerequisites</A>
|
|
<LI><A HREF="make.html#IDX849">list of changed prerequisites</A>
|
|
<LI><A HREF="make.html#IDX306">load average</A>
|
|
<LI><A HREF="make.html#IDX429">loops in variable expansion</A>
|
|
<LI><A HREF="make.html#IDX142"><CODE>lpr</CODE> (shell command)</A>, <A HREF="make.html#IDX200"><CODE>lpr</CODE> (shell command)</A>
|
|
</DIR>
|
|
<H2>m</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX719">m2c</A>
|
|
<LI><A HREF="make.html#IDX418">macro</A>
|
|
<LI><A HREF="make.html#IDX259"><CODE>make depend</CODE></A>
|
|
<LI><A HREF="make.html#IDX581"><CODE>MAKECMDGOALS</CODE></A>
|
|
<LI><A HREF="make.html#IDX7">makefile</A>
|
|
<LI><A HREF="make.html#IDX57">makefile name</A>
|
|
<LI><A HREF="make.html#IDX69">makefile name, how to specify</A>
|
|
<LI><A HREF="make.html#IDX11">makefile rule parts</A>
|
|
<LI><A HREF="make.html#IDX88">makefile, and <CODE>MAKEFILES</CODE> variable</A>
|
|
<LI><A HREF="make.html#IDX918">makefile, conventions for</A>
|
|
<LI><A HREF="make.html#IDX28">makefile, how <CODE>make</CODE> processes</A>
|
|
<LI><A HREF="make.html#IDX48">makefile, how to write</A>
|
|
<LI><A HREF="make.html#IDX73">makefile, including</A>
|
|
<LI><A HREF="make.html#IDX96">makefile, overriding</A>
|
|
<LI><A HREF="make.html#IDX99">makefile, parsing</A>
|
|
<LI><A HREF="make.html#IDX94">makefile, remaking of</A>
|
|
<LI><A HREF="make.html#IDX18">makefile, simple</A>
|
|
<LI><A HREF="make.html#IDX754">makeinfo</A>, <A HREF="make.html#IDX791">makeinfo</A>
|
|
<LI><A HREF="make.html#IDX884">match-anything rule</A>
|
|
<LI><A HREF="make.html#IDX97">match-anything rule, used to override</A>
|
|
<LI><A HREF="make.html#IDX915">missing features</A>
|
|
<LI><A HREF="make.html#IDX146">mistakes with wildcards</A>
|
|
<LI><A HREF="make.html#IDX443">modified variable reference</A>
|
|
<LI><A HREF="make.html#IDX718">Modula-2, rule to compile</A>
|
|
<LI><A HREF="make.html#IDX585"><CODE>mostlyclean</CODE> (standard target)</A>
|
|
<LI><A HREF="make.html#IDX228">multiple rules for one target</A>
|
|
<LI><A HREF="make.html#IDX252">multiple rules for one target (<CODE>::</CODE>)</A>
|
|
<LI><A HREF="make.html#IDX223">multiple targets</A>
|
|
<LI><A HREF="make.html#IDX833">multiple targets, in pattern rule</A>
|
|
</DIR>
|
|
<H2>n</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX58">name of makefile</A>
|
|
<LI><A HREF="make.html#IDX70">name of makefile, how to specify</A>
|
|
<LI><A HREF="make.html#IDX450">nested variable reference</A>
|
|
<LI><A HREF="make.html#IDX293">newline, quoting, in commands</A>
|
|
<LI><A HREF="make.html#IDX23">newline, quoting, in makefile</A>
|
|
<LI><A HREF="make.html#IDX527">nondirectory part</A>
|
|
</DIR>
|
|
<H2>o</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX40"><CODE>OBJ</CODE></A>
|
|
<LI><A HREF="make.html#IDX39"><CODE>obj</CODE></A>
|
|
<LI><A HREF="make.html#IDX36"><CODE>OBJECTS</CODE></A>
|
|
<LI><A HREF="make.html#IDX35"><CODE>objects</CODE></A>
|
|
<LI><A HREF="make.html#IDX38"><CODE>OBJS</CODE></A>
|
|
<LI><A HREF="make.html#IDX37"><CODE>objs</CODE></A>
|
|
<LI><A HREF="make.html#IDX889">old-fashioned suffix rules</A>
|
|
<LI><A HREF="make.html#IDX630">options</A>
|
|
<LI><A HREF="make.html#IDX358">options, and recursion</A>
|
|
<LI><A HREF="make.html#IDX389">options, setting from environment</A>
|
|
<LI><A HREF="make.html#IDX391">options, setting in makefiles</A>
|
|
<LI><A HREF="make.html#IDX836">order of pattern rules</A>
|
|
<LI><A HREF="make.html#IDX564">origin of variable</A>
|
|
<LI><A HREF="make.html#IDX95">overriding makefiles</A>
|
|
<LI><A HREF="make.html#IDX622">overriding variables with arguments</A>
|
|
<LI><A HREF="make.html#IDX468">overriding with <CODE>override</CODE></A>
|
|
</DIR>
|
|
<H2>p</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX299">parallel execution</A>
|
|
<LI><A HREF="make.html#IDX904">parallel execution, and archive update</A>
|
|
<LI><A HREF="make.html#IDX222">parallel execution, overriding</A>
|
|
<LI><A HREF="make.html#IDX12">parts of makefile rule</A>
|
|
<LI><A HREF="make.html#IDX709">Pascal, rule to compile</A>
|
|
<LI><A HREF="make.html#IDX828">pattern rule</A>
|
|
<LI><A HREF="make.html#IDX112">pattern rule, expansion</A>
|
|
<LI><A HREF="make.html#IDX835">pattern rules, order of</A>
|
|
<LI><A HREF="make.html#IDX234">pattern rules, static (not implicit)</A>
|
|
<LI><A HREF="make.html#IDX238">pattern rules, static, syntax of</A>
|
|
<LI><A HREF="make.html#IDX479">pattern-specific variables</A>
|
|
<LI><A HREF="make.html#IDX710">pc</A>, <A HREF="make.html#IDX786">pc</A>
|
|
<LI><A HREF="make.html#IDX187">phony targets</A>
|
|
<LI><A HREF="make.html#IDX145">pitfalls of wildcards</A>
|
|
<LI><A HREF="make.html#IDX912">portability</A>
|
|
<LI><A HREF="make.html#IDX1">POSIX</A>
|
|
<LI><A HREF="make.html#IDX386">POSIX.2</A>
|
|
<LI><A HREF="make.html#IDX922">post-installation commands</A>
|
|
<LI><A HREF="make.html#IDX921">pre-installation commands</A>
|
|
<LI><A HREF="make.html#IDX209">precious targets</A>
|
|
<LI><A HREF="make.html#IDX667">predefined rules and variables, printing</A>
|
|
<LI><A HREF="make.html#IDX538">prefix, adding</A>
|
|
<LI><A HREF="make.html#IDX117">prerequisite</A>
|
|
<LI><A HREF="make.html#IDX832">prerequisite pattern, implicit</A>
|
|
<LI><A HREF="make.html#IDX241">prerequisite pattern, static (not implicit)</A>
|
|
<LI><A HREF="make.html#IDX110">prerequisite, expansion</A>
|
|
<LI><A HREF="make.html#IDX129">prerequisites</A>
|
|
<LI><A HREF="make.html#IDX78">prerequisites, automatic generation</A>, <A HREF="make.html#IDX254">prerequisites, automatic generation</A>
|
|
<LI><A HREF="make.html#IDX14">prerequisites, introduction to</A>
|
|
<LI><A HREF="make.html#IDX852">prerequisites, list of all</A>
|
|
<LI><A HREF="make.html#IDX848">prerequisites, list of changed</A>
|
|
<LI><A HREF="make.html#IDX236">prerequisites, varying (static pattern)</A>
|
|
<LI><A HREF="make.html#IDX824">preserving intermediate files</A>
|
|
<LI><A HREF="make.html#IDX210">preserving with <CODE>.PRECIOUS</CODE></A>, <A HREF="make.html#IDX826">preserving with <CODE>.PRECIOUS</CODE></A>
|
|
<LI><A HREF="make.html#IDX215">preserving with <CODE>.SECONDARY</CODE></A>
|
|
<LI><A HREF="make.html#IDX590"><CODE>print</CODE> (standard target)</A>
|
|
<LI><A HREF="make.html#IDX141"><CODE>print</CODE> target</A>, <A HREF="make.html#IDX199"><CODE>print</CODE> target</A>
|
|
<LI><A HREF="make.html#IDX393">printing directories</A>
|
|
<LI><A HREF="make.html#IDX274">printing of commands</A>
|
|
<LI><A HREF="make.html#IDX576">printing user warnings</A>
|
|
<LI><A HREF="make.html#IDX6">problems and bugs, reporting</A>
|
|
<LI><A HREF="make.html#IDX148">problems with wildcards</A>
|
|
<LI><A HREF="make.html#IDX27">processing a makefile</A>
|
|
</DIR>
|
|
<H2>q</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX609">question mode</A>
|
|
<LI><A HREF="make.html#IDX246">quoting <CODE>%</CODE>, in static pattern</A>
|
|
<LI><A HREF="make.html#IDX500">quoting <CODE>%</CODE>, in <CODE>patsubst</CODE></A>
|
|
<LI><A HREF="make.html#IDX163">quoting <CODE>%</CODE>, in <CODE>vpath</CODE></A>
|
|
<LI><A HREF="make.html#IDX292">quoting newline, in commands</A>
|
|
<LI><A HREF="make.html#IDX22">quoting newline, in makefile</A>
|
|
</DIR>
|
|
<H2>r</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX713">Ratfor, rule to compile</A>
|
|
<LI><A HREF="make.html#IDX759">RCS, rule to extract from</A>
|
|
<LI><A HREF="make.html#IDX98">reading makefiles</A>
|
|
<LI><A HREF="make.html#IDX64"><CODE>README</CODE></A>
|
|
<LI><A HREF="make.html#IDX587"><CODE>realclean</CODE> (standard target)</A>
|
|
<LI><A HREF="make.html#IDX8">recompilation</A>
|
|
<LI><A HREF="make.html#IDX621">recompilation, avoiding</A>
|
|
<LI><A HREF="make.html#IDX198">recording events with empty targets</A>
|
|
<LI><A HREF="make.html#IDX334">recursion</A>
|
|
<LI><A HREF="make.html#IDX374">recursion, and <CODE>-C</CODE></A>
|
|
<LI><A HREF="make.html#IDX375">recursion, and <CODE>-f</CODE></A>
|
|
<LI><A HREF="make.html#IDX380">recursion, and <CODE>-j</CODE></A>
|
|
<LI><A HREF="make.html#IDX376">recursion, and <CODE>-o</CODE></A>
|
|
<LI><A HREF="make.html#IDX342">recursion, and <CODE>-t</CODE></A>
|
|
<LI><A HREF="make.html#IDX377">recursion, and <CODE>-W</CODE></A>
|
|
<LI><A HREF="make.html#IDX397">recursion, and <CODE>-w</CODE></A>
|
|
<LI><A HREF="make.html#IDX363">recursion, and command line variable definitions</A>
|
|
<LI><A HREF="make.html#IDX349">recursion, and environment</A>
|
|
<LI><A HREF="make.html#IDX339">recursion, and <CODE>MAKE</CODE> variable</A>
|
|
<LI><A HREF="make.html#IDX91">recursion, and <CODE>MAKEFILES</CODE> variable</A>
|
|
<LI><A HREF="make.html#IDX359">recursion, and options</A>
|
|
<LI><A HREF="make.html#IDX394">recursion, and printing directories</A>
|
|
<LI><A HREF="make.html#IDX350">recursion, and variables</A>
|
|
<LI><A HREF="make.html#IDX356">recursion, level of</A>
|
|
<LI><A HREF="make.html#IDX416">recursive variable expansion</A>, <A HREF="make.html#IDX424">recursive variable expansion</A>
|
|
<LI><A HREF="make.html#IDX426">recursively expanded variables</A>
|
|
<LI><A HREF="make.html#IDX420">reference to variables</A>, <A HREF="make.html#IDX442">reference to variables</A>
|
|
<LI><A HREF="make.html#IDX32">relinking</A>
|
|
<LI><A HREF="make.html#IDX93">remaking makefiles</A>
|
|
<LI><A HREF="make.html#IDX325">removal of target files</A>, <A HREF="make.html#IDX330">removal of target files</A>
|
|
<LI><A HREF="make.html#IDX517">removing duplicate words</A>
|
|
<LI><A HREF="make.html#IDX217">removing targets on failure</A>
|
|
<LI><A HREF="make.html#IDX46">removing, to clean up</A>
|
|
<LI><A HREF="make.html#IDX4">reporting bugs</A>
|
|
<LI><A HREF="make.html#IDX805">rm</A>
|
|
<LI><A HREF="make.html#IDX26"><CODE>rm</CODE> (shell command)</A>, <A HREF="make.html#IDX140"><CODE>rm</CODE> (shell command)</A>, <A HREF="make.html#IDX190"><CODE>rm</CODE> (shell command)</A>, <A HREF="make.html#IDX316"><CODE>rm</CODE> (shell command)</A>
|
|
<LI><A HREF="make.html#IDX265">rule commands</A>
|
|
<LI><A HREF="make.html#IDX130">rule prerequisites</A>
|
|
<LI><A HREF="make.html#IDX120">rule syntax</A>
|
|
<LI><A HREF="make.html#IDX123">rule targets</A>
|
|
<LI><A HREF="make.html#IDX128">rule, and <CODE>$</CODE></A>
|
|
<LI><A HREF="make.html#IDX251">rule, double-colon (<CODE>::</CODE>)</A>
|
|
<LI><A HREF="make.html#IDX49">rule, explicit, definition of</A>
|
|
<LI><A HREF="make.html#IDX115">rule, how to write</A>
|
|
<LI><A HREF="make.html#IDX695">rule, implicit</A>
|
|
<LI><A HREF="make.html#IDX176">rule, implicit, and directory search</A>
|
|
<LI><A HREF="make.html#IDX177">rule, implicit, and <CODE>VPATH</CODE></A>
|
|
<LI><A HREF="make.html#IDX820">rule, implicit, chains of</A>
|
|
<LI><A HREF="make.html#IDX51">rule, implicit, definition of</A>
|
|
<LI><A HREF="make.html#IDX697">rule, implicit, how to use</A>
|
|
<LI><A HREF="make.html#IDX43">rule, implicit, introduction to</A>
|
|
<LI><A HREF="make.html#IDX699">rule, implicit, predefined</A>
|
|
<LI><A HREF="make.html#IDX10">rule, introduction to</A>
|
|
<LI><A HREF="make.html#IDX230">rule, multiple for one target</A>
|
|
<LI><A HREF="make.html#IDX195">rule, no commands or prerequisites</A>
|
|
<LI><A HREF="make.html#IDX829">rule, pattern</A>
|
|
<LI><A HREF="make.html#IDX233">rule, static pattern</A>
|
|
<LI><A HREF="make.html#IDX248">rule, static pattern versus implicit</A>
|
|
<LI><A HREF="make.html#IDX226">rule, with multiple targets</A>
|
|
</DIR>
|
|
<H2>s</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX764">s. (SCCS file prefix)</A>
|
|
<LI><A HREF="make.html#IDX762">SCCS, rule to extract from</A>
|
|
<LI><A HREF="make.html#IDX894">search algorithm, implicit rule</A>
|
|
<LI><A HREF="make.html#IDX155">search path for prerequisites (<CODE>VPATH</CODE>)</A>
|
|
<LI><A HREF="make.html#IDX173">search path for prerequisites (<CODE>VPATH</CODE>), and implicit rules</A>
|
|
<LI><A HREF="make.html#IDX182">search path for prerequisites (<CODE>VPATH</CODE>), and link libraries</A>
|
|
<LI><A HREF="make.html#IDX506">searching for strings</A>
|
|
<LI><A HREF="make.html#IDX825">secondary files</A>
|
|
<LI><A HREF="make.html#IDX214">secondary targets</A>
|
|
<LI><A HREF="make.html#IDX262"><CODE>sed</CODE> (shell command)</A>
|
|
<LI><A HREF="make.html#IDX545">selecting a word</A>
|
|
<LI><A HREF="make.html#IDX548">selecting word lists</A>
|
|
<LI><A HREF="make.html#IDX405">sequences of commands</A>
|
|
<LI><A HREF="make.html#IDX388">setting options from environment</A>
|
|
<LI><A HREF="make.html#IDX390">setting options in makefiles</A>
|
|
<LI><A HREF="make.html#IDX459">setting variables</A>
|
|
<LI><A HREF="make.html#IDX229">several rules for one target</A>
|
|
<LI><A HREF="make.html#IDX224">several targets in a rule</A>
|
|
<LI><A HREF="make.html#IDX592"><CODE>shar</CODE> (standard target)</A>
|
|
<LI><A HREF="make.html#IDX24">shell command</A>
|
|
<LI><A HREF="make.html#IDX169">shell command, and directory search</A>
|
|
<LI><A HREF="make.html#IDX285">shell command, execution</A>
|
|
<LI><A HREF="make.html#IDX568">shell command, function for</A>
|
|
<LI><A HREF="make.html#IDX75">shell file name pattern (in <CODE>include</CODE>)</A>
|
|
<LI><A HREF="make.html#IDX76">shell wildcards (in <CODE>include</CODE>)</A>
|
|
<LI><A HREF="make.html#IDX296"><CODE>SHELL</CODE>, MS-DOS specifics</A>
|
|
<LI><A HREF="make.html#IDX328">signal</A>
|
|
<LI><A HREF="make.html#IDX271">silent operation</A>
|
|
<LI><A HREF="make.html#IDX17">simple makefile</A>
|
|
<LI><A HREF="make.html#IDX417">simple variable expansion</A>
|
|
<LI><A HREF="make.html#IDX34">simplifying with variables</A>
|
|
<LI><A HREF="make.html#IDX431">simply expanded variables</A>
|
|
<LI><A HREF="make.html#IDX516">sorting words</A>
|
|
<LI><A HREF="make.html#IDX436">spaces, in variable values</A>
|
|
<LI><A HREF="make.html#IDX503">spaces, stripping</A>
|
|
<LI><A HREF="make.html#IDX202">special targets</A>
|
|
<LI><A HREF="make.html#IDX68">specifying makefile name</A>
|
|
<LI><A HREF="make.html#IDX305">standard input</A>
|
|
<LI><A HREF="make.html#IDX3">standards conformance</A>
|
|
<LI><A HREF="make.html#IDX920">standards for makefiles</A>
|
|
<LI><A HREF="make.html#IDX232">static pattern rule</A>
|
|
<LI><A HREF="make.html#IDX237">static pattern rule, syntax of</A>
|
|
<LI><A HREF="make.html#IDX249">static pattern rule, versus implicit</A>
|
|
<LI><A HREF="make.html#IDX240">stem</A>, <A HREF="make.html#IDX883">stem</A>
|
|
<LI><A HREF="make.html#IDX858">stem, variable for</A>
|
|
<LI><A HREF="make.html#IDX573">stopping make</A>
|
|
<LI><A HREF="make.html#IDX508">strings, searching for</A>
|
|
<LI><A HREF="make.html#IDX501">stripping whitespace</A>
|
|
<LI><A HREF="make.html#IDX344">sub-<CODE>make</CODE></A>
|
|
<LI><A HREF="make.html#IDX335">subdirectories, recursion for</A>
|
|
<LI><A HREF="make.html#IDX444">substitution variable reference</A>
|
|
<LI><A HREF="make.html#IDX890">suffix rule</A>
|
|
<LI><A HREF="make.html#IDX907">suffix rule, for archive</A>
|
|
<LI><A HREF="make.html#IDX535">suffix, adding</A>
|
|
<LI><A HREF="make.html#IDX529">suffix, function to find</A>
|
|
<LI><A HREF="make.html#IDX448">suffix, substituting in variables</A>
|
|
<LI><A HREF="make.html#IDX632">switches</A>
|
|
<LI><A HREF="make.html#IDX901">symbol directories, updating archive</A>
|
|
<LI><A HREF="make.html#IDX121">syntax of rules</A>
|
|
</DIR>
|
|
<H2>t</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX125">tab character (in commands)</A>
|
|
<LI><A HREF="make.html#IDX16">tabs in rules</A>
|
|
<LI><A HREF="make.html#IDX594"><CODE>TAGS</CODE> (standard target)</A>
|
|
<LI><A HREF="make.html#IDX744">tangle</A>, <A HREF="make.html#IDX801">tangle</A>
|
|
<LI><A HREF="make.html#IDX591"><CODE>tar</CODE> (standard target)</A>
|
|
<LI><A HREF="make.html#IDX116">target</A>
|
|
<LI><A HREF="make.html#IDX830">target pattern, implicit</A>
|
|
<LI><A HREF="make.html#IDX239">target pattern, static (not implicit)</A>
|
|
<LI><A HREF="make.html#IDX326">target, deleting on error</A>
|
|
<LI><A HREF="make.html#IDX331">target, deleting on interrupt</A>
|
|
<LI><A HREF="make.html#IDX109">target, expansion</A>
|
|
<LI><A HREF="make.html#IDX834">target, multiple in pattern rule</A>
|
|
<LI><A HREF="make.html#IDX231">target, multiple rules for one</A>
|
|
<LI><A HREF="make.html#IDX605">target, touching</A>
|
|
<LI><A HREF="make.html#IDX477">target-specific variables</A>
|
|
<LI><A HREF="make.html#IDX122">targets</A>
|
|
<LI><A HREF="make.html#IDX189">targets without a file</A>
|
|
<LI><A HREF="make.html#IDX204">targets, built-in special</A>
|
|
<LI><A HREF="make.html#IDX197">targets, empty</A>
|
|
<LI><A HREF="make.html#IDX193">targets, force</A>
|
|
<LI><A HREF="make.html#IDX13">targets, introduction to</A>
|
|
<LI><A HREF="make.html#IDX225">targets, multiple</A>
|
|
<LI><A HREF="make.html#IDX188">targets, phony</A>
|
|
<LI><A HREF="make.html#IDX885">terminal rule</A>
|
|
<LI><A HREF="make.html#IDX596"><CODE>test</CODE> (standard target)</A>
|
|
<LI><A HREF="make.html#IDX626">testing compilation</A>
|
|
<LI><A HREF="make.html#IDX741">tex</A>, <A HREF="make.html#IDX793">tex</A>
|
|
<LI><A HREF="make.html#IDX739">TeX, rule to run</A>
|
|
<LI><A HREF="make.html#IDX753">texi2dvi</A>, <A HREF="make.html#IDX795">texi2dvi</A>
|
|
<LI><A HREF="make.html#IDX751">Texinfo, rule to format</A>
|
|
<LI><A HREF="make.html#IDX138">tilde (<CODE>~</CODE>)</A>
|
|
<LI><A HREF="make.html#IDX143"><CODE>touch</CODE> (shell command)</A>, <A HREF="make.html#IDX201"><CODE>touch</CODE> (shell command)</A>
|
|
<LI><A HREF="make.html#IDX604">touching files</A>
|
|
<LI><A HREF="make.html#IDX166">traditional directory search</A>
|
|
</DIR>
|
|
<H2>u</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX693">undefined variables, warning message</A>
|
|
<LI><A HREF="make.html#IDX899">updating archive symbol directories</A>
|
|
<LI><A HREF="make.html#IDX92">updating makefiles</A>
|
|
<LI><A HREF="make.html#IDX561">user defined functions</A>
|
|
</DIR>
|
|
<H2>v</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX415">value</A>
|
|
<LI><A HREF="make.html#IDX458">value, how a variable gets it</A>
|
|
<LI><A HREF="make.html#IDX414">variable</A>
|
|
<LI><A HREF="make.html#IDX53">variable definition</A>
|
|
<LI><A HREF="make.html#IDX33">variables</A>
|
|
<LI><A HREF="make.html#IDX454">variables, <SAMP>`$'</SAMP> in name</A>
|
|
<LI><A HREF="make.html#IDX839">variables, and implicit rule</A>
|
|
<LI><A HREF="make.html#IDX466">variables, appending to</A>
|
|
<LI><A HREF="make.html#IDX838">variables, automatic</A>
|
|
<LI><A HREF="make.html#IDX625">variables, command line</A>
|
|
<LI><A HREF="make.html#IDX362">variables, command line, and recursion</A>
|
|
<LI><A HREF="make.html#IDX452">variables, computed names</A>
|
|
<LI><A HREF="make.html#IDX440">variables, conditional assignment</A>
|
|
<LI><A HREF="make.html#IDX474">variables, defining verbatim</A>
|
|
<LI><A HREF="make.html#IDX347">variables, environment</A>, <A HREF="make.html#IDX475">variables, environment</A>
|
|
<LI><A HREF="make.html#IDX348">variables, exporting</A>
|
|
<LI><A HREF="make.html#IDX425">variables, flavors</A>
|
|
<LI><A HREF="make.html#IDX457">variables, how they get their values</A>
|
|
<LI><A HREF="make.html#IDX419">variables, how to reference</A>
|
|
<LI><A HREF="make.html#IDX430">variables, loops in expansion</A>
|
|
<LI><A HREF="make.html#IDX445">variables, modified reference</A>
|
|
<LI><A HREF="make.html#IDX453">variables, nested references</A>
|
|
<LI><A HREF="make.html#IDX563">variables, origin of</A>
|
|
<LI><A HREF="make.html#IDX469">variables, overriding</A>
|
|
<LI><A HREF="make.html#IDX623">variables, overriding with arguments</A>
|
|
<LI><A HREF="make.html#IDX480">variables, pattern-specific</A>
|
|
<LI><A HREF="make.html#IDX427">variables, recursively expanded</A>
|
|
<LI><A HREF="make.html#IDX460">variables, setting</A>
|
|
<LI><A HREF="make.html#IDX432">variables, simply expanded</A>
|
|
<LI><A HREF="make.html#IDX438">variables, spaces in values</A>
|
|
<LI><A HREF="make.html#IDX447">variables, substituting suffix in</A>
|
|
<LI><A HREF="make.html#IDX446">variables, substitution reference</A>
|
|
<LI><A HREF="make.html#IDX478">variables, target-specific</A>
|
|
<LI><A HREF="make.html#IDX692">variables, warning for undefined</A>
|
|
<LI><A HREF="make.html#IDX235">varying prerequisites</A>
|
|
<LI><A HREF="make.html#IDX472">verbatim variable definition</A>
|
|
<LI><A HREF="make.html#IDX154">vpath</A>
|
|
<LI><A HREF="make.html#IDX171"><CODE>VPATH</CODE>, and implicit rules</A>
|
|
<LI><A HREF="make.html#IDX181"><CODE>VPATH</CODE>, and link libraries</A>
|
|
</DIR>
|
|
<H2>w</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX575">warnings, printing</A>
|
|
<LI><A HREF="make.html#IDX743">weave</A>, <A HREF="make.html#IDX797">weave</A>
|
|
<LI><A HREF="make.html#IDX740">Web, rule to run</A>
|
|
<LI><A HREF="make.html#IDX614">what if</A>
|
|
<LI><A HREF="make.html#IDX437">whitespace, in variable values</A>
|
|
<LI><A HREF="make.html#IDX502">whitespace, stripping</A>
|
|
<LI><A HREF="make.html#IDX131">wildcard</A>
|
|
<LI><A HREF="make.html#IDX144">wildcard pitfalls</A>
|
|
<LI><A HREF="make.html#IDX554">wildcard, function</A>
|
|
<LI><A HREF="make.html#IDX897">wildcard, in archive member</A>
|
|
<LI><A HREF="make.html#IDX77">wildcard, in <CODE>include</CODE></A>
|
|
<LI><A HREF="make.html#IDX149">wildcards and MS-DOS/MS-Windows backslashes</A>
|
|
<LI><A HREF="make.html#IDX544">word, selecting a</A>
|
|
<LI><A HREF="make.html#IDX552">words, extracting first</A>
|
|
<LI><A HREF="make.html#IDX511">words, filtering</A>
|
|
<LI><A HREF="make.html#IDX514">words, filtering out</A>
|
|
<LI><A HREF="make.html#IDX550">words, finding number</A>
|
|
<LI><A HREF="make.html#IDX556">words, iterating over</A>
|
|
<LI><A HREF="make.html#IDX542">words, joining lists</A>
|
|
<LI><A HREF="make.html#IDX519">words, removing duplicates</A>
|
|
<LI><A HREF="make.html#IDX547">words, selecting lists of</A>
|
|
<LI><A HREF="make.html#IDX266">writing rule commands</A>
|
|
<LI><A HREF="make.html#IDX114">writing rules</A>
|
|
</DIR>
|
|
<H2>y</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX407"><CODE>yacc</CODE></A>
|
|
<LI><A HREF="make.html#IDX730">yacc</A>, <A HREF="make.html#IDX788">yacc</A>
|
|
<LI><A HREF="make.html#IDX731">Yacc, rule to run</A>
|
|
</DIR>
|
|
<H2>~</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX137"><CODE>~</CODE> (tilde)</A>
|
|
</DIR>
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC127" HREF="make.html#TOC127">Index of Functions, Variables, & Directives</A></H1>
|
|
|
|
<P>
|
|
<H2>$</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX842">$%</A>
|
|
<LI><A HREF="make.html#IDX867">$(%D)</A>
|
|
<LI><A HREF="make.html#IDX869">$(%F)</A>
|
|
<LI><A HREF="make.html#IDX863">$(*D)</A>
|
|
<LI><A HREF="make.html#IDX865">$(*F)</A>
|
|
<LI><A HREF="make.html#IDX871">$(<D)</A>
|
|
<LI><A HREF="make.html#IDX873">$(<F)</A>
|
|
<LI><A HREF="make.html#IDX879">$(?D)</A>
|
|
<LI><A HREF="make.html#IDX881">$(?F)</A>
|
|
<LI><A HREF="make.html#IDX859">$(@D)</A>
|
|
<LI><A HREF="make.html#IDX861">$(@F)</A>
|
|
<LI><A HREF="make.html#IDX875">$(^D)</A>
|
|
<LI><A HREF="make.html#IDX877">$(^F)</A>
|
|
<LI><A HREF="make.html#IDX856">$*</A>
|
|
<LI><A HREF="make.html#IDX247">$*, and static pattern</A>
|
|
<LI><A HREF="make.html#IDX854">$+</A>
|
|
<LI><A HREF="make.html#IDX844">$<</A>
|
|
<LI><A HREF="make.html#IDX846">$?</A>
|
|
<LI><A HREF="make.html#IDX840">$@</A>
|
|
<LI><A HREF="make.html#IDX850">$^</A>
|
|
</DIR>
|
|
<H2>%</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX843">% (automatic variable)</A>
|
|
<LI><A HREF="make.html#IDX868">%D (automatic variable)</A>
|
|
<LI><A HREF="make.html#IDX870">%F (automatic variable)</A>
|
|
</DIR>
|
|
<H2>*</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX857">* (automatic variable)</A>
|
|
<LI><A HREF="make.html#IDX917">* (automatic variable), unsupported bizarre usage</A>
|
|
<LI><A HREF="make.html#IDX864">*D (automatic variable)</A>
|
|
<LI><A HREF="make.html#IDX866">*F (automatic variable)</A>
|
|
</DIR>
|
|
<H2>+</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX855">+ (automatic variable)</A>
|
|
</DIR>
|
|
<H2>.</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX207">.DEFAULT</A>, <A HREF="make.html#IDX888">.DEFAULT</A>
|
|
<LI><A HREF="make.html#IDX413">.DEFAULT, and empty commands</A>
|
|
<LI><A HREF="make.html#IDX216">.DELETE_ON_ERROR</A>, <A HREF="make.html#IDX323">.DELETE_ON_ERROR</A>
|
|
<LI><A HREF="make.html#IDX220">.EXPORT_ALL_VARIABLES</A>, <A HREF="make.html#IDX353">.EXPORT_ALL_VARIABLES</A>
|
|
<LI><A HREF="make.html#IDX218">.IGNORE</A>, <A HREF="make.html#IDX319">.IGNORE</A>
|
|
<LI><A HREF="make.html#IDX211">.INTERMEDIATE</A>
|
|
<LI><A HREF="make.html#IDX186">.LIBPATTERNS</A>
|
|
<LI><A HREF="make.html#IDX221">.NOTPARALLEL</A>
|
|
<LI><A HREF="make.html#IDX191">.PHONY</A>, <A HREF="make.html#IDX205">.PHONY</A>
|
|
<LI><A HREF="make.html#IDX385">.POSIX</A>
|
|
<LI><A HREF="make.html#IDX208">.PRECIOUS</A>, <A HREF="make.html#IDX333">.PRECIOUS</A>
|
|
<LI><A HREF="make.html#IDX213">.SECONDARY</A>
|
|
<LI><A HREF="make.html#IDX219">.SILENT</A>, <A HREF="make.html#IDX282">.SILENT</A>
|
|
<LI><A HREF="make.html#IDX206">.SUFFIXES</A>, <A HREF="make.html#IDX891">.SUFFIXES</A>
|
|
</DIR>
|
|
<H2>/</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX85">/usr/gnu/include</A>
|
|
<LI><A HREF="make.html#IDX87">/usr/include</A>
|
|
<LI><A HREF="make.html#IDX86">/usr/local/include</A>
|
|
</DIR>
|
|
<H2><</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX845">< (automatic variable)</A>
|
|
<LI><A HREF="make.html#IDX872"><D (automatic variable)</A>
|
|
<LI><A HREF="make.html#IDX874"><F (automatic variable)</A>
|
|
</DIR>
|
|
<H2>?</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX847">? (automatic variable)</A>
|
|
<LI><A HREF="make.html#IDX880">?D (automatic variable)</A>
|
|
<LI><A HREF="make.html#IDX882">?F (automatic variable)</A>
|
|
</DIR>
|
|
<H2>@</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX841">@ (automatic variable)</A>
|
|
<LI><A HREF="make.html#IDX860">@D (automatic variable)</A>
|
|
<LI><A HREF="make.html#IDX862">@F (automatic variable)</A>
|
|
</DIR>
|
|
<H2>^</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX851">^ (automatic variable)</A>
|
|
<LI><A HREF="make.html#IDX876">^D (automatic variable)</A>
|
|
<LI><A HREF="make.html#IDX878">^F (automatic variable)</A>
|
|
</DIR>
|
|
<H2>a</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX537">addprefix</A>
|
|
<LI><A HREF="make.html#IDX534">addsuffix</A>
|
|
<LI><A HREF="make.html#IDX768">AR</A>
|
|
<LI><A HREF="make.html#IDX806">ARFLAGS</A>
|
|
<LI><A HREF="make.html#IDX770">AS</A>
|
|
<LI><A HREF="make.html#IDX807">ASFLAGS</A>
|
|
</DIR>
|
|
<H2>b</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX531">basename</A>
|
|
</DIR>
|
|
<H2>c</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX559">call</A>
|
|
<LI><A HREF="make.html#IDX772">CC</A>
|
|
<LI><A HREF="make.html#IDX808">CFLAGS</A>
|
|
<LI><A HREF="make.html#IDX776">CO</A>
|
|
<LI><A HREF="make.html#IDX810">COFLAGS</A>
|
|
<LI><A HREF="make.html#IDX295">COMSPEC</A>
|
|
<LI><A HREF="make.html#IDX778">CPP</A>
|
|
<LI><A HREF="make.html#IDX811">CPPFLAGS</A>
|
|
<LI><A HREF="make.html#IDX802">CTANGLE</A>
|
|
<LI><A HREF="make.html#IDX798">CWEAVE</A>
|
|
<LI><A HREF="make.html#IDX774">CXX</A>
|
|
<LI><A HREF="make.html#IDX809">CXXFLAGS</A>
|
|
</DIR>
|
|
<H2>d</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX470">define</A>
|
|
<LI><A HREF="make.html#IDX522">dir</A>
|
|
</DIR>
|
|
<H2>e</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX486">else</A>
|
|
<LI><A HREF="make.html#IDX471">endef</A>
|
|
<LI><A HREF="make.html#IDX487">endif</A>
|
|
<LI><A HREF="make.html#IDX571">error</A>
|
|
<LI><A HREF="make.html#IDX351">export</A>
|
|
</DIR>
|
|
<H2>f</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX779">FC</A>
|
|
<LI><A HREF="make.html#IDX812">FFLAGS</A>
|
|
<LI><A HREF="make.html#IDX509">filter</A>
|
|
<LI><A HREF="make.html#IDX512">filter-out</A>
|
|
<LI><A HREF="make.html#IDX505">findstring</A>
|
|
<LI><A HREF="make.html#IDX551">firstword</A>
|
|
<LI><A HREF="make.html#IDX555">foreach</A>
|
|
</DIR>
|
|
<H2>g</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX781">GET</A>
|
|
<LI><A HREF="make.html#IDX813">GFLAGS</A>
|
|
<LI><A HREF="make.html#IDX62">GNUmakefile</A>
|
|
<LI><A HREF="make.html#IDX168">GPATH</A>
|
|
</DIR>
|
|
<H2>i</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX557">if</A>
|
|
<LI><A HREF="make.html#IDX482">ifdef</A>
|
|
<LI><A HREF="make.html#IDX483">ifeq</A>
|
|
<LI><A HREF="make.html#IDX484">ifndef</A>
|
|
<LI><A HREF="make.html#IDX485">ifneq</A>
|
|
<LI><A HREF="make.html#IDX74">include</A>
|
|
</DIR>
|
|
<H2>j</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX540">join</A>
|
|
</DIR>
|
|
<H2>l</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX814">LDFLAGS</A>
|
|
<LI><A HREF="make.html#IDX783">LEX</A>
|
|
<LI><A HREF="make.html#IDX815">LFLAGS</A>
|
|
</DIR>
|
|
<H2>m</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX338">MAKE</A>, <A HREF="make.html#IDX435">MAKE</A>
|
|
<LI><A HREF="make.html#IDX582">MAKECMDGOALS</A>
|
|
<LI><A HREF="make.html#IDX61">Makefile</A>
|
|
<LI><A HREF="make.html#IDX63">makefile</A>
|
|
<LI><A HREF="make.html#IDX90">MAKEFILES</A>, <A HREF="make.html#IDX357">MAKEFILES</A>
|
|
<LI><A HREF="make.html#IDX360">MAKEFLAGS</A>
|
|
<LI><A HREF="make.html#IDX790">MAKEINFO</A>
|
|
<LI><A HREF="make.html#IDX355">MAKELEVEL</A>, <A HREF="make.html#IDX434">MAKELEVEL</A>
|
|
<LI><A HREF="make.html#IDX382">MAKEOVERRIDES</A>
|
|
<LI><A HREF="make.html#IDX387">MFLAGS</A>
|
|
</DIR>
|
|
<H2>n</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX525">notdir</A>
|
|
</DIR>
|
|
<H2>o</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX562">origin</A>
|
|
<LI><A HREF="make.html#IDX766">OUTPUT_OPTION</A>
|
|
<LI><A HREF="make.html#IDX467">override</A>
|
|
</DIR>
|
|
<H2>p</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX449">patsubst</A>, <A HREF="make.html#IDX495">patsubst</A>
|
|
<LI><A HREF="make.html#IDX785">PC</A>
|
|
<LI><A HREF="make.html#IDX816">PFLAGS</A>
|
|
</DIR>
|
|
<H2>r</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX817">RFLAGS</A>
|
|
<LI><A HREF="make.html#IDX804">RM</A>
|
|
</DIR>
|
|
<H2>s</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX565">shell</A>
|
|
<LI><A HREF="make.html#IDX294">SHELL</A>
|
|
<LI><A HREF="make.html#IDX286">SHELL (command execution)</A>
|
|
<LI><A HREF="make.html#IDX515">sort</A>
|
|
<LI><A HREF="make.html#IDX504">strip</A>
|
|
<LI><A HREF="make.html#IDX227">subst</A>, <A HREF="make.html#IDX494">subst</A>
|
|
<LI><A HREF="make.html#IDX528">suffix</A>
|
|
<LI><A HREF="make.html#IDX892">SUFFIXES</A>
|
|
</DIR>
|
|
<H2>t</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX800">TANGLE</A>
|
|
<LI><A HREF="make.html#IDX792">TEX</A>
|
|
<LI><A HREF="make.html#IDX794">TEXI2DVI</A>
|
|
</DIR>
|
|
<H2>u</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX352">unexport</A>
|
|
</DIR>
|
|
<H2>v</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX152">VPATH</A>, <A HREF="make.html#IDX157">VPATH</A>
|
|
<LI><A HREF="make.html#IDX153">vpath</A>, <A HREF="make.html#IDX158">vpath</A>
|
|
</DIR>
|
|
<H2>w</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX574">warning</A>
|
|
<LI><A HREF="make.html#IDX796">WEAVE</A>
|
|
<LI><A HREF="make.html#IDX151">wildcard</A>, <A HREF="make.html#IDX553">wildcard</A>
|
|
<LI><A HREF="make.html#IDX543">word</A>
|
|
<LI><A HREF="make.html#IDX546">wordlist</A>
|
|
<LI><A HREF="make.html#IDX549">words</A>
|
|
</DIR>
|
|
<H2>y</H2>
|
|
<DIR>
|
|
<LI><A HREF="make.html#IDX787">YACC</A>
|
|
<LI><A HREF="make.html#IDX789">YACCR</A>
|
|
<LI><A HREF="make.html#IDX818">YFLAGS</A>
|
|
</DIR>
|
|
|
|
</P>
|
|
<P><HR><P>
|
|
<H1>Footnotes</H1>
|
|
<H3><A NAME="FOOT1" HREF="make.html#DOCF1">(1)</A></H3>
|
|
<P>GNU Make compiled for MS-DOS and MS-Windows behaves as if
|
|
<VAR>prefix</VAR> has been defined to be the root of the DJGPP tree
|
|
hierarchy.
|
|
<H3><A NAME="FOOT2" HREF="make.html#DOCF2">(2)</A></H3>
|
|
<P>On MS-DOS, the value of current working
|
|
directory is <STRONG>global</STRONG>, so changing it <EM>will</EM> affect the
|
|
following command lines on those systems.
|
|
<H3><A NAME="FOOT3" HREF="make.html#DOCF3">(3)</A></H3>
|
|
<P><CODE>texi2dvi</CODE> uses TeX to do the real work
|
|
of formatting. TeX is not distributed with Texinfo.
|
|
<P><HR><P>
|
|
This document was generated on 19 July 2000 using the
|
|
<A HREF="http://wwwcn.cern.ch/dci/texi2html/">texi2html</A>
|
|
translator version 1.54.</P>
|
|
</BODY>
|
|
</HTML>
|