1 <?xml version="1.0" encoding="iso-8859-1"?>
2 <sect1 id="separate-compilation">
3 <title>Filenames and separate compilation</title>
5 <indexterm><primary>separate compilation</primary></indexterm>
6 <indexterm><primary>recompilation checker</primary></indexterm>
7 <indexterm><primary>make and recompilation</primary></indexterm>
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>
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 ‘.’. Non-hierarchical
18 modules are thus a special case in which none of the module names
21 <para>Pathname conventions vary from system to system. In
22 particular, the directory separator is
23 ‘<literal>/</literal>’ on Unix systems and
24 ‘<literal>\</literal>’ on Windows systems. In the
25 sections that follow, we shall consistently use
26 ‘<literal>/</literal>’ as the directory separator;
27 substitute this for the appropriate character for your
30 <sect2 id="source-files">
31 <title>Haskell source files</title>
33 <para>Each Haskell source module should be placed in a file on
36 <para>The file should usually be named after the module name, by
37 replacing dots in the module name by directory separators. For
38 example, on a Unix system, the module <literal>A.B.C</literal>
39 should be placed in the file <literal>A/B/C.hs</literal>,
40 relative to some base directory. GHC's behaviour if this rule
41 is not followed is fully defined by the following section (<xref
42 linkend="output-files"/>).</para>
45 <sect2 id="output-files">
46 <title>Output files</title>
48 <indexterm><primary>interface files</primary></indexterm>
49 <indexterm><primary><literal>.hi</literal> files</primary></indexterm>
50 <indexterm><primary>object files</primary></indexterm>
51 <indexterm><primary><literal>.o</literal> files</primary></indexterm>
53 <para>When asked to compile a source file, GHC normally
54 generates two files: an <firstterm>object file</firstterm>, and
55 an <firstterm>interface file</firstterm>. </para>
57 <para>The object file, which normally ends in a
58 <literal>.o</literal> suffix (or <literal>.obj</literal> if
59 you're on Windows), contains the compiled code for the module.</para>
61 <para>The interface file,
62 which normally ends in a <literal>.hi</literal> suffix, contains
63 the information that GHC needs in order to compile further
64 modules that depend on this module. It contains things like the
65 types of exported functions, definitions of data types, and so
66 on. It is stored in a binary format, so don't try to read one;
67 use the <option>--show-iface</option> option instead (see <xref
68 linkend="hi-options"/>).</para>
70 <para>You should think of the object file and the interface file as a
71 pair, since the interface file is in a sense a compiler-readable
72 description of the contents of the object file. If the
73 interface file and object file get out of sync for any reason,
74 then the compiler may end up making assumptions about the object
75 file that aren't true; trouble will almost certainly follow.
76 For this reason, we recommend keeping object files and interface
77 files in the same place (GHC does this by default, but it is
78 possible to override the defaults as we'll explain
81 <para>Every module has a <emphasis>module name</emphasis>
82 defined in its source code (<literal>module A.B.C where
83 ...</literal>).</para>
85 <para>The name of the object file generated by GHC is derived
86 according to the following rules, where
87 <replaceable>osuf</replaceable> is the object-file suffix (this
88 can be changed with the <option>-osuf</option> option).</para>
92 <para>If there is no <option>-odir</option> option (the
93 default), then the object filename is derived from the
94 source filename (ignoring the module name) by replacing the
95 suffix with <replaceable>osuf</replaceable>.</para>
99 <option>-odir</option> <replaceable>dir</replaceable>
100 has been specified, then the object filename is
101 <replaceable>dir</replaceable>/<replaceable>mod</replaceable>.<replaceable>osuf</replaceable>,
102 where <replaceable>mod</replaceable> is the module name with
103 dots replaced by slashes.</para>
107 <para>The name of the interface file is derived using the same
108 rules, except that the suffix is
109 <replaceable>hisuf</replaceable> (<literal>.hi</literal> by
110 default) instead of <replaceable>osuf</replaceable>, and the
111 relevant options are <option>-hidir</option> and
112 <option>-hisuf</option> instead of <option>-odir</option> and
113 <option>-osuf</option> respectively.</para>
115 <para>For example, if GHC compiles the module
116 <literal>A.B.C</literal> in the file
117 <filename>src/A/B/C.hs</filename>, with no
118 <literal>-odir</literal> or <literal>-hidir</literal> flags, the
119 interface file will be put in <literal>src/A/B/C.hi</literal>
120 and the object file in <literal>src/A/B/C.o</literal>.</para>
122 <para>For any module that is imported, GHC requires that the
123 name of the module in the import statement exactly matches the
124 name of the module in the interface file (or source file) found
125 using the strategy specified in <xref linkend="search-path"/>.
126 This means that for most modules, the source file name should
127 match the module name.</para>
129 <para>However, note that it is reasonable to have a module
130 <literal>Main</literal> in a file named
131 <filename>foo.hs</filename>, but this only works because GHC
132 never needs to search for the interface for module
133 <literal>Main</literal> (because it is never imported). It is
134 therefore possible to have several <literal>Main</literal>
135 modules in separate source files in the same directory, and GHC
136 will not get confused.</para>
138 <para>In batch compilation mode, the name of the object file can
139 also be overridden using the <option>-o</option> option, and the
140 name of the interface file can be specified directly using the
141 <option>-ohi</option> option.</para>
144 <sect2 id="search-path">
145 <title>The search path</title>
147 <indexterm><primary>search path</primary>
149 <indexterm><primary>interface files, finding them</primary></indexterm>
150 <indexterm><primary>finding interface files</primary></indexterm>
152 <para>In your program, you import a module
153 <literal>Foo</literal> by saying <literal>import Foo</literal>.
154 In <option>--make</option> mode or GHCi, GHC will look for a
155 source file for <literal>Foo</literal> and arrange to compile it
156 first. Without <option>--make</option>, GHC will look for the
157 interface file for <literal>Foo</literal>, which should have
158 been created by an earlier compilation of
159 <literal>Foo</literal>. GHC uses the same strategy in each of
160 these cases for finding the appropriate file.</para>
162 <para>This strategy is as follows: GHC keeps a list of
163 directories called the <firstterm>search path</firstterm>. For
164 each of these directories, it tries appending
165 <replaceable>basename</replaceable><literal>.</literal><replaceable>extension</replaceable>
166 to the directory, and checks whether the file exists. The value
167 of <replaceable>basename</replaceable> is the module name with
168 dots replaced by the directory separator ('/' or '\', depending
169 on the system), and <replaceable>extension</replaceable> is a
170 source extension (<literal>hs</literal>, <literal>lhs</literal>)
171 if we are in <option>--make</option> mode and GHCi, or
172 <replaceable>hisuf</replaceable> otherwise.</para>
174 <para>For example, suppose the search path contains directories
175 <literal>d1</literal>, <literal>d2</literal>, and
176 <literal>d3</literal>, and we are in <literal>--make</literal>
177 mode looking for the source file for a module
178 <literal>A.B.C</literal>. GHC will look in
179 <literal>d1/A/B/C.hs</literal>, <literal>d1/A/B/C.lhs</literal>,
180 <literal>d2/A/B/C.hs</literal>, and so on.</para>
182 <para>The search path by default contains a single directory:
183 <quote>.</quote> (i.e. the current directory). The following
184 options can be used to add to or change the contents of the
189 <term><option>-i<replaceable>dirs</replaceable></option></term>
191 <para><indexterm><primary><option>-i<replaceable>dirs</replaceable></option>
192 </primary></indexterm>This flag appends a colon-separated
193 list of <filename>dirs</filename> to the search path.</para>
198 <term><option>-i</option></term>
200 <para>resets the search path back to nothing.</para>
205 <para>This isn't the whole story: GHC also looks for modules in
206 pre-compiled libraries, known as packages. See the section on
207 packages (<xref linkend="packages"/>), for details.</para>
210 <sect2 id="options-output">
211 <title>Redirecting the compilation output(s)</title>
213 <indexterm><primary>output-directing options</primary></indexterm>
214 <indexterm><primary>redirecting compilation output</primary></indexterm>
219 <option>-o</option> <replaceable>file</replaceable>
220 <indexterm><primary><option>-o</option></primary></indexterm>
223 <para>GHC's compiled output normally goes into a
224 <filename>.hc</filename>, <filename>.o</filename>, etc.,
225 file, depending on the last-run compilation phase. The
226 option <option>-o <replaceable>file</replaceable></option>
227 re-directs the output of that last-run phase to
228 <replaceable>file</replaceable>.</para>
230 <para>Note: this “feature” can be
231 counterintuitive: <command>ghc -C -o foo.o
232 foo.hs</command> will put the intermediate C code in the
233 file <filename>foo.o</filename>, name
234 notwithstanding!</para>
236 <para>This option is most often used when creating an
237 executable file, to set the filename of the executable.
239 <screen> ghc -o prog --make Main</screen>
241 will compile the program starting with module
242 <literal>Main</literal> and put the executable in the
243 file <literal>prog</literal>.</para>
245 <para>Note: on Windows, if the result is an executable
246 file, the extension "<filename>.exe</filename>" is added
247 if the specified filename does not already have an
252 will compile and link the module
253 <filename>Main.hs</filename>, and put the resulting
254 executable in <filename>foo.exe</filename> (not
255 <filename>foo</filename>).</para>
261 <option>-odir</option> <replaceable>dir</replaceable>
262 <indexterm><primary><option>-odir</option></primary></indexterm>
265 <para>Redirects object files to directory
266 <replaceable>dir</replaceable>. For example:</para>
269 $ ghc -c parse/Foo.hs parse/Bar.hs gurgle/Bumble.hs -odir `arch`
272 <para>The object files, <filename>Foo.o</filename>,
273 <filename>Bar.o</filename>, and
274 <filename>Bumble.o</filename> would be put into a
275 subdirectory named after the architecture of the executing
276 machine (<filename>x86</filename>,
277 <filename>mips</filename>, etc).</para>
279 <para>Note that the <option>-odir</option> option does
280 <emphasis>not</emphasis> affect where the interface files
281 are put; use the <option>-hidir</option> option for that.
282 In the above example, they would still be put in
283 <filename>parse/Foo.hi</filename>,
284 <filename>parse/Bar.hi</filename>, and
285 <filename>gurgle/Bumble.hi</filename>.</para>
291 <option>-ohi</option> <replaceable>file</replaceable>
292 <indexterm><primary><option>-ohi</option></primary></indexterm>
295 <para>The interface output may be directed to another file
296 <filename>bar2/Wurble.iface</filename> with the option
297 <option>-ohi bar2/Wurble.iface</option> (not
300 <para>WARNING: if you redirect the interface file
301 somewhere that GHC can't find it, then the recompilation
302 checker may get confused (at the least, you won't get any
303 recompilation avoidance). We recommend using a
304 combination of <option>-hidir</option> and
305 <option>-hisuf</option> options instead, if
308 <para>To avoid generating an interface at all, you could
309 use this option to redirect the interface into the bit
310 bucket: <literal>-ohi /dev/null</literal>, for
317 <option>-hidir</option> <replaceable>dir</replaceable>
318 <indexterm><primary><option>-hidir</option></primary></indexterm>
321 <para>Redirects all generated interface files into
322 <replaceable>dir</replaceable>, instead of the
329 <option>-osuf</option> <replaceable>suffix</replaceable>
330 <indexterm><primary><option>-osuf</option></primary></indexterm>
333 <option>-hisuf</option> <replaceable>suffix</replaceable>
334 <indexterm><primary><option>-hisuf</option></primary></indexterm>
337 <option>-hcsuf</option> <replaceable>suffix</replaceable>
338 <indexterm><primary><option>-hcsuf</option></primary></indexterm>
341 <para>The <option>-osuf</option>
342 <replaceable>suffix</replaceable> will change the
343 <literal>.o</literal> file suffix for object files to
344 whatever you specify. We use this when compiling
345 libraries, so that objects for the profiling versions of
346 the libraries don't clobber the normal ones.</para>
348 <para>Similarly, the <option>-hisuf</option>
349 <replaceable>suffix</replaceable> will change the
350 <literal>.hi</literal> file suffix for non-system
351 interface files (see <xref linkend="hi-options"/>).</para>
353 <para>Finally, the option <option>-hcsuf</option>
354 <replaceable>suffix</replaceable> will change the
355 <literal>.hc</literal> file suffix for compiler-generated
356 intermediate C files.</para>
358 <para>The <option>-hisuf</option>/<option>-osuf</option>
359 game is particularly useful if you want to compile a
360 program both with and without profiling, in the same
361 directory. You can say:
364 to get the ordinary version, and
366 ghc ... -osuf prof.o -hisuf prof.hi -prof -auto-all</screen>
367 to get the profiled version.</para>
373 <sect2 id="keeping-intermediates">
374 <title>Keeping Intermediate Files</title>
375 <indexterm><primary>intermediate files, saving</primary>
377 <indexterm><primary><literal>.hc</literal> files, saving</primary>
379 <indexterm><primary><literal>.s</literal> files, saving</primary>
382 <para>The following options are useful for keeping certain
383 intermediate files around, when normally GHC would throw these
384 away after compilation:</para>
389 <option>-keep-hc-files</option>
390 <indexterm><primary><option>-keep-hc-files</option></primary></indexterm>
393 <para>Keep intermediate <literal>.hc</literal> files when
394 doing <literal>.hs</literal>-to-<literal>.o</literal>
395 compilations via C (NOTE: <literal>.hc</literal> files
396 aren't generated when using the native code generator, you
397 may need to use <option>-fvia-C</option> to force them
398 to be produced).</para>
404 <option>-keep-s-files</option>
405 <indexterm><primary><option>-keep-s-files</option></primary></indexterm>
408 <para>Keep intermediate <literal>.s</literal> files.</para>
414 <option>-keep-raw-s-files</option>
415 <indexterm><primary><option>-keep-raw-s-files</option></primary></indexterm>
418 <para>Keep intermediate <literal>.raw-s</literal> files.
419 These are the direct output from the C compiler, before
420 GHC does “assembly mangling” to produce the
421 <literal>.s</literal> file. Again, these are not produced
422 when using the native code generator.</para>
428 <option>-keep-tmp-files</option>
429 <indexterm><primary><option>-keep-tmp-files</option></primary></indexterm>
430 <indexterm><primary>temporary files</primary><secondary>keeping</secondary></indexterm>
433 <para>Instructs the GHC driver not to delete any of its
434 temporary files, which it normally keeps in
435 <literal>/tmp</literal> (or possibly elsewhere; see <xref
436 linkend="temp-files"/>). Running GHC with
437 <option>-v</option> will show you what temporary files
438 were generated along the way.</para>
444 <sect2 id="temp-files">
445 <title>Redirecting temporary files</title>
448 <primary>temporary files</primary>
449 <secondary>redirecting</secondary>
455 <option>-tmpdir</option>
456 <indexterm><primary><option>-tmpdir</option></primary></indexterm>
459 <para>If you have trouble because of running out of space
460 in <filename>/tmp</filename> (or wherever your
461 installation thinks temporary files should go), you may
462 use the <option>-tmpdir
463 <dir></option><indexterm><primary>-tmpdir
464 <dir> option</primary></indexterm> option to specify
465 an alternate directory. For example, <option>-tmpdir
466 .</option> says to put temporary files in the current
467 working directory.</para>
469 <para>Alternatively, use your <constant>TMPDIR</constant>
470 environment variable.<indexterm><primary>TMPDIR
471 environment variable</primary></indexterm> Set it to the
472 name of the directory where temporary files should be put.
473 GCC and other programs will honour the
474 <constant>TMPDIR</constant> variable as well.</para>
476 <para>Even better idea: Set the
477 <constant>DEFAULT_TMPDIR</constant> make variable when
478 building GHC, and never worry about
479 <constant>TMPDIR</constant> again. (see the build
480 documentation).</para>
486 <sect2 id="hi-options">
487 <title>Other options related to interface files</title>
488 <indexterm><primary>interface files, options</primary></indexterm>
493 <option>-ddump-hi</option>
494 <indexterm><primary><option>-ddump-hi</option></primary></indexterm>
497 <para>Dumps the new interface to standard output.</para>
503 <option>-ddump-hi-diffs</option>
504 <indexterm><primary><option>-ddump-hi-diffs</option></primary></indexterm>
507 <para>The compiler does not overwrite an existing
508 <filename>.hi</filename> interface file if the new one is
509 the same as the old one; this is friendly to
510 <command>make</command>. When an interface does change,
511 it is often enlightening to be informed. The
512 <option>-ddump-hi-diffs</option> option will make GHC run
513 <command>diff</command> on the old and new
514 <filename>.hi</filename> files.</para>
520 <option>-ddump-minimal-imports</option>
521 <indexterm><primary><option>-ddump-minimal-imports</option></primary></indexterm>
524 <para>Dump to the file "M.imports" (where M is the module
525 being compiled) a "minimal" set of import declarations.
526 You can safely replace all the import declarations in
527 "M.hs" with those found in "M.imports". Why would you
528 want to do that? Because the "minimal" imports (a) import
529 everything explicitly, by name, and (b) import nothing
530 that is not required. It can be quite painful to maintain
531 this property by hand, so this flag is intended to reduce
538 <option>--show-iface</option> <replaceable>file</replaceable>
539 <indexterm><primary><option>--show-iface</option></primary></indexterm>
542 <para>Where <replaceable>file</replaceable> is the name of
543 an interface file, dumps the contents of that interface in
544 a human-readable (ish) format.</para>
551 <title>The recompilation checker</title>
553 <indexterm><primary>recompilation checker</primary></indexterm>
558 <option>-no-recomp</option>
559 <indexterm><primary><option>-recomp</option></primary></indexterm>
560 <indexterm><primary><option>-no-recomp</option></primary></indexterm>
563 <para>Turn off recompilation checking (which is on by
564 default). Recompilation checking normally stops
565 compilation early, leaving an existing
566 <filename>.o</filename> file in place, if it can be
567 determined that the module does not need to be
573 <para>In the olden days, GHC compared the newly-generated
574 <filename>.hi</filename> file with the previous version; if they
575 were identical, it left the old one alone and didn't change its
576 modification date. In consequence, importers of a module with
577 an unchanged output <filename>.hi</filename> file were not
580 <para>This doesn't work any more. Suppose module
581 <literal>C</literal> imports module <literal>B</literal>, and
582 <literal>B</literal> imports module <literal>A</literal>. So
583 changes to module <literal>A</literal> might require module
584 <literal>C</literal> to be recompiled, and hence when
585 <filename>A.hi</filename> changes we should check whether
586 <literal>C</literal> should be recompiled. However, the
587 dependencies of <literal>C</literal> will only list
588 <literal>B.hi</literal>, not <literal>A.hi</literal>, and some
589 changes to <literal>A</literal> (changing the definition of a
590 function that appears in an inlining of a function exported by
591 <literal>B</literal>, say) may conceivably not change
592 <filename>B.hi</filename> one jot. So now…</para>
594 <para>GHC keeps a version number on each interface file, and on
595 each type signature within the interface file. It also keeps in
596 every interface file a list of the version numbers of everything
597 it used when it last compiled the file. If the source file's
598 modification date is earlier than the <filename>.o</filename>
599 file's date (i.e. the source hasn't changed since the file was
600 last compiled), and the recompilation checking is on, GHC will be
601 clever. It compares the version numbers on the things it needs
602 this time with the version numbers on the things it needed last
603 time (gleaned from the interface file of the module being
604 compiled); if they are all the same it stops compiling rather
605 early in the process saying “Compilation IS NOT
606 required”. What a beautiful sight!</para>
608 <para>Patrick Sansom had a workshop paper about how all this is
609 done (though the details have changed quite a bit). <ulink
610 url="mailto:sansom@dcs.gla.ac.uk">Ask him</ulink> if you want a
615 <sect2 id="using-make">
616 <title>Using <command>make</command></title>
618 <indexterm><primary><literal>make</literal></primary></indexterm>
620 <para>It is reasonably straightforward to set up a
621 <filename>Makefile</filename> to use with GHC, assuming you name
622 your source files the same as your modules. Thus:</para>
626 HC_OPTS = -cpp $(EXTRA_HC_OPTS)
628 SRCS = Main.lhs Foo.lhs Bar.lhs
629 OBJS = Main.o Foo.o Bar.o
631 .SUFFIXES : .o .hs .hi .lhs .hc .s
635 $(HC) -o $@ $(HC_OPTS) $(OBJS)
637 # Standard suffix rules
642 $(HC) -c $< $(HC_OPTS)
645 $(HC) -c $< $(HC_OPTS)
647 # Inter-module dependencies
648 Foo.o Foo.hc Foo.s : Baz.hi # Foo imports Baz
649 Main.o Main.hc Main.s : Foo.hi Baz.hi # Main imports Foo and Baz
652 <para>(Sophisticated <command>make</command> variants may
653 achieve some of the above more elegantly. Notably,
654 <command>gmake</command>'s pattern rules let you write the more
655 comprehensible:</para>
659 $(HC) -c $< $(HC_OPTS)
662 <para>What we've shown should work with any
663 <command>make</command>.)</para>
665 <para>Note the cheesy <literal>.o.hi</literal> rule: It records
666 the dependency of the interface (<filename>.hi</filename>) file
667 on the source. The rule says a <filename>.hi</filename> file
668 can be made from a <filename>.o</filename> file by
669 doing…nothing. Which is true.</para>
671 <para>Note the inter-module dependencies at the end of the
672 Makefile, which take the form</para>
675 Foo.o Foo.hc Foo.s : Baz.hi # Foo imports Baz
678 <para>They tell <command>make</command> that if any of
679 <literal>Foo.o</literal>, <literal>Foo.hc</literal> or
680 <literal>Foo.s</literal> have an earlier modification date than
681 <literal>Baz.hi</literal>, then the out-of-date file must be
682 brought up to date. To bring it up to date,
683 <literal>make</literal> looks for a rule to do so; one of the
684 preceding suffix rules does the job nicely.</para>
686 <sect3 id="sec-makefile-dependencies">
687 <title>Dependency generation</title>
688 <indexterm><primary>dependencies in Makefiles</primary></indexterm>
689 <indexterm><primary>Makefile dependencies</primary></indexterm>
691 <para>Putting inter-dependencies of the form <literal>Foo.o :
692 Bar.hi</literal> into your <filename>Makefile</filename> by
693 hand is rather error-prone. Don't worry, GHC has support for
694 automatically generating the required dependencies. Add the
695 following to your <filename>Makefile</filename>:</para>
699 ghc -M $(HC_OPTS) $(SRCS)
702 <para>Now, before you start compiling, and any time you change
703 the <literal>imports</literal> in your program, do
704 <command>make depend</command> before you do <command>make
705 cool_pgm</command>. <command>ghc -M</command> will
706 append the needed dependencies to your
707 <filename>Makefile</filename>.</para>
709 <para>In general, if module <literal>A</literal> contains the
716 then <command>ghc -M</command> will generate a dependency line
723 If module <literal>A</literal> contains the line
726 import {-# SOURCE #-} B ...blah...
729 then <command>ghc -M</command> will generate a dependency
736 (See <xref linkend="mutual-recursion"/> for details of
737 <literal>hi-boot</literal> style interface files.) If
738 <literal>A</literal> imports multiple modules, then there will
739 be multiple lines with <filename>A.o</filename> as the
742 <para>By default, <command>ghc -M</command> generates all the
743 dependencies, and then concatenates them onto the end of
744 <filename>makefile</filename> (or
745 <filename>Makefile</filename> if <filename>makefile</filename>
746 doesn't exist) bracketed by the lines "<literal># DO NOT
747 DELETE: Beginning of Haskell dependencies</literal>" and
748 "<literal># DO NOT DELETE: End of Haskell
749 dependencies</literal>". If these lines already exist in the
750 <filename>makefile</filename>, then the old dependencies are
751 deleted first.</para>
753 <para>Don't forget to use the same <option>-package</option>
754 options on the <literal>ghc -M</literal> command line as you
755 would when compiling; this enables the dependency generator to
756 locate any imported modules that come from packages. The
757 package modules won't be included in the dependencies
758 generated, though (but see the
759 <option>––include-prelude</option> option below).</para>
761 <para>The dependency generation phase of GHC can take some
762 additional options, which you may find useful. For historical
763 reasons, each option passed to the dependency generator from
764 the GHC command line must be preceded by
765 <literal>-optdep</literal>. For example, to pass <literal>-f
766 .depend</literal> to the dependency generator, you say
769 ghc -M -optdep-f -optdep.depend ...
772 The options which affect dependency generation are:</para>
776 <term><option>-w</option></term>
778 <para>Turn off warnings about interface file shadowing.</para>
783 <term><option>-f</option> <replaceable>file</replaceable></term>
785 <para>Use <replaceable>file</replaceable> as the makefile,
786 rather than <filename>makefile</filename> or
787 <filename>Makefile</filename>. If
788 <replaceable>file</replaceable> doesn't exist,
789 <command>mkdependHS</command> creates it. We often use
790 <option>-f .depend</option> to put the dependencies in
791 <filename>.depend</filename> and then
792 <command>include</command> the file
793 <filename>.depend</filename> into
794 <filename>Makefile</filename>.</para>
798 <!-- Retired with the move away from 'mkdependHS'.
800 <term><option>-o <osuf></option></term>
802 <para>Use <filename>.<osuf></filename> as the
803 "target file" suffix ( default: <literal>o</literal>).
804 Multiple <option>-o</option> flags are permitted
805 (GHC2.05 onwards). Thus "<option>-o hc -o o</option>"
806 will generate dependencies for <filename>.hc</filename>
807 and <filename>.o</filename> files.</para>
812 <term><option>-s <suf></option></term>
814 <para>Make extra dependencies that declare that files
816 <filename>.<suf>_<osuf></filename>
817 depend on interface files with suffix
818 <filename>.<suf>_hi</filename>, or (for
819 <literal>{-# SOURCE #-}</literal>
820 imports) on <filename>.hi-boot</filename>. Multiple
821 <option>-s</option> flags are permitted. For example,
822 <option>-o hc -s a -s b</option> will make dependencies
823 for <filename>.hc</filename> on
824 <filename>.hi</filename>,
825 <filename>.a_hc</filename> on
826 <filename>.a_hi</filename>, and
827 <filename>.b_hc</filename> on
828 <filename>.b_hi</filename>. (Useful in
829 conjunction with NoFib "ways".)</para>
834 <term><option>––exclude-module=<file></option></term>
836 <para>Regard <filename><file></filename> as
837 "stable"; i.e., exclude it from having dependencies on
843 <term><option>-x</option></term>
845 <para>same as <option>––exclude-module</option></para>
850 <term><option>––exclude-directory=<dirs></option></term>
852 <para>Regard the colon-separated list of directories
853 <filename><dirs></filename> as containing stable,
854 don't generate any dependencies on modules
860 <term><option>––include-module=<file></option></term>
862 <para>Regard <filename><file></filename> as not
863 "stable"; i.e., generate dependencies on it (if
864 any). This option is normally used in conjunction with
865 the <option>––exclude-directory</option> option.</para>
870 <term><option>––include-prelude</option></term>
872 <para>Regard modules imported from packages as unstable,
873 i.e., generate dependencies on the package modules used
874 (including <literal>Prelude</literal>, and all other
875 standard Haskell libraries). This option is normally
876 only used by the various system libraries.</para>
884 <sect2 id="mutual-recursion">
885 <title>How to compile mutually recursive modules</title>
887 <indexterm><primary>module system, recursion</primary></indexterm>
888 <indexterm><primary>recursion, between modules</primary></indexterm>
890 <para>Currently, the compiler does not have proper support for
891 dealing with mutually recursive modules:</para>
898 newtype TA = MkTA Int
913 <para>When compiling either module A and B, the compiler will
914 try (in vain) to look for the interface file of the other. So,
915 to get mutually recursive modules off the ground, you need to
916 hand write an interface file for A or B, so as to break the
917 loop. These hand-written interface files are called
918 <literal>hi-boot</literal> files, and are placed in a file
919 called <filename><module>.hi-boot</filename>. To import
920 from an <literal>hi-boot</literal> file instead of the standard
921 <filename>.hi</filename> file, use the following syntax in the
922 importing module: <indexterm><primary><literal>hi-boot</literal>
923 files</primary></indexterm> <indexterm><primary>importing,
924 <literal>hi-boot</literal> files</primary></indexterm></para>
927 import {-# SOURCE #-} A
930 <para>The hand-written interface need only contain the bare
931 minimum of information needed to get the bootstrapping process
932 started. For example, it doesn't need to contain declarations
933 for <emphasis>everything</emphasis> that module
934 <literal>A</literal> exports, only the things required by the
935 module that imports <literal>A</literal> recursively.</para>
937 <para>For the example at hand, the boot interface file for A
938 would look like the following:</para>
942 newtype TA = MkTA GHC.Base.Int
945 <para>Notice that we only put the declaration for the newtype
946 <literal>TA</literal> in the <literal>hi-boot</literal> file,
947 not the signature for <function>f</function>, since
948 <function>f</function> isn't used by <literal>B</literal>.</para>
950 <para>The syntax is similar to a normal Haskell source file, but
951 with some important differences:</para>
955 <para>Local entities (ones defined in the same <literal>hi-boot</literal> file may
956 be mentioned unqualified, but non-local entities (ones defined in other modules)
957 must be qualified with their
958 <emphasis>original</emphasis> defining module. Qualifying
959 by a module which just re-exports the entity won't do. In
960 particular, most <literal>Prelude</literal> entities aren't
961 actually defined in the <literal>Prelude</literal> (see for
962 example <literal>GHC.Base.Int</literal> in the above
963 example). HINT: to find out the fully-qualified name for
964 entities in the <literal>Prelude</literal> (or anywhere for
965 that matter), try using GHCi's
966 <literal>:info</literal> command, eg.</para>
967 <programlisting>Prelude> :m -Prelude
969 -- GHC.IOBase.IO is a type constructor
970 newtype GHC.IOBase.IO a
974 <para>Only <literal>data</literal>, <literal>type</literal>,
975 <literal>newtype</literal>, <literal>class</literal>, and
976 type signature declarations may be included. You cannot declare
977 <literal>instances</literal> or derive them automatically.
981 <listitem> <para>For <literal>data</literal> or <literal>newtype</literal> declaration, you may omit all
982 the constructors, by omitting the '=' and everything that follows it:
987 In a <emphasis>source</emphasis> program
988 this would declare TA to have no constructors (a GHC extension: see <xref linkend="nullary-types"/>),
989 but in an hi-boot file it means "I don't know or care what the constructors are".
990 This is the most common form of data type declaration, because it's easy to get right.</para>
992 You <emphasis>can</emphasis> also write out the constructors but, if you do so, you must write
993 it out precisely as in its real definition.
994 It is especially delicate if you use a strictness annotation "!",
995 with or without an <literal>{-# UNPACK #-}</literal> pragma. In a source file
996 GHC may or may not choose to unbox the argument, but in an hi-boot file it's
997 assumed that you express the <emphasis>outcome</emphasis> of this decision.
998 (So in the cases where GHC decided not to unpack, you must not use the pragma.)
999 Tread with care.</para>
1001 Regardless of whether you write the constructors, you must write all the type parameters,
1002 <emphasis>including their kinds</emphasis>
1003 if they are not '*'. (You can give explicit kinds in source files too (<xref linkend="sec-kinding"/>),
1004 but you <emphasis>must</emphasis> do so in hi-boot files.)</para>
1007 <listitem> <para>For <literal>class</literal> declaration, you may not specify any class
1008 operations. We could lift this restriction if it became tiresome.</para>
1012 <para>If <literal>M.hi-boot</literal> mentions an entity <literal>N.f</literal>, defined in some other
1013 module <literal>N</literal>, then GHC will by default go hunting for <literal>N.hi</literal>. If module
1014 <literal>N</literal> is not yet compiled either, GHC won't look for <literal>N.hi-boot</literal>; it'll just
1015 complain. To fix this, in the source file that uses
1016 <literal>import {-# SOURCE #-} M</literal>, add
1017 <literal>import {-# SOURCE #-} N()</literal>. (The "()" says that you don't want to import anything into
1018 your current scope, and will prevent unused-import warnings.) You only need this if no other imported module
1019 depends on <literal>N.hi-boot</literal>.</para>
1024 <sect2 id="orphan-modules">
1025 <title>Orphan modules and instance declarations</title>
1027 <para> Haskell specifies that when compiling module M, any instance
1028 declaration in any module "below" M is visible. (Module A is "below"
1029 M if A is imported directly by M, or if A is below a module that M imports directly.)
1030 In principle, GHC must therefore read the interface files of every module below M,
1031 just in case they contain an instance declaration that matters to M. This would
1032 be a disaster in practice, so GHC tries to be clever. </para>
1034 <para>In particular, if an instance declaration is in the same module as the definition
1035 of any type or class mentioned in the head of the instance declaration, then
1036 GHC has to visit that interface file anyway. Example:</para>
1039 instance C a => D (T a) where ...
1042 <para> The instance declaration is only relevant if the type T is in use, and if
1043 so, GHC will have visited A's interface file to find T's definition. </para>
1045 <para> The only problem comes when a module contains an instance declaration
1046 and GHC has no other reason for visiting the module. Example:
1049 instance C a => D (T a) where ...
1052 Here, neither D nor T is declared in module Orphan.
1053 We call such modules ``orphan modules'',
1054 defined thus:</para>
1056 <listitem> <para> An <emphasis>orphan module</emphasis>
1057 <indexterm><primary>orphan module</primary></indexterm>
1058 contains at least one <emphasis>orphan instance</emphasis> or at
1059 least one <emphasis>orphan rule</emphasis>.</para> </listitem>
1061 <listitem><para> An instance declaration in a module M is an <emphasis>orphan instance</emphasis> if
1062 <indexterm><primary>orphan instance</primary></indexterm>
1063 none of the type constructors
1064 or classes mentioned in the instance head (the part after the ``<literal>=></literal>'') are declared
1067 <para> Only the instance head counts. In the example above, it is not good enough for C's declaration
1068 to be in module A; it must be the declaration of D or T.</para>
1071 <listitem><para> A rewrite rule in a module M is an <emphasis>orphan rule</emphasis>
1072 <indexterm><primary>orphan rule</primary></indexterm>
1073 if none of the variables, type constructors,
1074 or classes that are free in the left hand side of the rule are declared in M.
1079 <para> GHC identifies orphan modules, and visits the interface file of
1080 every orphan module below the module being compiled. This is usually
1081 wasted work, but there is no avoiding it. You should therefore do
1082 your best to have as few orphan modules as possible.
1086 <para> You can identify an orphan module by looking in its interface
1087 file, <filename>M.hi</filename>, using the
1088 <option>--show-iface</option>. If there is a ``!'' on the first line,
1089 GHC considers it an orphan module.
1096 ;;; Local Variables: ***
1098 ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter" "sect1") ***