Remove dead code, now that -fvia-c is a no-op
[ghc.git] / docs / users_guide / separate_compilation.xml
1 <?xml version="1.0" encoding="iso-8859-1"?>
2 <sect1 id="separate-compilation">
3 <title>Filenames and separate compilation</title>
4
5 <indexterm><primary>separate compilation</primary></indexterm>
6 <indexterm><primary>recompilation checker</primary></indexterm>
7 <indexterm><primary>make and recompilation</primary></indexterm>
8
9 <para>This section describes what files GHC expects to find, what
10 files it creates, where these files are stored, and what options
11 affect this behaviour.</para>
12
13 <para>Note that this section is written with
14 <firstterm>hierarchical modules</firstterm> in mind (see <xref
15 linkend="hierarchical-modules"/>); hierarchical modules are an
16 extension to Haskell 98 which extends the lexical syntax of
17 module names to include a dot &lsquo;.&rsquo;. Non-hierarchical
18 modules are thus a special case in which none of the module names
19 contain dots.</para>
20
21 <para>Pathname conventions vary from system to system. In
22 particular, the directory separator is
23 &lsquo;<literal>/</literal>&rsquo; on Unix systems and
24 &lsquo;<literal>\</literal>&rsquo; on Windows systems. In the
25 sections that follow, we shall consistently use
26 &lsquo;<literal>/</literal>&rsquo; as the directory separator;
27 substitute this for the appropriate character for your
28 system.</para>
29
30 <sect2 id="source-files">
31 <title>Haskell source files</title>
32
33 <indexterm><primary>filenames</primary></indexterm>
34
35 <para>Each Haskell source module should be placed in a file on
36 its own.</para>
37
38 <para>Usually, the file should be named after the module name,
39 replacing dots in the module name by directory separators. For
40 example, on a Unix system, the module <literal>A.B.C</literal>
41 should be placed in the file <literal>A/B/C.hs</literal>,
42 relative to some base directory. If the module is not going to
43 be imported by another module (<literal>Main</literal>, for
44 example), then you are free to use any filename for it.</para>
45
46 <indexterm><primary>unicode</primary></indexterm>
47
48 <para> GHC assumes that source files are
49 ASCII<indexterm><primary>ASCII</primary></indexterm> or
50 UTF-8<indexterm><primary>UTF-8</primary></indexterm> only, other
51 encodings<indexterm><primary>encoding</primary></indexterm> are
52 not recognised. However, invalid UTF-8 sequences will be
53 ignored in comments, so it is possible to use other encodings
54 such as
55 Latin-1<indexterm><primary>Latin-1</primary></indexterm>, as
56 long as the non-comment source code is ASCII only.</para>
57 </sect2>
58
59 <sect2 id="output-files">
60 <title>Output files</title>
61
62 <indexterm><primary>interface files</primary></indexterm>
63 <indexterm><primary><literal>.hi</literal> files</primary></indexterm>
64 <indexterm><primary>object files</primary></indexterm>
65 <indexterm><primary><literal>.o</literal> files</primary></indexterm>
66
67 <para>When asked to compile a source file, GHC normally
68 generates two files: an <firstterm>object file</firstterm>, and
69 an <firstterm>interface file</firstterm>. </para>
70
71 <para>The object file, which normally ends in a
72 <literal>.o</literal> suffix, contains the compiled code for the
73 module.</para>
74
75 <para>The interface file,
76 which normally ends in a <literal>.hi</literal> suffix, contains
77 the information that GHC needs in order to compile further
78 modules that depend on this module. It contains things like the
79 types of exported functions, definitions of data types, and so
80 on. It is stored in a binary format, so don't try to read one;
81 use the <option>--show-iface</option> option instead (see <xref
82 linkend="hi-options"/>).</para>
83
84 <para>You should think of the object file and the interface file as a
85 pair, since the interface file is in a sense a compiler-readable
86 description of the contents of the object file. If the
87 interface file and object file get out of sync for any reason,
88 then the compiler may end up making assumptions about the object
89 file that aren't true; trouble will almost certainly follow.
90 For this reason, we recommend keeping object files and interface
91 files in the same place (GHC does this by default, but it is
92 possible to override the defaults as we'll explain
93 shortly).</para>
94
95 <para>Every module has a <emphasis>module name</emphasis>
96 defined in its source code (<literal>module A.B.C where
97 ...</literal>).</para>
98
99 <para>The name of the object file generated by GHC is derived
100 according to the following rules, where
101 <replaceable>osuf</replaceable> is the object-file suffix (this
102 can be changed with the <option>-osuf</option> option).</para>
103
104 <itemizedlist>
105 <listitem>
106 <para>If there is no <option>-odir</option> option (the
107 default), then the object filename is derived from the
108 source filename (ignoring the module name) by replacing the
109 suffix with <replaceable>osuf</replaceable>.</para>
110 </listitem>
111 <listitem>
112 <para>If
113 <option>-odir</option>&nbsp;<replaceable>dir</replaceable>
114 has been specified, then the object filename is
115 <replaceable>dir</replaceable>/<replaceable>mod</replaceable>.<replaceable>osuf</replaceable>,
116 where <replaceable>mod</replaceable> is the module name with
117 dots replaced by slashes. GHC will silently create the necessary directory
118 structure underneath <replaceable>dir</replaceable>, if it does not
119 already exist.</para>
120 </listitem>
121 </itemizedlist>
122
123 <para>The name of the interface file is derived using the same
124 rules, except that the suffix is
125 <replaceable>hisuf</replaceable> (<literal>.hi</literal> by
126 default) instead of <replaceable>osuf</replaceable>, and the
127 relevant options are <option>-hidir</option> and
128 <option>-hisuf</option> instead of <option>-odir</option> and
129 <option>-osuf</option> respectively.</para>
130
131 <para>For example, if GHC compiles the module
132 <literal>A.B.C</literal> in the file
133 <filename>src/A/B/C.hs</filename>, with no
134 <literal>-odir</literal> or <literal>-hidir</literal> flags, the
135 interface file will be put in <literal>src/A/B/C.hi</literal>
136 and the object file in <literal>src/A/B/C.o</literal>.</para>
137
138 <para>For any module that is imported, GHC requires that the
139 name of the module in the import statement exactly matches the
140 name of the module in the interface file (or source file) found
141 using the strategy specified in <xref linkend="search-path"/>.
142 This means that for most modules, the source file name should
143 match the module name.</para>
144
145 <para>However, note that it is reasonable to have a module
146 <literal>Main</literal> in a file named
147 <filename>foo.hs</filename>, but this only works because GHC
148 never needs to search for the interface for module
149 <literal>Main</literal> (because it is never imported). It is
150 therefore possible to have several <literal>Main</literal>
151 modules in separate source files in the same directory, and GHC
152 will not get confused.</para>
153
154 <para>In batch compilation mode, the name of the object file can
155 also be overridden using the <option>-o</option> option, and the
156 name of the interface file can be specified directly using the
157 <option>-ohi</option> option.</para>
158 </sect2>
159
160 <sect2 id="search-path">
161 <title>The search path</title>
162
163 <indexterm><primary>search path</primary>
164 </indexterm>
165 <indexterm><primary>interface files, finding them</primary></indexterm>
166 <indexterm><primary>finding interface files</primary></indexterm>
167
168 <para>In your program, you import a module
169 <literal>Foo</literal> by saying <literal>import Foo</literal>.
170 In <option>--make</option> mode or GHCi, GHC will look for a
171 source file for <literal>Foo</literal> and arrange to compile it
172 first. Without <option>--make</option>, GHC will look for the
173 interface file for <literal>Foo</literal>, which should have
174 been created by an earlier compilation of
175 <literal>Foo</literal>. GHC uses the same strategy in each of
176 these cases for finding the appropriate file.</para>
177
178 <para>This strategy is as follows: GHC keeps a list of
179 directories called the <firstterm>search path</firstterm>. For
180 each of these directories, it tries appending
181 <replaceable>basename</replaceable><literal>.</literal><replaceable>extension</replaceable>
182 to the directory, and checks whether the file exists. The value
183 of <replaceable>basename</replaceable> is the module name with
184 dots replaced by the directory separator ('/' or '\', depending
185 on the system), and <replaceable>extension</replaceable> is a
186 source extension (<literal>hs</literal>, <literal>lhs</literal>)
187 if we are in <option>--make</option> mode or GHCi, or
188 <replaceable>hisuf</replaceable> otherwise.</para>
189
190 <para>For example, suppose the search path contains directories
191 <literal>d1</literal>, <literal>d2</literal>, and
192 <literal>d3</literal>, and we are in <literal>--make</literal>
193 mode looking for the source file for a module
194 <literal>A.B.C</literal>. GHC will look in
195 <literal>d1/A/B/C.hs</literal>, <literal>d1/A/B/C.lhs</literal>,
196 <literal>d2/A/B/C.hs</literal>, and so on.</para>
197
198 <para>The search path by default contains a single directory:
199 <quote>.</quote> (i.e. the current directory). The following
200 options can be used to add to or change the contents of the
201 search path:</para>
202
203 <variablelist>
204 <varlistentry>
205 <term><option>-i<replaceable>dirs</replaceable></option></term>
206 <listitem>
207 <para><indexterm><primary><option>-i<replaceable>dirs</replaceable></option>
208 </primary></indexterm>This flag appends a colon-separated
209 list of <filename>dirs</filename> to the search path.</para>
210 </listitem>
211 </varlistentry>
212
213 <varlistentry>
214 <term><option>-i</option></term>
215 <listitem>
216 <para>resets the search path back to nothing.</para>
217 </listitem>
218 </varlistentry>
219 </variablelist>
220
221 <para>This isn't the whole story: GHC also looks for modules in
222 pre-compiled libraries, known as packages. See the section on
223 packages (<xref linkend="packages"/>) for details.</para>
224 </sect2>
225
226 <sect2 id="options-output">
227 <title>Redirecting the compilation output(s)</title>
228
229 <indexterm><primary>output-directing options</primary></indexterm>
230 <indexterm><primary>redirecting compilation output</primary></indexterm>
231
232 <variablelist>
233 <varlistentry>
234 <term>
235 <option>-o</option> <replaceable>file</replaceable>
236 <indexterm><primary><option>-o</option></primary></indexterm>
237 </term>
238 <listitem>
239 <para>GHC's compiled output normally goes into a
240 <filename>.hc</filename>, <filename>.o</filename>, etc.,
241 file, depending on the last-run compilation phase. The
242 option <option>-o <replaceable>file</replaceable></option>
243 re-directs the output of that last-run phase to
244 <replaceable>file</replaceable>.</para>
245
246 <para>Note: this &ldquo;feature&rdquo; can be
247 counterintuitive: <command>ghc -C -o foo.o
248 foo.hs</command> will put the intermediate C code in the
249 file <filename>foo.o</filename>, name
250 notwithstanding!</para>
251
252 <para>This option is most often used when creating an
253 executable file, to set the filename of the executable.
254 For example:
255 <screen> ghc -o prog --make Main</screen>
256
257 will compile the program starting with module
258 <literal>Main</literal> and put the executable in the
259 file <literal>prog</literal>.</para>
260
261 <para>Note: on Windows, if the result is an executable
262 file, the extension "<filename>.exe</filename>" is added
263 if the specified filename does not already have an
264 extension. Thus
265 <programlisting>
266 ghc -o foo Main.hs
267 </programlisting>
268 will compile and link the module
269 <filename>Main.hs</filename>, and put the resulting
270 executable in <filename>foo.exe</filename> (not
271 <filename>foo</filename>).</para>
272
273 <para>If you use <command>ghc --make</command> and you don't
274 use the <option>-o</option>, the name GHC will choose
275 for the executable will be based on the name of the file
276 containing the module <literal>Main</literal>.
277 Note that with GHC the <literal>Main</literal> module doesn't
278 have to be put in file <filename>Main.hs</filename>.
279 Thus both
280 <programlisting>
281 ghc --make Prog
282 </programlisting>
283 and
284 <programlisting>
285 ghc --make Prog.hs
286 </programlisting>
287 will produce <filename>Prog</filename> (or
288 <filename>Prog.exe</filename> if you are on Windows).</para>
289 </listitem>
290 </varlistentry>
291
292 <varlistentry>
293 <term>
294 <option>-odir</option> <replaceable>dir</replaceable>
295 <indexterm><primary><option>-odir</option></primary></indexterm>
296 </term>
297 <listitem>
298 <para>Redirects object files to directory
299 <replaceable>dir</replaceable>. For example:</para>
300
301 <screen>
302 $ ghc -c parse/Foo.hs parse/Bar.hs gurgle/Bumble.hs -odir `uname -m`
303 </screen>
304
305 <para>The object files, <filename>Foo.o</filename>,
306 <filename>Bar.o</filename>, and
307 <filename>Bumble.o</filename> would be put into a
308 subdirectory named after the architecture of the executing
309 machine (<filename>x86</filename>,
310 <filename>mips</filename>, etc).</para>
311
312 <para>Note that the <option>-odir</option> option does
313 <emphasis>not</emphasis> affect where the interface files
314 are put; use the <option>-hidir</option> option for that.
315 In the above example, they would still be put in
316 <filename>parse/Foo.hi</filename>,
317 <filename>parse/Bar.hi</filename>, and
318 <filename>gurgle/Bumble.hi</filename>.</para>
319 </listitem>
320 </varlistentry>
321
322 <varlistentry>
323 <term>
324 <option>-ohi</option> <replaceable>file</replaceable>
325 <indexterm><primary><option>-ohi</option></primary></indexterm>
326 </term>
327 <listitem>
328 <para>The interface output may be directed to another file
329 <filename>bar2/Wurble.iface</filename> with the option
330 <option>-ohi bar2/Wurble.iface</option> (not
331 recommended).</para>
332
333 <para>WARNING: if you redirect the interface file
334 somewhere that GHC can't find it, then the recompilation
335 checker may get confused (at the least, you won't get any
336 recompilation avoidance). We recommend using a
337 combination of <option>-hidir</option> and
338 <option>-hisuf</option> options instead, if
339 possible.</para>
340
341 <para>To avoid generating an interface at all, you could
342 use this option to redirect the interface into the bit
343 bucket: <literal>-ohi /dev/null</literal>, for
344 example.</para>
345 </listitem>
346 </varlistentry>
347
348 <varlistentry>
349 <term>
350 <option>-hidir</option> <replaceable>dir</replaceable>
351 <indexterm><primary><option>-hidir</option></primary></indexterm>
352 </term>
353 <listitem>
354 <para>Redirects all generated interface files into
355 <replaceable>dir</replaceable>, instead of the
356 default.</para>
357 </listitem>
358 </varlistentry>
359
360 <varlistentry>
361 <term>
362 <option>-stubdir</option> <replaceable>dir</replaceable>
363 <indexterm><primary><option>-stubdir</option></primary></indexterm>
364 </term>
365 <listitem>
366 <para>Redirects all generated FFI stub files into
367 <replaceable>dir</replaceable>. Stub files are generated when the
368 Haskell source contains a <literal>foreign export</literal> or
369 <literal>foreign import "&amp;wrapper"</literal> declaration (see <xref
370 linkend="foreign-export-ghc" />). The <option>-stubdir</option>
371 option behaves in exactly the same way as <option>-odir</option>
372 and <option>-hidir</option> with respect to hierarchical
373 modules.</para>
374 </listitem>
375 </varlistentry>
376
377 <varlistentry>
378 <term>
379 <option>-outputdir</option> <replaceable>dir</replaceable>
380 <indexterm><primary><option>-outputdir</option></primary></indexterm>
381 </term>
382 <listitem>
383 <para>The <option>-outputdir</option> option is shorthand for
384 the combination
385 of <option>-odir</option>, <option>-hidir</option>,
386 and <option>-stubdir</option>.
387 </para>
388 </listitem>
389 </varlistentry>
390
391 <varlistentry>
392 <term>
393 <option>-osuf</option> <replaceable>suffix</replaceable>
394 <indexterm><primary><option>-osuf</option></primary></indexterm>
395 </term>
396 <term>
397 <option>-hisuf</option> <replaceable>suffix</replaceable>
398 <indexterm><primary><option>-hisuf</option></primary></indexterm>
399 </term>
400 <term>
401 <option>-hcsuf</option> <replaceable>suffix</replaceable>
402 <indexterm><primary><option>-hcsuf</option></primary></indexterm>
403 </term>
404 <listitem>
405 <para>The <option>-osuf</option>
406 <replaceable>suffix</replaceable> will change the
407 <literal>.o</literal> file suffix for object files to
408 whatever you specify. We use this when compiling
409 libraries, so that objects for the profiling versions of
410 the libraries don't clobber the normal ones.</para>
411
412 <para>Similarly, the <option>-hisuf</option>
413 <replaceable>suffix</replaceable> will change the
414 <literal>.hi</literal> file suffix for non-system
415 interface files (see <xref linkend="hi-options"/>).</para>
416
417 <para>Finally, the option <option>-hcsuf</option>
418 <replaceable>suffix</replaceable> will change the
419 <literal>.hc</literal> file suffix for compiler-generated
420 intermediate C files.</para>
421
422 <para>The <option>-hisuf</option>/<option>-osuf</option>
423 game is particularly useful if you want to compile a
424 program both with and without profiling, in the same
425 directory. You can say:
426 <screen>
427 ghc ...</screen>
428 to get the ordinary version, and
429 <screen>
430 ghc ... -osuf prof.o -hisuf prof.hi -prof -auto-all</screen>
431 to get the profiled version.</para>
432 </listitem>
433 </varlistentry>
434 </variablelist>
435 </sect2>
436
437 <sect2 id="keeping-intermediates">
438 <title>Keeping Intermediate Files</title>
439 <indexterm><primary>intermediate files, saving</primary>
440 </indexterm>
441 <indexterm><primary><literal>.hc</literal> files, saving</primary>
442 </indexterm>
443 <indexterm><primary><literal>.ll</literal> files, saving</primary>
444 </indexterm>
445 <indexterm><primary><literal>.s</literal> files, saving</primary>
446 </indexterm>
447
448 <para>The following options are useful for keeping certain
449 intermediate files around, when normally GHC would throw these
450 away after compilation:</para>
451
452 <variablelist>
453 <varlistentry>
454 <term>
455 <option>-keep-hc-file</option>,
456 <option>-keep-hc-files</option>
457 <indexterm><primary><option>-keep-hc-file</option></primary></indexterm>
458 <indexterm><primary><option>-keep-hc-files</option></primary></indexterm>
459 </term>
460 <listitem>
461 <para>Keep intermediate <literal>.hc</literal> files when
462 doing <literal>.hs</literal>-to-<literal>.o</literal>
463 compilations via C (NOTE: <literal>.hc</literal> files
464 are only generated by unregisterised compilers).</para>
465 </listitem>
466 </varlistentry>
467
468 <varlistentry>
469 <term>
470 <option>-keep-llvm-file</option>,
471 <option>-keep-llvm-files</option>
472 <indexterm><primary><option>-keep-llvm-file</option></primary></indexterm>
473 <indexterm><primary><option>-keep-llvm-files</option></primary></indexterm>
474 </term>
475 <listitem>
476 <para>Keep intermediate <literal>.ll</literal> files when
477 doing <literal>.hs</literal>-to-<literal>.o</literal>
478 compilations via LLVM (NOTE: <literal>.ll</literal> files
479 aren't generated when using the native code generator, you
480 may need to use <option>-fllvm</option> to force them
481 to be produced).</para>
482 </listitem>
483 </varlistentry>
484
485 <varlistentry>
486 <term>
487 <option>-keep-s-file</option>,
488 <option>-keep-s-files</option>
489 <indexterm><primary><option>-keep-s-file</option></primary></indexterm>
490 <indexterm><primary><option>-keep-s-files</option></primary></indexterm>
491 </term>
492 <listitem>
493 <para>Keep intermediate <literal>.s</literal> files.</para>
494 </listitem>
495 </varlistentry>
496
497 <varlistentry>
498 <term>
499 <option>-keep-tmp-files</option>
500 <indexterm><primary><option>-keep-tmp-files</option></primary></indexterm>
501 <indexterm><primary>temporary files</primary><secondary>keeping</secondary></indexterm>
502 </term>
503 <listitem>
504 <para>Instructs the GHC driver not to delete any of its
505 temporary files, which it normally keeps in
506 <literal>/tmp</literal> (or possibly elsewhere; see <xref
507 linkend="temp-files"/>). Running GHC with
508 <option>-v</option> will show you what temporary files
509 were generated along the way.</para>
510 </listitem>
511 </varlistentry>
512 </variablelist>
513 </sect2>
514
515 <sect2 id="temp-files">
516 <title>Redirecting temporary files</title>
517
518 <indexterm>
519 <primary>temporary files</primary>
520 <secondary>redirecting</secondary>
521 </indexterm>
522
523 <variablelist>
524 <varlistentry>
525 <term>
526 <option>-tmpdir</option>
527 <indexterm><primary><option>-tmpdir</option></primary></indexterm>
528 </term>
529 <listitem>
530 <para>If you have trouble because of running out of space
531 in <filename>/tmp</filename> (or wherever your
532 installation thinks temporary files should go), you may
533 use the <option>-tmpdir
534 &lt;dir&gt;</option><indexterm><primary>-tmpdir
535 &lt;dir&gt; option</primary></indexterm> option to specify
536 an alternate directory. For example, <option>-tmpdir
537 .</option> says to put temporary files in the current
538 working directory.</para>
539
540 <para>Alternatively, use your <constant>TMPDIR</constant>
541 environment variable.<indexterm><primary>TMPDIR
542 environment variable</primary></indexterm> Set it to the
543 name of the directory where temporary files should be put.
544 GCC and other programs will honour the
545 <constant>TMPDIR</constant> variable as well.</para>
546
547 <para>Even better idea: Set the
548 <constant>DEFAULT_TMPDIR</constant> make variable when
549 building GHC, and never worry about
550 <constant>TMPDIR</constant> again. (see the build
551 documentation).</para>
552 </listitem>
553 </varlistentry>
554 </variablelist>
555 </sect2>
556
557 <sect2 id="hi-options">
558 <title>Other options related to interface files</title>
559 <indexterm><primary>interface files, options</primary></indexterm>
560
561 <variablelist>
562 <varlistentry>
563 <term>
564 <option>-ddump-hi</option>
565 <indexterm><primary><option>-ddump-hi</option></primary></indexterm>
566 </term>
567 <listitem>
568 <para>Dumps the new interface to standard output.</para>
569 </listitem>
570 </varlistentry>
571
572 <varlistentry>
573 <term>
574 <option>-ddump-hi-diffs</option>
575 <indexterm><primary><option>-ddump-hi-diffs</option></primary></indexterm>
576 </term>
577 <listitem>
578 <para>The compiler does not overwrite an existing
579 <filename>.hi</filename> interface file if the new one is
580 the same as the old one; this is friendly to
581 <command>make</command>. When an interface does change,
582 it is often enlightening to be informed. The
583 <option>-ddump-hi-diffs</option> option will make GHC
584 report the differences between the old and
585 new <filename>.hi</filename> files.</para>
586 </listitem>
587 </varlistentry>
588
589 <varlistentry>
590 <term>
591 <option>-ddump-minimal-imports</option>
592 <indexterm><primary><option>-ddump-minimal-imports</option></primary></indexterm>
593 </term>
594 <listitem>
595 <para>Dump to the file "M.imports" (where M is the module
596 being compiled) a "minimal" set of import declarations.
597 You can safely replace all the import declarations in
598 "M.hs" with those found in "M.imports". Why would you
599 want to do that? Because the "minimal" imports (a) import
600 everything explicitly, by name, and (b) import nothing
601 that is not required. It can be quite painful to maintain
602 this property by hand, so this flag is intended to reduce
603 the labour.</para>
604 </listitem>
605 </varlistentry>
606
607 <varlistentry>
608 <term>
609 <option>--show-iface</option> <replaceable>file</replaceable>
610 <indexterm><primary><option>--show-iface</option></primary></indexterm>
611 </term>
612 <listitem>
613 <para>where <replaceable>file</replaceable> is the name of
614 an interface file, dumps the contents of that interface in
615 a human-readable (ish) format. See <xref linkend="modes"/>.</para>
616 </listitem>
617 </varlistentry>
618 </variablelist>
619 </sect2>
620
621 <sect2 id="recomp">
622 <title>The recompilation checker</title>
623
624 <indexterm><primary>recompilation checker</primary></indexterm>
625
626 <variablelist>
627 <varlistentry>
628 <term>
629 <option>-fforce-recomp</option>
630 <indexterm><primary><option>-fforce-recomp</option></primary></indexterm>
631 <indexterm><primary><option>-fno-force-recomp</option></primary></indexterm>
632 </term>
633 <listitem>
634 <para>Turn off recompilation checking (which is on by
635 default). Recompilation checking normally stops
636 compilation early, leaving an existing
637 <filename>.o</filename> file in place, if it can be
638 determined that the module does not need to be
639 recompiled.</para>
640 </listitem>
641 </varlistentry>
642 </variablelist>
643
644 <para>In the olden days, GHC compared the newly-generated
645 <filename>.hi</filename> file with the previous version; if they
646 were identical, it left the old one alone and didn't change its
647 modification date. In consequence, importers of a module with
648 an unchanged output <filename>.hi</filename> file were not
649 recompiled.</para>
650
651 <para>This doesn't work any more. Suppose module
652 <literal>C</literal> imports module <literal>B</literal>, and
653 <literal>B</literal> imports module <literal>A</literal>. So
654 changes to module <literal>A</literal> might require module
655 <literal>C</literal> to be recompiled, and hence when
656 <filename>A.hi</filename> changes we should check whether
657 <literal>C</literal> should be recompiled. However, the
658 dependencies of <literal>C</literal> will only list
659 <literal>B.hi</literal>, not <literal>A.hi</literal>, and some
660 changes to <literal>A</literal> (changing the definition of a
661 function that appears in an inlining of a function exported by
662 <literal>B</literal>, say) may conceivably not change
663 <filename>B.hi</filename> one jot. So now&hellip;</para>
664
665 <para>GHC calculates a fingerprint (in fact an MD5 hash) of each
666 interface file, and of each declaration within the interface
667 file. It also keeps in every interface file a list of the
668 fingerprints of everything it used when it last compiled the
669 file. If the source file's modification date is earlier than
670 the <filename>.o</filename> file's date (i.e. the source hasn't
671 changed since the file was last compiled), and the recompilation
672 checking is on, GHC will be clever. It compares the fingerprints
673 on the things it needs this time with the fingerprints
674 on the things it needed last time (gleaned from the
675 interface file of the module being compiled); if they are all
676 the same it stops compiling early in the process saying
677 &ldquo;Compilation IS NOT required&rdquo;. What a beautiful
678 sight!</para>
679
680 <para>You can read
681 about <ulink url="http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/RecompilationAvoidance">how
682 all this works</ulink> in the GHC commentary.</para>
683
684 </sect2>
685
686 <sect2 id="mutual-recursion">
687 <title>How to compile mutually recursive modules</title>
688
689 <indexterm><primary>module system, recursion</primary></indexterm>
690 <indexterm><primary>recursion, between modules</primary></indexterm>
691
692 <para>GHC supports the compilation of mutually recursive modules.
693 This section explains how.</para>
694
695 <para>Every cycle in the module import graph must be broken by a <filename>hs-boot</filename> file.
696 Suppose that modules <filename>A.hs</filename> and <filename>B.hs</filename> are Haskell source files,
697 thus:
698 <programlisting>
699 module A where
700 import B( TB(..) )
701
702 newtype TA = MkTA Int
703
704 f :: TB -&#62; TA
705 f (MkTB x) = MkTA x
706
707 module B where
708 import {-# SOURCE #-} A( TA(..) )
709
710 data TB = MkTB !Int
711
712 g :: TA -&#62; TB
713 g (MkTA x) = MkTB x
714 </programlisting>
715 <indexterm><primary><literal>hs-boot</literal>
716 files</primary></indexterm> <indexterm><primary>importing,
717 <literal>hi-boot</literal> files</primary></indexterm>
718 Here <filename>A</filename> imports <filename>B</filename>, but <filename>B</filename> imports
719 <filename>A</filename> with a <literal>{-# SOURCE #-}</literal> pragma, which breaks the
720 circular dependency. Every loop in the module import graph must be broken by a <literal>{-# SOURCE #-}</literal> import;
721 or, equivalently, the module import graph must be acyclic if <literal>{-# SOURCE #-}</literal> imports are ignored.
722 </para>
723 <para>For every module <filename>A.hs</filename> that is <literal>{-# SOURCE #-}</literal>-imported
724 in this way there must exist a source file <literal>A.hs-boot</literal>. This file contains an abbreviated
725 version of <filename>A.hs</filename>, thus:
726 <programlisting>
727 module A where
728 newtype TA = MkTA Int
729 </programlisting>
730 </para>
731 <para>To compile these three files, issue the following commands:
732 <programlisting>
733 ghc -c A.hs-boot -- Produces A.hi-boot, A.o-boot
734 ghc -c B.hs -- Consumes A.hi-boot, produces B.hi, B.o
735 ghc -c A.hs -- Consumes B.hi, produces A.hi, A.o
736 ghc -o foo A.o B.o -- Linking the program
737 </programlisting>
738 </para>
739 <para>There are several points to note here:
740 <itemizedlist>
741 <listitem>
742 <para>The file <filename>A.hs-boot</filename> is a programmer-written source file.
743 It must live in the same directory as its parent source file <filename>A.hs</filename>.
744 Currently, if you use a literate source file <filename>A.lhs</filename> you must
745 also use a literate boot file, <filename>A.lhs-boot</filename>; and vice versa.
746 </para></listitem>
747
748 <listitem><para>
749 A <filename>hs-boot</filename> file is compiled by GHC, just like a <filename>hs</filename> file:
750 <programlisting>
751 ghc -c A.hs-boot
752 </programlisting>
753 When a hs-boot file <filename>A.hs-boot</filename>
754 is compiled, it is checked for scope and type errors.
755 When its parent module <filename>A.hs</filename> is compiled, the two are compared, and
756 an error is reported if the two are inconsistent.
757 </para></listitem>
758
759 <listitem>
760 <para> Just as compiling <filename>A.hs</filename> produces an
761 interface file <filename>A.hi</filename>, and an object file
762 <filename>A.o</filename>, so compiling
763 <filename>A.hs-boot</filename> produces an interface file
764 <filename>A.hi-boot</filename>, and an pseudo-object file
765 <filename>A.o-boot</filename>: </para>
766
767 <itemizedlist>
768 <listitem>
769 <para>The pseudo-object file <filename>A.o-boot</filename> is
770 empty (don't link it!), but it is very useful when using a
771 Makefile, to record when the <filename>A.hi-boot</filename> was
772 last brought up to date (see <xref
773 linkend="using-make"/>).</para>
774 </listitem>
775
776 <listitem>
777 <para>The <filename>hi-boot</filename> generated by compiling a
778 <filename>hs-boot</filename> file is in the same
779 machine-generated binary format as any other GHC-generated
780 interface file (e.g. <filename>B.hi</filename>). You can
781 display its contents with <command>ghc
782 --show-iface</command>. If you specify a directory for
783 interface files, the <option>-ohidir</option> flag, then that
784 affects <filename>hi-boot</filename> files
785 too.</para>
786 </listitem>
787 </itemizedlist>
788 </listitem>
789
790 <listitem><para> If hs-boot files are considered distinct from their parent source
791 files, and if a <literal>{-# SOURCE #-}</literal> import is considered to refer to the
792 hs-boot file, then the module import graph must have no cycles. The command
793 <command>ghc -M</command> will report an error if a cycle is found.
794 </para></listitem>
795
796 <listitem><para> A module <literal>M</literal> that is
797 <literal>{-# SOURCE #-}</literal>-imported in a program will usually also be
798 ordinarily imported elsewhere. If not, <command>ghc --make</command>
799 automatically adds <literal>M</literal> to the set of modules it tries to
800 compile and link, to ensure that <literal>M</literal>'s implementation is included in
801 the final program.
802 </para></listitem>
803 </itemizedlist>
804 </para>
805 <para>
806 A hs-boot file need only contain the bare
807 minimum of information needed to get the bootstrapping process
808 started. For example, it doesn't need to contain declarations
809 for <emphasis>everything</emphasis> that module
810 <literal>A</literal> exports, only the things required by the
811 module(s) that import <literal>A</literal> recursively.</para>
812 <para>A hs-boot file is written in a subset of Haskell:
813 <itemizedlist>
814 <listitem><para> The module header (including the export list), and import statements, are exactly as in
815 Haskell, and so are the scoping rules.
816 Hence, to mention a non-Prelude type or class, you must import it.</para></listitem>
817
818 <listitem><para> There must be no value declarations, but there can be type signatures for
819 values. For example:
820 <programlisting>
821 double :: Int -&#62; Int
822 </programlisting>
823 </para></listitem>
824 <listitem><para> Fixity declarations are exactly as in Haskell.</para></listitem>
825 <listitem><para> Type synonym declarations are exactly as in Haskell.</para></listitem>
826 <listitem><para> A data type declaration can either be given in full, exactly as in Haskell, or it
827 can be given abstractly, by omitting the '=' sign and everything that follows. For example:
828 <programlisting>
829 data T a b
830 </programlisting>
831 In a <emphasis>source</emphasis> program
832 this would declare TA to have no constructors (a GHC extension: see <xref linkend="nullary-types"/>),
833 but in an hi-boot file it means "I don't know or care what the constructors are".
834 This is the most common form of data type declaration, because it's easy to get right.
835 You <emphasis>can</emphasis> also write out the constructors but, if you do so, you must write
836 it out precisely as in its real definition.</para>
837 <para>
838 If you do not write out the constructors, you may need to give a kind
839 annotation (<xref linkend="kinding"/>), to tell
840 GHC the kind of the type variable, if it is not "*". (In source files, this is worked out
841 from the way the type variable is used in the constructors.) For example:
842 <programlisting>
843 data R (x :: * -&#62; *) y
844 </programlisting>
845 You cannot use <literal>deriving</literal> on a data type declaration; write an
846 <literal>instance</literal> declaration instead.
847 </para></listitem>
848 <listitem><para> Class declarations is exactly as in Haskell, except that you may not put
849 default method declarations. You can also omit all the superclasses and class
850 methods entirely; but you must either omit them all or put them all in.
851 </para></listitem>
852 <listitem><para> You can include instance declarations just as in Haskell; but omit the "where" part.
853 </para></listitem>
854 </itemizedlist>
855 </para>
856 </sect2>
857
858
859 <sect2 id="using-make">
860 <title>Using <command>make</command></title>
861
862 <indexterm><primary><literal>make</literal></primary></indexterm>
863
864 <para>It is reasonably straightforward to set up a
865 <filename>Makefile</filename> to use with GHC, assuming you name
866 your source files the same as your modules. Thus:</para>
867
868 <programlisting>
869 HC = ghc
870 HC_OPTS = -cpp $(EXTRA_HC_OPTS)
871
872 SRCS = Main.lhs Foo.lhs Bar.lhs
873 OBJS = Main.o Foo.o Bar.o
874
875 .SUFFIXES : .o .hs .hi .lhs .hc .s
876
877 cool_pgm : $(OBJS)
878 rm -f $@
879 $(HC) -o $@ $(HC_OPTS) $(OBJS)
880
881 # Standard suffix rules
882 .o.hi:
883 @:
884
885 .lhs.o:
886 $(HC) -c $&#60; $(HC_OPTS)
887
888 .hs.o:
889 $(HC) -c $&#60; $(HC_OPTS)
890
891 .o-boot.hi-boot:
892 @:
893
894 .lhs-boot.o-boot:
895 $(HC) -c $&#60; $(HC_OPTS)
896
897 .hs-boot.o-boot:
898 $(HC) -c $&#60; $(HC_OPTS)
899
900 # Inter-module dependencies
901 Foo.o Foo.hc Foo.s : Baz.hi # Foo imports Baz
902 Main.o Main.hc Main.s : Foo.hi Baz.hi # Main imports Foo and Baz
903 </programlisting>
904
905 <para>(Sophisticated <command>make</command> variants may
906 achieve some of the above more elegantly. Notably,
907 <command>gmake</command>'s pattern rules let you write the more
908 comprehensible:</para>
909
910 <programlisting>
911 %.o : %.lhs
912 $(HC) -c $&#60; $(HC_OPTS)
913 </programlisting>
914
915 <para>What we've shown should work with any
916 <command>make</command>.)</para>
917
918 <para>Note the cheesy <literal>.o.hi</literal> rule: It records
919 the dependency of the interface (<filename>.hi</filename>) file
920 on the source. The rule says a <filename>.hi</filename> file
921 can be made from a <filename>.o</filename> file by
922 doing&hellip;nothing. Which is true.</para>
923 <para> Note that the suffix rules are all repeated twice, once
924 for normal Haskell source files, and once for <filename>hs-boot</filename>
925 files (see <xref linkend="mutual-recursion"/>).</para>
926
927 <para>Note also the inter-module dependencies at the end of the
928 Makefile, which take the form
929
930 <programlisting>
931 Foo.o Foo.hc Foo.s : Baz.hi # Foo imports Baz
932 </programlisting>
933
934 They tell <command>make</command> that if any of
935 <literal>Foo.o</literal>, <literal>Foo.hc</literal> or
936 <literal>Foo.s</literal> have an earlier modification date than
937 <literal>Baz.hi</literal>, then the out-of-date file must be
938 brought up to date. To bring it up to date,
939 <literal>make</literal> looks for a rule to do so; one of the
940 preceding suffix rules does the job nicely. These dependencies
941 can be generated automatically by <command>ghc</command>; see
942 <xref linkend="makefile-dependencies"/></para>
943
944 </sect2>
945
946 <sect2 id="makefile-dependencies">
947 <title>Dependency generation</title>
948 <indexterm><primary>dependencies in Makefiles</primary></indexterm>
949 <indexterm><primary>Makefile dependencies</primary></indexterm>
950
951 <para>Putting inter-dependencies of the form <literal>Foo.o :
952 Bar.hi</literal> into your <filename>Makefile</filename> by
953 hand is rather error-prone. Don't worry, GHC has support for
954 automatically generating the required dependencies. Add the
955 following to your <filename>Makefile</filename>:</para>
956
957 <programlisting>
958 depend :
959 ghc -M $(HC_OPTS) $(SRCS)
960 </programlisting>
961
962 <para>Now, before you start compiling, and any time you change
963 the <literal>imports</literal> in your program, do
964 <command>make depend</command> before you do <command>make
965 cool&lowbar;pgm</command>. The command <command>ghc -M</command> will
966 append the needed dependencies to your
967 <filename>Makefile</filename>.</para>
968
969 <para>In general, <command>ghc -M Foo</command> does the following.
970 For each module <literal>M</literal> in the set
971 <literal>Foo</literal> plus all its imports (transitively),
972 it adds to the Makefile:
973 <itemizedlist>
974 <listitem><para>A line recording the dependence of the object file on the source file.
975 <programlisting>
976 M.o : M.hs
977 </programlisting>
978 (or <literal>M.lhs</literal> if that is the filename you used).
979 </para></listitem>
980 <listitem><para> For each import declaration <literal>import X</literal> in <literal>M</literal>,
981 a line recording the dependence of <literal>M</literal> on <literal>X</literal>:
982 <programlisting>
983 M.o : X.hi
984 </programlisting></para></listitem>
985 <listitem><para> For each import declaration <literal>import {-# SOURCE #-} X</literal> in <literal>M</literal>,
986 a line recording the dependence of <literal>M</literal> on <literal>X</literal>:
987 <programlisting>
988 M.o : X.hi-boot
989 </programlisting>
990 (See <xref linkend="mutual-recursion"/> for details of
991 <literal>hi-boot</literal> style interface files.)
992 </para></listitem>
993 </itemizedlist>
994 If <literal>M</literal> imports multiple modules, then there will
995 be multiple lines with <filename>M.o</filename> as the
996 target.</para>
997 <para>There is no need to list all of the source files as arguments to the <command>ghc -M</command> command;
998 <command>ghc</command> traces the dependencies, just like <command>ghc --make</command>
999 (a new feature in GHC 6.4).</para>
1000
1001 <para>Note that <literal>ghc -M</literal> needs to find a <emphasis>source
1002 file</emphasis> for each module in the dependency graph, so that it can
1003 parse the import declarations and follow dependencies. Any pre-compiled
1004 modules without source files must therefore belong to a
1005 package<footnote><para>This is a change in behaviour relative to 6.2 and
1006 earlier.</para>
1007 </footnote>.</para>
1008
1009 <para>By default, <command>ghc -M</command> generates all the
1010 dependencies, and then concatenates them onto the end of
1011 <filename>makefile</filename> (or
1012 <filename>Makefile</filename> if <filename>makefile</filename>
1013 doesn't exist) bracketed by the lines "<literal>&num; DO NOT
1014 DELETE: Beginning of Haskell dependencies</literal>" and
1015 "<literal>&num; DO NOT DELETE: End of Haskell
1016 dependencies</literal>". If these lines already exist in the
1017 <filename>makefile</filename>, then the old dependencies are
1018 deleted first.</para>
1019
1020 <para>Don't forget to use the same <option>-package</option>
1021 options on the <literal>ghc -M</literal> command line as you
1022 would when compiling; this enables the dependency generator to
1023 locate any imported modules that come from packages. The
1024 package modules won't be included in the dependencies
1025 generated, though (but see the
1026 <option>&ndash;&ndash;include-pkg-deps</option> option below).</para>
1027
1028 <para>The dependency generation phase of GHC can take some
1029 additional options, which you may find useful.
1030
1031 The options which affect dependency generation are:</para>
1032
1033 <variablelist>
1034 <varlistentry>
1035 <term><option>-ddump-mod-cycles</option></term>
1036 <listitem>
1037 <para>Display a list of the cycles in the module graph. This is
1038 useful when trying to eliminate such cycles.</para>
1039 </listitem>
1040 </varlistentry>
1041
1042 <varlistentry>
1043 <term><option>-v2</option></term>
1044 <listitem>
1045 <para>Print a full list of the module dependencies to stdout.
1046 (This is the standard verbosity flag, so the list will
1047 also be displayed with <option>-v3</option> and
1048 <option>-v4</option>;
1049 <xref linkend ="options-help"/>.)</para>
1050 </listitem>
1051 </varlistentry>
1052
1053 <varlistentry>
1054 <term><option>-dep-makefile</option> <replaceable>file</replaceable></term>
1055 <listitem>
1056 <para>Use <replaceable>file</replaceable> as the makefile,
1057 rather than <filename>makefile</filename> or
1058 <filename>Makefile</filename>. If
1059 <replaceable>file</replaceable> doesn't exist,
1060 <command>mkdependHS</command> creates it. We often use
1061 <option>-dep-makefile .depend</option> to put the dependencies in
1062 <filename>.depend</filename> and then
1063 <command>include</command> the file
1064 <filename>.depend</filename> into
1065 <filename>Makefile</filename>.</para>
1066 </listitem>
1067 </varlistentry>
1068
1069 <varlistentry>
1070 <term><option>-dep-suffix &lt;suf&gt;</option></term>
1071 <listitem>
1072 <para>Make extra dependencies that declare that files
1073 with suffix
1074 <filename>.&lt;suf&gt;&lowbar;&lt;osuf&gt;</filename>
1075 depend on interface files with suffix
1076 <filename>.&lt;suf&gt;&lowbar;hi</filename>, or (for
1077 <literal>&lcub;-&num; SOURCE &num;-&rcub;</literal>
1078 imports) on <filename>.hi-boot</filename>. Multiple
1079 <option>-dep-suffix</option> flags are permitted. For example,
1080 <option>-dep-suffix a -dep-suffix b</option>
1081 will make dependencies
1082 for <filename>.hs</filename> on
1083 <filename>.hi</filename>,
1084 <filename>.a&lowbar;hs</filename> on
1085 <filename>.a&lowbar;hi</filename>, and
1086 <filename>.b&lowbar;hs</filename> on
1087 <filename>.b&lowbar;hi</filename>. (Useful in
1088 conjunction with NoFib "ways".)</para>
1089 </listitem>
1090 </varlistentry>
1091
1092 <varlistentry>
1093 <term><option>&ndash;&ndash;exclude-module=&lt;file&gt;</option></term>
1094 <listitem>
1095 <para>Regard <filename>&lt;file&gt;</filename> as
1096 "stable"; i.e., exclude it from having dependencies on
1097 it.</para>
1098 </listitem>
1099 </varlistentry>
1100
1101 <varlistentry>
1102 <term><option>&ndash;&ndash;include-pkg-deps</option></term>
1103 <listitem>
1104 <para>Regard modules imported from packages as unstable,
1105 i.e., generate dependencies on any imported package modules
1106 (including <literal>Prelude</literal>, and all other
1107 standard Haskell libraries). Dependencies are not traced
1108 recursively into packages; dependencies are only generated for
1109 home-package modules on external-package modules directly imported
1110 by the home package module.
1111 This option is normally
1112 only used by the various system libraries.</para>
1113 </listitem>
1114 </varlistentry>
1115 </variablelist>
1116
1117 </sect2>
1118
1119 <sect2 id="orphan-modules">
1120 <title>Orphan modules and instance declarations</title>
1121
1122 <para> Haskell specifies that when compiling module M, any instance
1123 declaration in any module "below" M is visible. (Module A is "below"
1124 M if A is imported directly by M, or if A is below a module that M imports directly.)
1125 In principle, GHC must therefore read the interface files of every module below M,
1126 just in case they contain an instance declaration that matters to M. This would
1127 be a disaster in practice, so GHC tries to be clever. </para>
1128
1129 <para>In particular, if an instance declaration is in the same module as the definition
1130 of any type or class mentioned in the <emphasis>head</emphasis> of the instance declaration
1131 (the part after the &ldquo;<literal>=&gt;</literal>&rdquo;; see <xref linkend="instance-rules"/>), then
1132 GHC has to visit that interface file anyway. Example:</para>
1133 <programlisting>
1134 module A where
1135 instance C a =&gt; D (T a) where ...
1136 data T a = ...
1137 </programlisting>
1138 <para> The instance declaration is only relevant if the type T is in use, and if
1139 so, GHC will have visited A's interface file to find T's definition. </para>
1140
1141 <para> The only problem comes when a module contains an instance declaration
1142 and GHC has no other reason for visiting the module. Example:
1143 <programlisting>
1144 module Orphan where
1145 instance C a =&gt; D (T a) where ...
1146 class C a where ...
1147 </programlisting>
1148 Here, neither D nor T is declared in module Orphan.
1149 We call such modules &ldquo;orphan modules&rdquo;.
1150 GHC identifies orphan modules, and visits the interface file of
1151 every orphan module below the module being compiled. This is usually
1152 wasted work, but there is no avoiding it. You should therefore do
1153 your best to have as few orphan modules as possible.
1154 </para>
1155 <para>
1156 Functional dependencies complicate matters. Suppose we have:
1157 <programlisting>
1158 module B where
1159 instance E T Int where ...
1160 data T = ...
1161 </programlisting>
1162 Is this an orphan module? Apparently not, because <literal>T</literal>
1163 is declared in the same module. But suppose class <literal>E</literal> had a
1164 functional dependency:
1165 <programlisting>
1166 module Lib where
1167 class E x y | y -> x where ...
1168 </programlisting>
1169 Then in some importing module M, the constraint <literal>(E a Int)</literal> should be "improved" by setting
1170 <literal>a = T</literal>, <emphasis>even though there is no explicit mention
1171 of <literal>T</literal> in M</emphasis>.</para>
1172
1173 These considerations lead to the following definition of an orphan module:
1174 <itemizedlist>
1175 <listitem> <para> An <emphasis>orphan module</emphasis>
1176 <indexterm><primary>orphan module</primary></indexterm>
1177 contains at least one <emphasis>orphan instance</emphasis> or at
1178 least one <emphasis>orphan rule</emphasis>.</para> </listitem>
1179
1180 <listitem><para> An instance declaration in a module M is an <emphasis>orphan instance</emphasis> if
1181 <indexterm><primary>orphan instance</primary></indexterm>
1182 <itemizedlist>
1183 <listitem><para>
1184 The class of the instance declaration is not declared in M, and
1185 </para></listitem>
1186 <listitem>
1187 <para> <emphasis>Either</emphasis> the class has no functional dependencies, and none of the type constructors
1188 in the instance head is declared in M; <emphasis>or</emphasis> there
1189 is a functional dependency for which none of the type constructors mentioned
1190 in the <emphasis>non-determined</emphasis> part of the instance head is defined in M.
1191 </para></listitem>
1192 </itemizedlist>
1193 </para>
1194 <para> Only the instance head
1195 counts. In the example above, it is not good enough for C's declaration
1196 to be in module A; it must be the declaration of D or T.</para>
1197 </listitem>
1198
1199 <listitem><para> A rewrite rule in a module M is an <emphasis>orphan rule</emphasis>
1200 <indexterm><primary>orphan rule</primary></indexterm>
1201 if none of the variables, type constructors,
1202 or classes that are free in the left hand side of the rule are declared in M.
1203 </para> </listitem>
1204 </itemizedlist>
1205
1206
1207
1208 <para>If you use the flag <option>-fwarn-orphans</option>, GHC will warn you
1209 if you are creating an orphan module.
1210 Like any warning, you can switch the warning off with <option>-fno-warn-orphans</option>,
1211 and <option>-Werror</option>
1212 will make the compilation fail if the warning is issued.
1213 </para>
1214 <para>
1215 You can identify an orphan module by looking in its interface
1216 file, <filename>M.hi</filename>, using the
1217 <link linkend="modes"><option>--show-iface</option> mode</link>. If there is a <literal>[orphan module]</literal> on the
1218 first line, GHC considers it an orphan module.
1219 </para>
1220 </sect2>
1221
1222 </sect1>
1223
1224 <!-- Emacs stuff:
1225 ;;; Local Variables: ***
1226 ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter" "sect1") ***
1227 ;;; End: ***
1228 -->