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