Skip to content

Commit a048a08

Browse files
chaselambdachaselambda
committed
Change some reordering
1 parent e457b8d commit a048a08

File tree

2 files changed

+69
-68
lines changed

2 files changed

+69
-68
lines changed

‎docs/index.html

Lines changed: 36 additions & 35 deletions
Original file line numberDiff line numberDiff line change
@@ -172,19 +172,19 @@
172172

173173

174174
<ol>
175-
<li><a class="toc-item" href="#static-pattern-rules">Static Pattern Rules</a>
175+
<li><a class="toc-item" href="#implicit-rules">Implicit Rules</a>
176176
</li>
177177

178178
</ol>
179179

180180
<ol>
181-
<li><a class="toc-item" href="#static-pattern-rules-and-filter">Static Pattern Rules and Filter</a>
181+
<li><a class="toc-item" href="#static-pattern-rules">Static Pattern Rules</a>
182182
</li>
183183

184184
</ol>
185185

186186
<ol>
187-
<li><a class="toc-item" href="#implicit-rules">Implicit Rules</a>
187+
<li><a class="toc-item" href="#static-pattern-rules-and-filter">Static Pattern Rules and Filter</a>
188188
</li>
189189

190190
</ol>
@@ -653,13 +653,44 @@ <h2 id="automatic-variables">Automatic Variables</h2>
653653
rm -f hey one two</code></pre>
654654

655655
<h1 id="fancy-rules">Fancy Rules</h1>
656+
<h2 id="implicit-rules">Implicit Rules</h2>
657+
<!-- (Section 10) -->
658+
<p>Make loves c compilation. And every time it expresses its love, things get confusing. Perhaps the most confusing part of Make is the magic/automatic rules that are made. Make calls these &quot;implicit&quot; rules. I don&#39;t personally agree with this design decision, and I don&#39;t recommend using them, but they&#39;re often used and are thus useful to know. Here&#39;s a list of implicit rules:</p>
659+
<ul>
660+
<li>Compiling a C program: <code>n.o</code> is made automatically from <code>n.c</code> with a command of the form <code>$(CC) -c $(CPPFLAGS) $(CFLAGS)</code></li>
661+
<li>Compiling a C++ program: <code>n.o</code> is made automatically from <code>n.cc</code> or <code>n.cpp</code> with a command of the form <code>$(CXX) -c $(CPPFLAGS) $(CXXFLAGS)</code></li>
662+
<li>Linking a single object file: <code>n</code> is made automatically from <code>n.o</code> by running the command <code>$(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)</code></li>
663+
</ul>
664+
<p>The important variables used by implicit rules are:</p>
665+
<ul>
666+
<li><code>CC</code>: Program for compiling C programs; default <code>cc</code></li>
667+
<li><code>CXX</code>: Program for compiling C++ programs; default <code>g++</code></li>
668+
<li><code>CFLAGS</code>: Extra flags to give to the C compiler</li>
669+
<li><code>CXXFLAGS</code>: Extra flags to give to the C++ compiler</li>
670+
<li><code>CPPFLAGS</code>: Extra flags to give to the C preprocessor</li>
671+
<li><code>LDFLAGS</code>: Extra flags to give to compilers when they are supposed to invoke the linker</li>
672+
</ul>
673+
<p>Let&#39;s see how we can now build a C program without ever explicitly telling Make how to do the compililation:</p>
674+
<pre><code class="hljs makefile">CC = gcc <span class="hljs-comment"># Flag for implicit rules</span>
675+
CFLAGS = -g <span class="hljs-comment"># Flag for implicit rules. Turn on debug info</span>
676+
677+
<span class="hljs-comment"># Implicit rule #1: blah is built via the C linker implicit rule</span>
678+
<span class="hljs-comment"># Implicit rule #2: blah.o is built via the C compilation implicit rule, because blah.c exists</span>
679+
<span class="hljs-section">blah: blah.o</span>
680+
681+
<span class="hljs-section">blah.c:</span>
682+
echo <span class="hljs-string">"int main() { return 0; }"</span> &gt; blah.c
683+
684+
<span class="hljs-section">clean:</span>
685+
rm -f blah*</code></pre>
686+
656687
<h2 id="static-pattern-rules">Static Pattern Rules</h2>
657688
<!-- (Section 4.10) -->
658-
<p>Make loves c compilation. And every time it expresses its love, things get confusing. Here&#39;s the syntax for a new type of rule called a static pattern:</p>
689+
<p>Static pattern rules are another way to write less in a Makefile, but I&#39;d say are more useful and a bit less &quot;magic&quot;. Here&#39;s their syntax:</p>
659690
<pre><code class="hljs makefile">targets ...: target-pattern: prereq-patterns ...
660691
commands</code></pre>
661692

662-
<p>The essence is that the given target is matched by the target-pattern (via a <code>%</code> wildcard). Whatever was matched is called the <em>stem</em>. The stem is then substituted into the prereq-pattern, to generate the target&#39;s prereqs.</p>
693+
<p>The essence is that the given <code>target</code> is matched by the <code>target-pattern</code> (via a <code>%</code> wildcard). Whatever was matched is called the <em>stem</em>. The stem is then substituted into the <code>prereq-pattern</code>, to generate the target&#39;s prereqs.</p>
663694
<p>A typical use case is to compile <code>.c</code> files into <code>.o</code> files. Here&#39;s the <em>manual way</em>:</p>
664695
<pre><code class="hljs makefile">objects = foo.o bar.o all.o
665696
<span class="hljs-section">all: <span class="hljs-variable">$(objects)</span></span>
@@ -718,36 +749,6 @@ <h2 id="static-pattern-rules-and-filter">Static Pattern Rules and Filter</h2>
718749
rm -f <span class="hljs-variable">$(src_files)</span></code></pre>
719750

720751

721-
<h2 id="implicit-rules">Implicit Rules</h2>
722-
<!-- (Section 10) -->
723-
<p>Perhaps the most confusing part of make is the magic rules and variables that are made. Here&#39;s a list of implicit rules:</p>
724-
<ul>
725-
<li>Compiling a C program: <code>n.o</code> is made automatically from <code>n.c</code> with a command of the form <code>$(CC) -c $(CPPFLAGS) $(CFLAGS)</code></li>
726-
<li>Compiling a C++ program: <code>n.o</code> is made automatically from <code>n.cc</code> or <code>n.cpp</code> with a command of the form <code>$(CXX) -c $(CPPFLAGS) $(CXXFLAGS)</code></li>
727-
<li>Linking a single object file: <code>n</code> is made automatically from <code>n.o</code> by running the command <code>$(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)</code></li>
728-
</ul>
729-
<p>As such, the important variables used by implicit rules are:</p>
730-
<ul>
731-
<li><code>CC</code>: Program for compiling C programs; default cc</li>
732-
<li><code>CXX</code>: Program for compiling C++ programs; default G++</li>
733-
<li><code>CFLAGS</code>: Extra flags to give to the C compiler</li>
734-
<li><code>CXXFLAGS</code>: Extra flags to give to the C++ compiler</li>
735-
<li><code>CPPFLAGS</code>: Extra flags to give to the C preprocessor</li>
736-
<li><code>LDFLAGS</code>: Extra flags to give to compilers when they are supposed to invoke the linker</li>
737-
</ul>
738-
<pre><code class="hljs makefile">CC = gcc <span class="hljs-comment"># Flag for implicit rules</span>
739-
CFLAGS = -g <span class="hljs-comment"># Flag for implicit rules. Turn on debug info</span>
740-
741-
<span class="hljs-comment"># Implicit rule #1: blah is built via the C linker implicit rule</span>
742-
<span class="hljs-comment"># Implicit rule #2: blah.o is built via the C compilation implicit rule, because blah.c exists</span>
743-
<span class="hljs-section">blah: blah.o</span>
744-
745-
<span class="hljs-section">blah.c:</span>
746-
echo <span class="hljs-string">"int main() { return 0; }"</span> &gt; blah.c
747-
748-
<span class="hljs-section">clean:</span>
749-
rm -f blah*</code></pre>
750-
751752
<h2 id="pattern-rules">Pattern Rules</h2>
752753
<p>Pattern rules are often used but quite confusing. You can look at them as two ways:</p>
753754
<ul>

‎src/index.md

Lines changed: 33 additions & 33 deletions
Original file line numberDiff line numberDiff line change
@@ -276,15 +276,46 @@ clean:
276276
```
277277

278278
# Fancy Rules
279+
## Implicit Rules
280+
<!-- (Section 10) -->
281+
Make loves c compilation. And every time it expresses its love, things get confusing. Perhaps the most confusing part of Make is the magic/automatic rules that are made. Make calls these "implicit" rules. I don't personally agree with this design decision, and I don't recommend using them, but they're often used and are thus useful to know. Here's a list of implicit rules:
282+
- Compiling a C program: `n.o` is made automatically from `n.c` with a command of the form `$(CC) -c $(CPPFLAGS) $(CFLAGS)`
283+
- Compiling a C++ program: `n.o` is made automatically from `n.cc` or `n.cpp` with a command of the form `$(CXX) -c $(CPPFLAGS) $(CXXFLAGS)`
284+
- Linking a single object file: `n` is made automatically from `n.o` by running the command `$(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)`
285+
286+
The important variables used by implicit rules are:
287+
- `CC`: Program for compiling C programs; default `cc`
288+
- `CXX`: Program for compiling C++ programs; default `g++`
289+
- `CFLAGS`: Extra flags to give to the C compiler
290+
- `CXXFLAGS`: Extra flags to give to the C++ compiler
291+
- `CPPFLAGS`: Extra flags to give to the C preprocessor
292+
- `LDFLAGS`: Extra flags to give to compilers when they are supposed to invoke the linker
293+
294+
Let's see how we can now build a C program without ever explicitly telling Make how to do the compililation:
295+
```makefile
296+
CC = gcc # Flag for implicit rules
297+
CFLAGS = -g # Flag for implicit rules. Turn on debug info
298+
299+
# Implicit rule #1: blah is built via the C linker implicit rule
300+
# Implicit rule #2: blah.o is built via the C compilation implicit rule, because blah.c exists
301+
blah: blah.o
302+
303+
blah.c:
304+
echo "int main() { return 0; }" > blah.c
305+
306+
clean:
307+
rm -f blah*
308+
```
309+
279310
## Static Pattern Rules
280311
<!-- (Section 4.10) -->
281-
Make loves c compilation. And every time it expresses its love, things get confusing. Here's the syntax for a new type of rule called a static pattern:
312+
Static pattern rules are another way to write less in a Makefile, but I'd say are more useful and a bit less "magic". Here's their syntax:
282313
```makefile
283314
targets ...: target-pattern: prereq-patterns ...
284315
commands
285316
```
286317

287-
The essence is that the given target is matched by the target-pattern (via a `%` wildcard). Whatever was matched is called the *stem*. The stem is then substituted into the prereq-pattern, to generate the target's prereqs.
318+
The essence is that the given `target` is matched by the `target-pattern` (via a `%` wildcard). Whatever was matched is called the *stem*. The stem is then substituted into the `prereq-pattern`, to generate the target's prereqs.
288319

289320
A typical use case is to compile `.c` files into `.o` files. Here's the *manual way*:
290321
```makefile
@@ -351,37 +382,6 @@ clean:
351382
```
352383

353384

354-
## Implicit Rules
355-
<!-- (Section 10) -->
356-
Perhaps the most confusing part of make is the magic rules and variables that are made. Here's a list of implicit rules:
357-
- Compiling a C program: `n.o` is made automatically from `n.c` with a command of the form `$(CC) -c $(CPPFLAGS) $(CFLAGS)`
358-
- Compiling a C++ program: `n.o` is made automatically from `n.cc` or `n.cpp` with a command of the form `$(CXX) -c $(CPPFLAGS) $(CXXFLAGS)`
359-
- Linking a single object file: `n` is made automatically from `n.o` by running the command `$(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)`
360-
361-
As such, the important variables used by implicit rules are:
362-
- `CC`: Program for compiling C programs; default cc
363-
- `CXX`: Program for compiling C++ programs; default G++
364-
- `CFLAGS`: Extra flags to give to the C compiler
365-
- `CXXFLAGS`: Extra flags to give to the C++ compiler
366-
- `CPPFLAGS`: Extra flags to give to the C preprocessor
367-
- `LDFLAGS`: Extra flags to give to compilers when they are supposed to invoke the linker
368-
369-
370-
```makefile
371-
CC = gcc # Flag for implicit rules
372-
CFLAGS = -g # Flag for implicit rules. Turn on debug info
373-
374-
# Implicit rule #1: blah is built via the C linker implicit rule
375-
# Implicit rule #2: blah.o is built via the C compilation implicit rule, because blah.c exists
376-
blah: blah.o
377-
378-
blah.c:
379-
echo "int main() { return 0; }" > blah.c
380-
381-
clean:
382-
rm -f blah*
383-
```
384-
385385
## Pattern Rules
386386
Pattern rules are often used but quite confusing. You can look at them as two ways:
387387
- A way to define your own implicit rules

0 commit comments

Comments
 (0)