1 <sect1 id="separate-compilation">
2 <title>Filenames and separate compilation</title>
4 <indexterm><primary>separate compilation</primary></indexterm>
5 <indexterm><primary>recompilation checker</primary></indexterm>
6 <indexterm><primary>make and recompilation</primary></indexterm>
8 <para>This section describes what files GHC expects to find, what
9 files it creates, where these files are stored, and what options
10 affect this behaviour.</para>
12 <para>Note that this section is written with
13 <firstterm>hierarchical modules</firstterm> in mind (see <xref
14 linkend="hierarchical-modules">); hierarchical modules are an
15 extension to Haskell 98 which extends the lexical syntax of
16 module names to include a dot ‘.’. Non-hierarchical
17 modules are thus a special case in which none of the module names
20 <para>Pathname conventions vary from system to system. In
21 particular, the directory separator is
22 ‘<literal>/</literal>’ on Unix systems and
23 ‘<literal>\</literal>’ on Windows systems. In the
24 sections that follow, we shall consistently use
25 ‘<literal>/</literal>’ as the directory separator;
26 substitute this for the appropriate character for your
29 <sect2 id="source-files">
30 <title>Haskell source files</title>
32 <para>Each Haskell source module should be placed in a file on
35 <para>The file should usually be named after the module name, by
36 replacing dots in the module name by directory separators. For
37 example, on a Unix system, the module <literal>A.B.C</literal>
38 should be placed in the file <literal>A/B/C.hs</literal>,
39 relative to some base directory. GHC's behaviour if this rule
40 is not followed is fully defined by the following section (<xref
41 linkend="output-files">).</para>
44 <sect2 id="output-files">
45 <title>Output files</title>
47 <indexterm><primary>interface files</primary></indexterm>
48 <indexterm><primary><literal>.hi</literal> files</primary></indexterm>
49 <indexterm><primary>object files</primary></indexterm>
50 <indexterm><primary><literal>.o</literal> files</primary></indexterm>
52 <para>When asked to compile a source file, GHC normally
53 generates two files: an <firstterm>object file</firstterm>, and
54 an <firstterm>interface file</firstterm>. </para>
56 <para>The object file, which normally ends in a
57 <literal>.o</literal> suffix (or <literal>.obj</literal> if
58 you're on Windows), contains the compiled code for the module.</para>
60 <para>The interface file,
61 which normally ends in a <literal>.hi</literal> suffix, contains
62 the information that GHC needs in order to compile further
63 modules that depend on this module. It contains things like the
64 types of exported functions, definitions of data types, and so
65 on. It is stored in a binary format, so don't try to read one;
66 use the <option>--show-iface</option> option instead (see <xref
67 linkend="hi-options">).</para>
69 <para>You should think of the object file and the interface file as a
70 pair, since the interface file is in a sense a compiler-readable
71 description of the contents of the object file. If the
72 interface file and object file get out of sync for any reason,
73 then the compiler may end up making assumptions about the object
74 file that aren't true; trouble will almost certainly follow.
75 For this reason, we recommend keeping object files and interface
76 files in the same place (GHC does this by default, but it is
77 possible to override the defaults as we'll explain
80 <para>Every module has a <emphasis>module name</emphasis>
81 defined in its source code (<literal>module A.B.C where
82 ...</literal>).</para>
84 <para>The name of the object file generated by GHC is derived
85 according to the following rules, where
86 <replaceable>osuf</replaceable> is the object-file suffix (this
87 can be changed with the <option>-osuf</option> option).</para>
91 <para>If there is no <option>-odir</option> option (the
92 default), then the object filename is derived from the
93 source filename (ignoring the module name) by replacing the
94 suffix with <replaceable>osuf</replaceable>.</para>
98 <option>-odir</option> <replaceable>dir</replaceable>
99 has been specified, then the object filename is
100 <replaceable>dir</replaceable>/<replaceable>mod</replaceable>.<replaceable>osuf</replaceable>,
101 where <replaceable>mod</replaceable> is the module name with
102 dots replaced by slashes.</para>
106 <para>The name of the interface file is derived using the same
107 rules, except that the suffix is
108 <replaceable>hisuf</replaceable> (<literal>.hi</literal> by
109 default) instead of <replaceable>osuf</replaceable>, and the
110 relevant options are <option>-hidir</option> and
111 <option>-hisuf</option> instead of <option>-odir</option> and
112 <option>-osuf</option> respectively.</para>
114 <para>For example, if GHC compiles the module
115 <literal>A.B.C</literal> in the file
116 <filename>src/A/B/C.hs</filename>, with no
117 <literal>-odir</literal> or <literal>-hidir</literal> flags, the
118 interface file will be put in <literal>src/A/B/C.hi</literal>
119 and the object file in <literal>src/A/B/C.o</literal>.</para>
121 <para>For any module that is imported, GHC requires that the
122 name of the module in the import statement exactly matches the
123 name of the module in the interface file (or source file) found
124 using the strategy specified in <xref linkend="search-path">.
125 This means that for most modules, the source file name should
126 match the module name.</para>
128 <para>However, note that it is reasonable to have a module
129 <literal>Main</literal> in a file named
130 <filename>foo.hs</filename>, but this only works because GHC
131 never needs to search for the interface for module
132 <literal>Main</literal> (because it is never imported). It is
133 therefore possible to have several <literal>Main</literal>
134 modules in separate source files in the same directory, and GHC
135 will not get confused.</para>
137 <para>In batch compilation mode, the name of the object file can
138 also be overriden using the <option>-o</option> option, and the
139 name of the interface file can be specified directly using the
140 <option>-ohi</option> option.</para>
143 <sect2 id="search-path">
144 <title>The search path</title>
146 <indexterm><primary>search path</primary>
148 <indexterm><primary>interface files, finding them</primary></indexterm>
149 <indexterm><primary>finding interface files</primary></indexterm>
151 <para>In your program, you import a module
152 <literal>Foo</literal> by saying <literal>import Foo</literal>.
153 In <option>--make</option> mode or GHCi, GHC will look for a
154 source file for <literal>Foo</literal> and arrange to compile it
155 first. Without <option>--make</option>, GHC will look for the
156 interface file for <literal>Foo</literal>, which should have
157 been created by an earlier compilation of
158 <literal>Foo</literal>. GHC uses the same strategy in each of
159 these cases for finding the appropriate file.</para>
161 <para>This strategy is as follows: GHC keeps a list of
162 directories called the <firstterm>search path</firstterm>. For
163 each of these directories, it tries appending
164 <replaceable>basename</replaceable><literal>.</literal><replaceable>extension</replaceable>
165 to the directory, and checks whether the file exists. The value
166 of <replaceable>basename</replaceable> is the module name with
167 dots replaced by the directory separator ('/' or '\', depending
168 on the system), and <replaceable>extension</replaceable> is a
169 source extension (<literal>hs</literal>, <literal>lhs</literal>)
170 if we are in <option>--make</option> mode and GHCi, or
171 <replaceable>hisuf</replaceable> otherwise.</para>
173 <para>For example, suppose the search path contains directories
174 <literal>d1</literal>, <literal>d2</literal>, and
175 <literal>d3</literal>, and we are in <literal>--make</literal>
176 mode looking for the source file for a module
177 <literal>A.B.C</literal>. GHC will look in
178 <literal>d1/A/B/C.hs</literal>, <literal>d1/A/B/C.lhs</literal>,
179 <literal>d2/A/B/C.hs</literal>, and so on.</para>
181 <para>The search path by default contains a single directory:
182 <quote>.</quote> (i.e. the current directory). The following
183 options can be used to add to or change the contents of the
188 <term><option>-i<replaceable>dirs</replaceable></option></term>
190 <para><indexterm><primary><option>-i<replaceable>dirs</replaceable></option>
191 </primary></indexterm>This flag appends a colon-separated
192 list of <filename>dirs</filename> to the search path.</para>
197 <term><option>-i</option></term>
199 <para>resets the search path back to nothing.</para>
204 <para>This isn't the whole story: GHC also looks for modules in
205 pre-compiled libraries, known as packages. See the section on
206 packages (<xref linkend="packages">), for details.</para>
209 <sect2 id="options-output">
210 <title>Redirecting the compilation output(s)</title>
212 <indexterm><primary>output-directing options</primary></indexterm>
213 <indexterm><primary>redirecting compilation output</primary></indexterm>
217 <term><option>-o</option> <replaceable>file</replaceable></term>
218 <indexterm><primary><option>-o</option></primary></indexterm>
220 <para>GHC's compiled output normally goes into a
221 <filename>.hc</filename>, <filename>.o</filename>, etc.,
222 file, depending on the last-run compilation phase. The
223 option <option>-o <replaceable>file</replaceable></option>
224 re-directs the output of that last-run phase to
225 <replaceable>file</replaceable>.</para>
227 <para>Note: this “feature” can be
228 counterintuitive: <command>ghc -C -o foo.o
229 foo.hs</command> will put the intermediate C code in the
230 file <filename>foo.o</filename>, name
231 notwithstanding!</para>
233 <para>This option is most often used when creating an
234 executable file, to set the filename of the executable.
236 <screen> ghc -o prog --make Main</screen>
238 will compile the program starting with module
239 <literal>Main</literal> and put the executable in the
240 file <literal>prog</literal>.</para>
242 <para>Note: on Windows, if the result is an executable
243 file, the extension "<filename>.exe</filename>" is added
244 if the specified filename does not already have an
249 will compile and link the module
250 <filename>Main.hs</filename>, and put the resulting
251 executable in <filename>foo.exe</filename> (not
252 <filename>foo</filename>).</para>
257 <term><option>-odir</option> <replaceable>dir</replaceable></term>
258 <indexterm><primary><option>-odir</option></primary></indexterm>
260 <para>Redirects object files to directory
261 <replaceable>dir</replaceable>. For example:</para>
264 $ ghc -c parse/Foo.hs parse/Bar.hs gurgle/Bumble.hs -odir `arch`
267 <para>The object files, <filename>Foo.o</filename>,
268 <filename>Bar.o</filename>, and
269 <filename>Bumble.o</filename> would be put into a
270 subdirectory named after the architecture of the executing
271 machine (<filename>x86</filename>,
272 <filename>mips</filename>, etc).</para>
274 <para>Note that the <option>-odir</option> option does
275 <emphasis>not</emphasis> affect where the interface files
276 are put; use the <option>-hidir</option> option for that.
277 In the above example, they would still be put in
278 <filename>parse/Foo.hi</filename>,
279 <filename>parse/Bar.hi</filename>, and
280 <filename>gurgle/Bumble.hi</filename>.</para>
285 <term><option>-ohi</option> <replaceable>file</replaceable></term>
286 <indexterm><primary><option>-ohi</option></primary>
289 <para>The interface output may be directed to another file
290 <filename>bar2/Wurble.iface</filename> with the option
291 <option>-ohi bar2/Wurble.iface</option> (not
294 <para>WARNING: if you redirect the interface file
295 somewhere that GHC can't find it, then the recompilation
296 checker may get confused (at the least, you won't get any
297 recompilation avoidance). We recommend using a
298 combination of <option>-hidir</option> and
299 <option>-hisuf</option> options instead, if
302 <para>To avoid generating an interface at all, you could
303 use this option to redirect the interface into the bit
304 bucket: <literal>-ohi /dev/null</literal>, for
310 <term><option>-hidir</option> <replaceable>dir</replaceable></term>
311 <indexterm><primary><option>-hidir</option></primary>
314 <para>Redirects all generated interface files into
315 <replaceable>dir</replaceable>, instead of the
321 <term><option>-osuf</option> <replaceable>suffix</replaceable></term>
322 <term><option>-hisuf</option> <replaceable>suffix</replaceable></term>
323 <term><option>-hcsuf</option> <replaceable>suffix</replaceable></term>
324 <indexterm><primary><option>-osuf</option></primary></indexterm>
325 <indexterm><primary><option>-hisuf</option></primary></indexterm>
326 <indexterm><primary><option>-hcsuf</option></primary></indexterm>
328 <para>EXOTICA: The <option>-osuf</option>
329 <replaceable>suffix</replaceable> will change the
330 <literal>.o</literal> file suffix for object files to
331 whatever you specify. We use this when compiling
332 libraries, so that objects for the profiling versions of
333 the libraries don't clobber the normal ones.</para>
335 <para>Similarly, the <option>-hisuf</option>
336 <replaceable>suffix</replaceable> will change the
337 <literal>.hi</literal> file suffix for non-system
338 interface files (see <XRef LinkEnd="hi-options">).</para>
340 <para>Finally, the option <option>-hcsuf</option>
341 <replaceable>suffix</replaceable> will change the
342 <literal>.hc</literal> file suffix for compiler-generated
343 intermediate C files.</para>
345 <para>The <option>-hisuf</option>/<option>-osuf</option>
346 game is particularly useful if you want to compile a
347 program both with and without profiling, in the same
348 directory. You can say:
351 to get the ordinary version, and
353 ghc ... -osuf prof.o -hisuf prof.hi -prof -auto-all</Screen>
354 to get the profiled version.</para>
360 <sect2 id="keeping-intermediates">
361 <title>Keeping Intermediate Files</title>
362 <indexterm><primary>intermediate files, saving</primary>
364 <indexterm><primary><literal>.hc</literal> files, saving</primary>
366 <indexterm><primary><literal>.s</literal> files, saving</primary>
369 <para>The following options are useful for keeping certain
370 intermediate files around, when normally GHC would throw these
371 away after compilation:</para>
375 <term><option>-keep-hc-files</option></term>
377 <primary><option>-keep-hc-files</option></primary>
380 <para>Keep intermediate <literal>.hc</literal> files when
381 doing <literal>.hs</literal>-to-<literal>.o</literal>
382 compilations via C (NOTE: <literal>.hc</literal> files
383 aren't generated when using the native code generator, you
384 may need to use <option>-fvia-C</option> to force them
385 to be produced).</para>
390 <term><option>-keep-s-files</option></term>
392 <primary><option>-keep-s-files</option></primary>
395 <para>Keep intermediate <literal>.s</literal> files.</para>
400 <term><option>-keep-raw-s-files</option></term>
402 <primary><option>-keep-raw-s-files</option></primary>
405 <para>Keep intermediate <literal>.raw-s</literal> files.
406 These are the direct output from the C compiler, before
407 GHC does “assembly mangling” to produce the
408 <literal>.s</literal> file. Again, these are not produced
409 when using the native code generator.</para>
414 <term><option>-keep-tmp-files</option></term>
416 <primary><option>-keep-tmp-files</option></primary>
419 <primary>temporary files</primary>
420 <secondary>keeping</secondary>
423 <para>Instructs the GHC driver not to delete any of its
424 temporary files, which it normally keeps in
425 <literal>/tmp</literal> (or possibly elsewhere; see <xref
426 linkend="temp-files">). Running GHC with
427 <option>-v</option> will show you what temporary files
428 were generated along the way.</para>
434 <sect2 id="temp-files">
435 <title>Redirecting temporary files</title>
438 <primary>temporary files</primary>
439 <secondary>redirecting</secondary>
444 <term><option>-tmpdir</option></term>
445 <indexterm><primary><option>-tmpdir</option></primary></indexterm>
447 <para>If you have trouble because of running out of space
448 in <filename>/tmp</filename> (or wherever your
449 installation thinks temporary files should go), you may
450 use the <option>-tmpdir
451 <dir></option><IndexTerm><Primary>-tmpdir
452 <dir> option</Primary></IndexTerm> option to specify
453 an alternate directory. For example, <option>-tmpdir
454 .</option> says to put temporary files in the current
455 working directory.</para>
457 <para>Alternatively, use your <Constant>TMPDIR</Constant>
458 environment variable.<IndexTerm><Primary>TMPDIR
459 environment variable</Primary></IndexTerm> Set it to the
460 name of the directory where temporary files should be put.
461 GCC and other programs will honour the
462 <Constant>TMPDIR</Constant> variable as well.</para>
464 <para>Even better idea: Set the
465 <Constant>DEFAULT_TMPDIR</Constant> make variable when
466 building GHC, and never worry about
467 <Constant>TMPDIR</Constant> again. (see the build
468 documentation).</para>
474 <Sect2 id="hi-options">
475 <title>Other options related to interface files</title>
476 <indexterm><primary>interface files, options</primary></indexterm>
480 <term><option>-ddump-hi</option></term>
481 <indexterm><primary><option>-ddump-hi</option></primary>
484 <para>Dumps the new interface to standard output.</para>
489 <term><option>-ddump-hi-diffs</option></term>
490 <indexterm><primary><option>-ddump-hi-diffs</option></primary>
493 <para>The compiler does not overwrite an existing
494 <filename>.hi</filename> interface file if the new one is
495 the same as the old one; this is friendly to
496 <command>make</command>. When an interface does change,
497 it is often enlightening to be informed. The
498 <option>-ddump-hi-diffs</option> option will make GHC run
499 <command>diff</command> on the old and new
500 <filename>.hi</filename> files.</para>
505 <term><option>-ddump-minimal-imports</option></term>
506 <indexterm><primary><option>-ddump-minimal-imports</option></primary>
509 <para>Dump to the file "M.imports" (where M is the module
510 being compiled) a "minimal" set of import declarations.
511 You can safely replace all the import declarations in
512 "M.hs" with those found in "M.imports". Why would you
513 want to do that? Because the "minimal" imports (a) import
514 everything explicitly, by name, and (b) import nothing
515 that is not required. It can be quite painful to maintain
516 this property by hand, so this flag is intended to reduce
522 <term><option>--show-iface</option>
523 <replaceable>file</replaceable></term>
524 <indexterm><primary><option>--show-iface</option></primary>
527 <para>Where <replaceable>file</replaceable> is the name of
528 an interface file, dumps the contents of that interface in
529 a human-readable (ish) format.</para>
536 <title>The recompilation checker</title>
538 <indexterm><primary>recompilation checker</primary></indexterm>
542 <term><option>-no-recomp</option></term>
543 <indexterm><primary><option>-recomp</option></primary></indexterm>
544 <indexterm><primary><option>-no-recomp</option></primary></indexterm>
546 <para>Turn off recompilation checking (which is on by
547 default). Recompilation checking normally stops
548 compilation early, leaving an existing
549 <filename>.o</filename> file in place, if it can be
550 determined that the module does not need to be
556 <para>In the olden days, GHC compared the newly-generated
557 <filename>.hi</filename> file with the previous version; if they
558 were identical, it left the old one alone and didn't change its
559 modification date. In consequence, importers of a module with
560 an unchanged output <filename>.hi</filename> file were not
563 <para>This doesn't work any more. Suppose module
564 <literal>C</literal> imports module <literal>B</literal>, and
565 <literal>B</literal> imports module <literal>A</literal>. So
566 changes to module <literal>A</literal> might require module
567 <literal>C</literal> to be recompiled, and hence when
568 <filename>A.hi</filename> changes we should check whether
569 <literal>C</literal> should be recompiled. However, the
570 dependencies of <literal>C</literal> will only list
571 <literal>B.hi</literal>, not <literal>A.hi</literal>, and some
572 changes to <literal>A</literal> (changing the definition of a
573 function that appears in an inlining of a function exported by
574 <literal>B</literal>, say) may conceivably not change
575 <filename>B.hi</filename> one jot. So now…</para>
577 <para>GHC keeps a version number on each interface file, and on
578 each type signature within the interface file. It also keeps in
579 every interface file a list of the version numbers of everything
580 it used when it last compiled the file. If the source file's
581 modification date is earlier than the <filename>.o</filename>
582 file's date (i.e. the source hasn't changed since the file was
583 last compiled), and the reompilation checking is on, GHC will be
584 clever. It compares the version numbers on the things it needs
585 this time with the version numbers on the things it needed last
586 time (gleaned from the interface file of the module being
587 compiled); if they are all the same it stops compiling rather
588 early in the process saying “Compilation IS NOT
589 required”. What a beautiful sight!</para>
591 <para>Patrick Sansom had a workshop paper about how all this is
592 done (though the details have changed quite a bit). <ULink
593 URL="mailto:sansom@dcs.gla.ac.uk">Ask him</ULink> if you want a
598 <sect2 id="using-make">
599 <title>Using <command>make</command></title>
601 <indexterm><primary><literal>make</literal></primary></indexterm>
603 <para>It is reasonably straightforward to set up a
604 <filename>Makefile</filename> to use with GHC, assuming you name
605 your source files the same as your modules. Thus:</para>
609 HC_OPTS = -cpp $(EXTRA_HC_OPTS)
611 SRCS = Main.lhs Foo.lhs Bar.lhs
612 OBJS = Main.o Foo.o Bar.o
614 .SUFFIXES : .o .hs .hi .lhs .hc .s
618 $(HC) -o $@ $(HC_OPTS) $(OBJS)
620 # Standard suffix rules
625 $(HC) -c $< $(HC_OPTS)
628 $(HC) -c $< $(HC_OPTS)
630 # Inter-module dependencies
631 Foo.o Foo.hc Foo.s : Baz.hi # Foo imports Baz
632 Main.o Main.hc Main.s : Foo.hi Baz.hi # Main imports Foo and Baz
635 <para>(Sophisticated <command>make</command> variants may
636 achieve some of the above more elegantly. Notably,
637 <command>gmake</command>'s pattern rules let you write the more
638 comprehensible:</para>
642 $(HC) -c $< $(HC_OPTS)
645 <para>What we've shown should work with any
646 <command>make</command>.)</para>
648 <para>Note the cheesy <literal>.o.hi</literal> rule: It records
649 the dependency of the interface (<filename>.hi</filename>) file
650 on the source. The rule says a <filename>.hi</filename> file
651 can be made from a <filename>.o</filename> file by
652 doing…nothing. Which is true.</para>
654 <para>Note the inter-module dependencies at the end of the
655 Makefile, which take the form</para>
658 Foo.o Foo.hc Foo.s : Baz.hi # Foo imports Baz
661 <para>They tell <command>make</command> that if any of
662 <literal>Foo.o</literal>, <literal>Foo.hc</literal> or
663 <literal>Foo.s</literal> have an earlier modification date than
664 <literal>Baz.hi</literal>, then the out-of-date file must be
665 brought up to date. To bring it up to date,
666 <literal>make</literal> looks for a rule to do so; one of the
667 preceding suffix rules does the job nicely.</para>
669 <sect3 id="sec-makefile-dependencies">
670 <title>Dependency generation</title>
671 <indexterm><primary>dependencies in Makefiles</primary></indexterm>
672 <indexterm><primary>Makefile dependencies</primary></indexterm>
674 <para>Putting inter-dependencies of the form <literal>Foo.o :
675 Bar.hi</literal> into your <filename>Makefile</filename> by
676 hand is rather error-prone. Don't worry, GHC has support for
677 automatically generating the required dependencies. Add the
678 following to your <filename>Makefile</filename>:</para>
682 ghc -M $(HC_OPTS) $(SRCS)
685 <para>Now, before you start compiling, and any time you change
686 the <literal>imports</literal> in your program, do
687 <command>make depend</command> before you do <command>make
688 cool_pgm</command>. <command>ghc -M</command> will
689 append the needed dependencies to your
690 <filename>Makefile</filename>.</para>
692 <para>In general, if module <literal>A</literal> contains the
699 then <command>ghc -M</command> will generate a dependency line
706 If module <literal>A</literal> contains the line
709 import {-# SOURCE #-} B ...blah...
712 then <command>ghc -M</command> will generate a dependency
719 (See <xref linkend="mutual-recursion"> for details of
720 <literal>hi-boot</literal> style interface files.) If
721 <literal>A</literal> imports multiple modules, then there will
722 be multiple lines with <filename>A.o</filename> as the
725 <para>By default, <command>ghc -M</command> generates all the
726 dependencies, and then concatenates them onto the end of
727 <filename>makefile</filename> (or
728 <filename>Makefile</filename> if <filename>makefile</filename>
729 doesn't exist) bracketed by the lines "<literal># DO NOT
730 DELETE: Beginning of Haskell dependencies</literal>" and
731 "<literal># DO NOT DELETE: End of Haskell
732 dependencies</literal>". If these lines already exist in the
733 <filename>makefile</filename>, then the old dependencies are
734 deleted first.</para>
736 <para>Don't forget to use the same <option>-package</option>
737 options on the <literal>ghc -M</literal> command line as you
738 would when compiling; this enables the dependency generator to
739 locate any imported modules that come from packages. The
740 package modules won't be included in the dependencies
741 generated, though (but see the
742 <option>––include-prelude</option> option below).</para>
744 <para>The dependency generation phase of GHC can take some
745 additional options, which you may find useful. For historical
746 reasons, each option passed to the dependency generator from
747 the GHC command line must be preceded by
748 <literal>-optdep</literal>. For example, to pass <literal>-f
749 .depend</literal> to the dependency generator, you say
752 ghc -M -optdep-f -optdep.depend ...
755 The options which affect dependency generation are:</para>
759 <term><option>-w</option></term>
761 <para>Turn off warnings about interface file shadowing.</para>
766 <term><option>-f</option> <replaceable>file</replaceable></term>
768 <para>Use <replaceable>file</replaceable> as the makefile,
769 rather than <filename>makefile</filename> or
770 <filename>Makefile</filename>. If
771 <replaceable>file</replaceable> doesn't exist,
772 <command>mkdependHS</command> creates it. We often use
773 <option>-f .depend</option> to put the dependencies in
774 <filename>.depend</filename> and then
775 <command>include</command> the file
776 <filename>.depend</filename> into
777 <filename>Makefile</filename>.</para>
782 <term><option>-o <osuf></option></term>
784 <para>Use <filename>.<osuf></filename> as the
785 "target file" suffix ( default: <literal>o</literal>).
786 Multiple <option>-o</option> flags are permitted
787 (GHC2.05 onwards). Thus "<option>-o hc -o o</option>"
788 will generate dependencies for <filename>.hc</filename>
789 and <filename>.o</filename> files.</para>
794 <term><option>-s <suf></option></term>
796 <para>Make extra dependencies that declare that files
798 <filename>.<suf>_<osuf></filename>
799 depend on interface files with suffix
800 <filename>.<suf>_hi</filename>, or (for
801 <literal>{-# SOURCE #-}</literal>
802 imports) on <filename>.hi-boot</filename>. Multiple
803 <option>-s</option> flags are permitted. For example,
804 <option>-o hc -s a -s b</option> will make dependencies
805 for <filename>.hc</filename> on
806 <filename>.hi</filename>,
807 <filename>.a_hc</filename> on
808 <filename>.a_hi</filename>, and
809 <filename>.b_hc</filename> on
810 <filename>.b_hi</filename>. (Useful in
811 conjunction with NoFib "ways".)</para>
816 <term><option>––exclude-module=<file></option></term>
818 <para>Regard <filename><file></filename> as
819 "stable"; i.e., exclude it from having dependencies on
825 <term><option>-x</option></term>
827 <para>same as <option>––exclude-module</option></para>
832 <term><option>––exclude-directory=<dirs></option></term>
834 <para>Regard the colon-separated list of directories
835 <filename><dirs></filename> as containing stable,
836 don't generate any dependencies on modules
842 <term><option>––include-module=<file></option></term>
844 <para>Regard <filename><file></filename> as not
845 "stable"; i.e., generate dependencies on it (if
846 any). This option is normally used in conjunction with
847 the <option>––exclude-directory</option> option.</para>
852 <term><option>––include-prelude</option></term>
854 <para>Regard modules imported from packages as unstable,
855 i.e., generate dependencies on the package modules used
856 (including <literal>Prelude</literal>, and all other
857 standard Haskell libraries). This option is normally
858 only used by the various system libraries.</para>
866 <sect2 id="mutual-recursion">
867 <title>How to compile mutually recursive modules</title>
869 <indexterm><primary>module system, recursion</primary></indexterm>
870 <indexterm><primary>recursion, between modules</primary></indexterm>
872 <para>Currently, the compiler does not have proper support for
873 dealing with mutually recursive modules:</para>
880 newtype TA = MkTA Int
895 <para>When compiling either module A and B, the compiler will
896 try (in vain) to look for the interface file of the other. So,
897 to get mutually recursive modules off the ground, you need to
898 hand write an interface file for A or B, so as to break the
899 loop. These hand-written interface files are called
900 <literal>hi-boot</literal> files, and are placed in a file
901 called <filename><module>.hi-boot</filename>. To import
902 from an <literal>hi-boot</literal> file instead of the standard
903 <filename>.hi</filename> file, use the following syntax in the
904 importing module: <indexterm><primary><literal>hi-boot</literal>
905 files</primary></indexterm> <indexterm><primary>importing,
906 <literal>hi-boot</literal> files</primary></indexterm></para>
909 import {-# SOURCE #-} A
912 <para>The hand-written interface need only contain the bare
913 minimum of information needed to get the bootstrapping process
914 started. For example, it doesn't need to contain declarations
915 for <emphasis>everything</emphasis> that module
916 <literal>A</literal> exports, only the things required by the
917 module that imports <literal>A</literal> recursively.</para>
919 <para>For the example at hand, the boot interface file for A
920 would look like the following:</para>
924 newtype TA = MkTA GHC.Base.Int
927 <para>The syntax is similar to a normal Haskell source file, but
928 with some important differences:</para>
932 <para>Non-local entities must be qualified with their
933 <emphasis>original</emphasis> defining module. Qualifying
934 by a module which just re-exports the entity won't do. In
935 particular, most <literal>Prelude</literal> entities aren't
936 actually defined in the <literal>Prelude</literal> (see for
937 example <literal>GHC.Base.Int</literal> in the above
938 example). HINT: to find out the fully-qualified name for
939 entities in the <literal>Prelude</literal> (or anywhere for
940 that matter), try using GHCi's
941 <literal>:info</literal> command, eg.</para>
942 <programlisting>Prelude> :m -Prelude
944 -- GHC.IOBase.IO is a type constructor
945 newtype GHC.IOBase.IO a
949 <para>Only <literal>data</literal>, <literal>type</literal>,
950 <literal>newtype</literal>, <literal>class</literal>, and
951 type signature declarations may be included. You cannot declare
952 <literal>instances</literal> or derive them automatically.
956 <listitem> <para>For <literal>data</literal> or <literal>newtype</literal> declaration, you may omit all
957 the constructors, by omitting the '=' and everything that follows it:
962 In a <emphasis>source</emphasis> program
963 this would declare TA to have no constructors (a GHC extension: see <xref linkend="nullary-types">),
964 but in an hi-boot file it means "I don't know or care what the construtors are".
965 This is the most common form of data type declaration, because it's easy to get right.</para>
967 You <emphasis>can</emphasis> also write out the constructors but, if you do so, you must write
968 it out precisely as in its real definition.
969 It is especially delicate if you use a strictness annotation "!",
970 with or without an <literal>{-# UNPACK #-}</literal> pragma. In a source file
971 GHC may or may not choose to unbox the argument, but in an hi-boot file it's
972 assumed that you express the <emphasis>outcome</emphasis> of this decision.
973 (So in the cases where GHC decided not to unpack, you must not use the pragma.)
974 Tread with care.</para>
976 Regardless of whether you write the constructors, you must write all the type parameters,
977 <emphasis>including their kinds</emphasis>
978 if they are not '*'. (You can give explicit kinds in source files too (<xref linkend="sec-kinding">),
979 but you <emphasis>must</emphasis> do so in hi-boot files.)</para>
982 <listitem> <para>For <literal>class</literal> declaration, you may not specify any class
983 operations. We could lift this restriction if it became tiresome.</para>
987 <para>Notice that we only put the declaration for the newtype
988 <literal>TA</literal> in the <literal>hi-boot</literal> file,
989 not the signature for <Function>f</Function>, since
990 <Function>f</Function> isn't used by <literal>B</literal>.</para>
995 <sect2 id="orphan-modules">
996 <title>Orphan modules and instance declarations</title>
998 <para> Haskell specifies that when compiling module M, any instance
999 declaration in any module "below" M is visible. (Module A is "below"
1000 M if A is imported directly by M, or if A is below a module that M imports directly.)
1001 In principle, GHC must therefore read the interface files of every module below M,
1002 just in case they contain an instance declaration that matters to M. This would
1003 be a disaster in practice, so GHC tries to be clever. </para>
1005 <para>In particular, if an instance declaration is in the same module as the definition
1006 of any type or class mentioned in the head of the instance declaration, then
1007 GHC has to visit that interface file anyway. Example:</para>
1010 instance C a => D (T a) where ...
1013 <para> The instance declaration is only relevant if the type T is in use, and if
1014 so, GHC will have visited A's interface file to find T's definition. </para>
1016 <para> The only problem comes when a module contains an instance declaration
1017 and GHC has no other reason for visiting the module. Example:
1020 instance C a => D (T a) where ...
1023 Here, neither D nor T is declared in module Orphan.
1024 We call such modules ``orphan modules'',
1025 defined thus:</para>
1027 <listitem> <para> An <emphasis>orphan module</emphasis>
1028 <indexterm><primary>orphan module</primary></indexterm>
1029 contains at least one <emphasis>orphan instance</emphasis> or at
1030 least one <emphasis>orphan rule</emphasis>.</para> </listitem>
1032 <listitem><para> An instance declaration in a module M is an <emphasis>orphan instance</emphasis> if
1033 <indexterm><primary>orphan instance</primary></indexterm>
1034 none of the type constructors
1035 or classes mentioned in the instance head (the part after the ``<literal>=></literal>'') are declared
1038 <para> Only the instance head counts. In the example above, it is not good enough for C's declaration
1039 to be in module A; it must be the declaration of D or T.</para>
1042 <listitem><para> A rewrite rule in a module M is an <emphasis>orphan rule</emphasis>
1043 <indexterm><primary>orphan rule</primary></indexterm>
1044 if none of the variables, type constructors,
1045 or classes that are free in the left hand side of the rule are declared in M.
1050 <para> GHC identifies orphan modules, and visits the interface file of
1051 every orphan module below the module being compiled. This is usually
1052 wasted work, but there is no avoiding it. You should therefore do
1053 your best to have as few orphan modules as possible.
1057 <para> You can identify an orphan module by looking in its interface
1058 file, <filename>M.hi</filename>, using the
1059 <option>--show-iface</option>. If there is a ``!'' on the first line,
1060 GHC considers it an orphan module.
1067 ;;; Local Variables: ***
1069 ;;; sgml-parent-document: ("using.sgml" "book" "chapter") ***