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 <indexterm><primary>filenames</primary></indexterm>
35 <para>Each Haskell source module should be placed in a file on
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>
46 <indexterm><primary>unicode</primary></indexterm>
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
55 Latin-1<indexterm><primary>Latin-1</primary></indexterm>, as
56 long as the non-comment source code is ASCII only.</para>
59 <sect2 id="output-files">
60 <title>Output files</title>
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>
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>
71 <para>The object file, which normally ends in a
72 <literal>.o</literal> suffix, contains the compiled code for the
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>
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
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>
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>
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>
113 <option>-odir</option> <replaceable>dir</replaceable>
114 has been specified, then the object filename is
115 <replaceable>dir</replaceable>/<replaceable>mod</replaceable>.<replaceable>osuf</replaceable>,
116 where <replaceable>mod</replaceable> is the module name with
117 dots replaced by slashes. GHC will silently create the necessary directory
118 structure underneath <replaceable>dir</replaceable>, if it does not
119 already exist.</para>
123 <para>The name of the interface file is derived using the same
124 rules, except that the suffix is
125 <replaceable>hisuf</replaceable> (<literal>.hi</literal> by
126 default) instead of <replaceable>osuf</replaceable>, and the
127 relevant options are <option>-hidir</option> and
128 <option>-hisuf</option> instead of <option>-odir</option> and
129 <option>-osuf</option> respectively.</para>
131 <para>For example, if GHC compiles the module
132 <literal>A.B.C</literal> in the file
133 <filename>src/A/B/C.hs</filename>, with no
134 <literal>-odir</literal> or <literal>-hidir</literal> flags, the
135 interface file will be put in <literal>src/A/B/C.hi</literal>
136 and the object file in <literal>src/A/B/C.o</literal>.</para>
138 <para>For any module that is imported, GHC requires that the
139 name of the module in the import statement exactly matches the
140 name of the module in the interface file (or source file) found
141 using the strategy specified in <xref linkend="search-path"/>.
142 This means that for most modules, the source file name should
143 match the module name.</para>
145 <para>However, note that it is reasonable to have a module
146 <literal>Main</literal> in a file named
147 <filename>foo.hs</filename>, but this only works because GHC
148 never needs to search for the interface for module
149 <literal>Main</literal> (because it is never imported). It is
150 therefore possible to have several <literal>Main</literal>
151 modules in separate source files in the same directory, and GHC
152 will not get confused.</para>
154 <para>In batch compilation mode, the name of the object file can
155 also be overridden using the <option>-o</option> option, and the
156 name of the interface file can be specified directly using the
157 <option>-ohi</option> option.</para>
160 <sect2 id="search-path">
161 <title>The search path</title>
163 <indexterm><primary>search path</primary>
165 <indexterm><primary>interface files, finding them</primary></indexterm>
166 <indexterm><primary>finding interface files</primary></indexterm>
168 <para>In your program, you import a module
169 <literal>Foo</literal> by saying <literal>import Foo</literal>.
170 In <option>--make</option> mode or GHCi, GHC will look for a
171 source file for <literal>Foo</literal> and arrange to compile it
172 first. Without <option>--make</option>, GHC will look for the
173 interface file for <literal>Foo</literal>, which should have
174 been created by an earlier compilation of
175 <literal>Foo</literal>. GHC uses the same strategy in each of
176 these cases for finding the appropriate file.</para>
178 <para>This strategy is as follows: GHC keeps a list of
179 directories called the <firstterm>search path</firstterm>. For
180 each of these directories, it tries appending
181 <replaceable>basename</replaceable><literal>.</literal><replaceable>extension</replaceable>
182 to the directory, and checks whether the file exists. The value
183 of <replaceable>basename</replaceable> is the module name with
184 dots replaced by the directory separator ('/' or '\', depending
185 on the system), and <replaceable>extension</replaceable> is a
186 source extension (<literal>hs</literal>, <literal>lhs</literal>)
187 if we are in <option>--make</option> mode or GHCi, or
188 <replaceable>hisuf</replaceable> otherwise.</para>
190 <para>For example, suppose the search path contains directories
191 <literal>d1</literal>, <literal>d2</literal>, and
192 <literal>d3</literal>, and we are in <literal>--make</literal>
193 mode looking for the source file for a module
194 <literal>A.B.C</literal>. GHC will look in
195 <literal>d1/A/B/C.hs</literal>, <literal>d1/A/B/C.lhs</literal>,
196 <literal>d2/A/B/C.hs</literal>, and so on.</para>
198 <para>The search path by default contains a single directory:
199 <quote>.</quote> (i.e. the current directory). The following
200 options can be used to add to or change the contents of the
205 <term><option>-i<replaceable>dirs</replaceable></option></term>
207 <para><indexterm><primary><option>-i<replaceable>dirs</replaceable></option>
208 </primary></indexterm>This flag appends a colon-separated
209 list of <filename>dirs</filename> to the search path.</para>
214 <term><option>-i</option></term>
216 <para>resets the search path back to nothing.</para>
221 <para>This isn't the whole story: GHC also looks for modules in
222 pre-compiled libraries, known as packages. See the section on
223 packages (<xref linkend="packages"/>) for details.</para>
226 <sect2 id="options-output">
227 <title>Redirecting the compilation output(s)</title>
229 <indexterm><primary>output-directing options</primary></indexterm>
230 <indexterm><primary>redirecting compilation output</primary></indexterm>
235 <option>-o</option> <replaceable>file</replaceable>
236 <indexterm><primary><option>-o</option></primary></indexterm>
239 <para>GHC's compiled output normally goes into a
240 <filename>.hc</filename>, <filename>.o</filename>, etc.,
241 file, depending on the last-run compilation phase. The
242 option <option>-o <replaceable>file</replaceable></option>
243 re-directs the output of that last-run phase to
244 <replaceable>file</replaceable>.</para>
246 <para>Note: this “feature” can be
247 counterintuitive: <command>ghc -C -o foo.o
248 foo.hs</command> will put the intermediate C code in the
249 file <filename>foo.o</filename>, name
250 notwithstanding!</para>
252 <para>This option is most often used when creating an
253 executable file, to set the filename of the executable.
255 <screen> ghc -o prog --make Main</screen>
257 will compile the program starting with module
258 <literal>Main</literal> and put the executable in the
259 file <literal>prog</literal>.</para>
261 <para>Note: on Windows, if the result is an executable
262 file, the extension "<filename>.exe</filename>" is added
263 if the specified filename does not already have an
268 will compile and link the module
269 <filename>Main.hs</filename>, and put the resulting
270 executable in <filename>foo.exe</filename> (not
271 <filename>foo</filename>).</para>
273 <para>If you use <command>ghc --make</command> and you don't
274 use the <option>-o</option>, the name GHC will choose
275 for the executable will be based on the name of the file
276 containing the module <literal>Main</literal>.
277 Note that with GHC the <literal>Main</literal> module doesn't
278 have to be put in file <filename>Main.hs</filename>.
287 will produce <filename>Prog</filename> (or
288 <filename>Prog.exe</filename> if you are on Windows).</para>
294 <option>-odir</option> <replaceable>dir</replaceable>
295 <indexterm><primary><option>-odir</option></primary></indexterm>
298 <para>Redirects object files to directory
299 <replaceable>dir</replaceable>. For example:</para>
302 $ ghc -c parse/Foo.hs parse/Bar.hs gurgle/Bumble.hs -odir `arch`
305 <para>The object files, <filename>Foo.o</filename>,
306 <filename>Bar.o</filename>, and
307 <filename>Bumble.o</filename> would be put into a
308 subdirectory named after the architecture of the executing
309 machine (<filename>x86</filename>,
310 <filename>mips</filename>, etc).</para>
312 <para>Note that the <option>-odir</option> option does
313 <emphasis>not</emphasis> affect where the interface files
314 are put; use the <option>-hidir</option> option for that.
315 In the above example, they would still be put in
316 <filename>parse/Foo.hi</filename>,
317 <filename>parse/Bar.hi</filename>, and
318 <filename>gurgle/Bumble.hi</filename>.</para>
324 <option>-ohi</option> <replaceable>file</replaceable>
325 <indexterm><primary><option>-ohi</option></primary></indexterm>
328 <para>The interface output may be directed to another file
329 <filename>bar2/Wurble.iface</filename> with the option
330 <option>-ohi bar2/Wurble.iface</option> (not
333 <para>WARNING: if you redirect the interface file
334 somewhere that GHC can't find it, then the recompilation
335 checker may get confused (at the least, you won't get any
336 recompilation avoidance). We recommend using a
337 combination of <option>-hidir</option> and
338 <option>-hisuf</option> options instead, if
341 <para>To avoid generating an interface at all, you could
342 use this option to redirect the interface into the bit
343 bucket: <literal>-ohi /dev/null</literal>, for
350 <option>-hidir</option> <replaceable>dir</replaceable>
351 <indexterm><primary><option>-hidir</option></primary></indexterm>
354 <para>Redirects all generated interface files into
355 <replaceable>dir</replaceable>, instead of the
362 <option>-stubdir</option> <replaceable>dir</replaceable>
363 <indexterm><primary><option>-stubdir</option></primary></indexterm>
366 <para>Redirects all generated FFI stub files into
367 <replaceable>dir</replaceable>. Stub files are generated when the
368 Haskell source contains a <literal>foreign export</literal> or
369 <literal>foreign import "&wrapper"</literal> declaration (see <xref
370 linkend="foreign-export-ghc" />). The <option>-stubdir</option>
371 option behaves in exactly the same way as <option>-odir</option>
372 and <option>-hidir</option> with respect to hierarchical
379 <option>-osuf</option> <replaceable>suffix</replaceable>
380 <indexterm><primary><option>-osuf</option></primary></indexterm>
383 <option>-hisuf</option> <replaceable>suffix</replaceable>
384 <indexterm><primary><option>-hisuf</option></primary></indexterm>
387 <option>-hcsuf</option> <replaceable>suffix</replaceable>
388 <indexterm><primary><option>-hcsuf</option></primary></indexterm>
391 <para>The <option>-osuf</option>
392 <replaceable>suffix</replaceable> will change the
393 <literal>.o</literal> file suffix for object files to
394 whatever you specify. We use this when compiling
395 libraries, so that objects for the profiling versions of
396 the libraries don't clobber the normal ones.</para>
398 <para>Similarly, the <option>-hisuf</option>
399 <replaceable>suffix</replaceable> will change the
400 <literal>.hi</literal> file suffix for non-system
401 interface files (see <xref linkend="hi-options"/>).</para>
403 <para>Finally, the option <option>-hcsuf</option>
404 <replaceable>suffix</replaceable> will change the
405 <literal>.hc</literal> file suffix for compiler-generated
406 intermediate C files.</para>
408 <para>The <option>-hisuf</option>/<option>-osuf</option>
409 game is particularly useful if you want to compile a
410 program both with and without profiling, in the same
411 directory. You can say:
414 to get the ordinary version, and
416 ghc ... -osuf prof.o -hisuf prof.hi -prof -auto-all</screen>
417 to get the profiled version.</para>
423 <sect2 id="keeping-intermediates">
424 <title>Keeping Intermediate Files</title>
425 <indexterm><primary>intermediate files, saving</primary>
427 <indexterm><primary><literal>.hc</literal> files, saving</primary>
429 <indexterm><primary><literal>.s</literal> files, saving</primary>
432 <para>The following options are useful for keeping certain
433 intermediate files around, when normally GHC would throw these
434 away after compilation:</para>
439 <option>-keep-hc-file</option>,
440 <option>-keep-hc-files</option>
441 <indexterm><primary><option>-keep-hc-file</option></primary></indexterm>
442 <indexterm><primary><option>-keep-hc-files</option></primary></indexterm>
445 <para>Keep intermediate <literal>.hc</literal> files when
446 doing <literal>.hs</literal>-to-<literal>.o</literal>
447 compilations via C (NOTE: <literal>.hc</literal> files
448 aren't generated when using the native code generator, you
449 may need to use <option>-fvia-C</option> to force them
450 to be produced).</para>
456 <option>-keep-s-file</option>,
457 <option>-keep-s-files</option>
458 <indexterm><primary><option>-keep-s-file</option></primary></indexterm>
459 <indexterm><primary><option>-keep-s-files</option></primary></indexterm>
462 <para>Keep intermediate <literal>.s</literal> files.</para>
468 <option>-keep-raw-s-file</option>,
469 <option>-keep-raw-s-files</option>
470 <indexterm><primary><option>-keep-raw-s-file</option></primary></indexterm>
471 <indexterm><primary><option>-keep-raw-s-files</option></primary></indexterm>
474 <para>Keep intermediate <literal>.raw-s</literal> files.
475 These are the direct output from the C compiler, before
476 GHC does “assembly mangling” to produce the
477 <literal>.s</literal> file. Again, these are not produced
478 when using the native code generator.</para>
484 <option>-keep-tmp-files</option>
485 <indexterm><primary><option>-keep-tmp-files</option></primary></indexterm>
486 <indexterm><primary>temporary files</primary><secondary>keeping</secondary></indexterm>
489 <para>Instructs the GHC driver not to delete any of its
490 temporary files, which it normally keeps in
491 <literal>/tmp</literal> (or possibly elsewhere; see <xref
492 linkend="temp-files"/>). Running GHC with
493 <option>-v</option> will show you what temporary files
494 were generated along the way.</para>
500 <sect2 id="temp-files">
501 <title>Redirecting temporary files</title>
504 <primary>temporary files</primary>
505 <secondary>redirecting</secondary>
511 <option>-tmpdir</option>
512 <indexterm><primary><option>-tmpdir</option></primary></indexterm>
515 <para>If you have trouble because of running out of space
516 in <filename>/tmp</filename> (or wherever your
517 installation thinks temporary files should go), you may
518 use the <option>-tmpdir
519 <dir></option><indexterm><primary>-tmpdir
520 <dir> option</primary></indexterm> option to specify
521 an alternate directory. For example, <option>-tmpdir
522 .</option> says to put temporary files in the current
523 working directory.</para>
525 <para>Alternatively, use your <constant>TMPDIR</constant>
526 environment variable.<indexterm><primary>TMPDIR
527 environment variable</primary></indexterm> Set it to the
528 name of the directory where temporary files should be put.
529 GCC and other programs will honour the
530 <constant>TMPDIR</constant> variable as well.</para>
532 <para>Even better idea: Set the
533 <constant>DEFAULT_TMPDIR</constant> make variable when
534 building GHC, and never worry about
535 <constant>TMPDIR</constant> again. (see the build
536 documentation).</para>
542 <sect2 id="hi-options">
543 <title>Other options related to interface files</title>
544 <indexterm><primary>interface files, options</primary></indexterm>
549 <option>-ddump-hi</option>
550 <indexterm><primary><option>-ddump-hi</option></primary></indexterm>
553 <para>Dumps the new interface to standard output.</para>
559 <option>-ddump-hi-diffs</option>
560 <indexterm><primary><option>-ddump-hi-diffs</option></primary></indexterm>
563 <para>The compiler does not overwrite an existing
564 <filename>.hi</filename> interface file if the new one is
565 the same as the old one; this is friendly to
566 <command>make</command>. When an interface does change,
567 it is often enlightening to be informed. The
568 <option>-ddump-hi-diffs</option> option will make GHC run
569 <command>diff</command> on the old and new
570 <filename>.hi</filename> files.</para>
576 <option>-ddump-minimal-imports</option>
577 <indexterm><primary><option>-ddump-minimal-imports</option></primary></indexterm>
580 <para>Dump to the file "M.imports" (where M is the module
581 being compiled) a "minimal" set of import declarations.
582 You can safely replace all the import declarations in
583 "M.hs" with those found in "M.imports". Why would you
584 want to do that? Because the "minimal" imports (a) import
585 everything explicitly, by name, and (b) import nothing
586 that is not required. It can be quite painful to maintain
587 this property by hand, so this flag is intended to reduce
594 <option>--show-iface</option> <replaceable>file</replaceable>
595 <indexterm><primary><option>--show-iface</option></primary></indexterm>
598 <para>where <replaceable>file</replaceable> is the name of
599 an interface file, dumps the contents of that interface in
600 a human-readable (ish) format. See <xref linkend="modes"/>.</para>
607 <title>The recompilation checker</title>
609 <indexterm><primary>recompilation checker</primary></indexterm>
614 <option>-fforce-recomp</option>
615 <indexterm><primary><option>-fforce-recomp</option></primary></indexterm>
616 <indexterm><primary><option>-fno-force-recomp</option></primary></indexterm>
619 <para>Turn off recompilation checking (which is on by
620 default). Recompilation checking normally stops
621 compilation early, leaving an existing
622 <filename>.o</filename> file in place, if it can be
623 determined that the module does not need to be
629 <para>In the olden days, GHC compared the newly-generated
630 <filename>.hi</filename> file with the previous version; if they
631 were identical, it left the old one alone and didn't change its
632 modification date. In consequence, importers of a module with
633 an unchanged output <filename>.hi</filename> file were not
636 <para>This doesn't work any more. Suppose module
637 <literal>C</literal> imports module <literal>B</literal>, and
638 <literal>B</literal> imports module <literal>A</literal>. So
639 changes to module <literal>A</literal> might require module
640 <literal>C</literal> to be recompiled, and hence when
641 <filename>A.hi</filename> changes we should check whether
642 <literal>C</literal> should be recompiled. However, the
643 dependencies of <literal>C</literal> will only list
644 <literal>B.hi</literal>, not <literal>A.hi</literal>, and some
645 changes to <literal>A</literal> (changing the definition of a
646 function that appears in an inlining of a function exported by
647 <literal>B</literal>, say) may conceivably not change
648 <filename>B.hi</filename> one jot. So now…</para>
650 <para>GHC keeps a version number on each interface file, and on
651 each type signature within the interface file. It also keeps in
652 every interface file a list of the version numbers of everything
653 it used when it last compiled the file. If the source file's
654 modification date is earlier than the <filename>.o</filename>
655 file's date (i.e. the source hasn't changed since the file was
656 last compiled), and the recompilation checking is on, GHC will be
657 clever. It compares the version numbers on the things it needs
658 this time with the version numbers on the things it needed last
659 time (gleaned from the interface file of the module being
660 compiled); if they are all the same it stops compiling rather
661 early in the process saying “Compilation IS NOT
662 required”. What a beautiful sight!</para>
664 <para>Patrick Sansom had a workshop paper about how all this is
665 done (though the details have changed quite a bit). <ulink
666 url="mailto:sansom@dcs.gla.ac.uk">Ask him</ulink> if you want a
671 <sect2 id="mutual-recursion">
672 <title>How to compile mutually recursive modules</title>
674 <indexterm><primary>module system, recursion</primary></indexterm>
675 <indexterm><primary>recursion, between modules</primary></indexterm>
677 <para>GHC supports the compilation of mutually recursive modules.
678 This section explains how.</para>
680 <para>Every cycle in the module import graph must be broken by a <filename>hs-boot</filename> file.
681 Suppose that modules <filename>A.hs</filename> and <filename>B.hs</filename> are Haskell source files,
687 newtype TA = MkTA Int
693 import {-# SOURCE #-} A( TA(..) )
700 <indexterm><primary><literal>hs-boot</literal>
701 files</primary></indexterm> <indexterm><primary>importing,
702 <literal>hi-boot</literal> files</primary></indexterm>
703 Here <filename>A</filename> imports <filename>B</filename>, but <filename>B</filename> imports
704 <filename>A</filename> with a <literal>{-# SOURCE #-}</literal> pragma, which breaks the
705 circular dependency. Every loop in the module import graph must be broken by a <literal>{-# SOURCE #-}</literal> import;
706 or, equivalently, the module import graph must be acyclic if <literal>{-# SOURCE #-}</literal> imports are ignored.
708 <para>For every module <filename>A.hs</filename> that is <literal>{-# SOURCE #-}</literal>-imported
709 in this way there must exist a source file <literal>A.hs-boot</literal>. This file contains an abbreviated
710 version of <filename>A.hs</filename>, thus:
713 newtype TA = MkTA Int
716 <para>To compile these three files, issue the following commands:
718 ghc -c A.hs-boot -- Produces A.hi-boot, A.o-boot
719 ghc -c B.hs -- Consumes A.hi-boot, produces B.hi, B.o
720 ghc -c A.hs -- Consumes B.hi, produces A.hi, A.o
721 ghc -o foo A.o B.o -- Linking the program
724 <para>There are several points to note here:
727 <para>The file <filename>A.hs-boot</filename> is a programmer-written source file.
728 It must live in the same directory as its parent source file <filename>A.hs</filename>.
729 Currently, if you use a literate source file <filename>A.lhs</filename> you must
730 also use a literate boot file, <filename>A.lhs-boot</filename>; and vice versa.
734 A <filename>hs-boot</filename> file is compiled by GHC, just like a <filename>hs</filename> file:
738 When a hs-boot file <filename>A.hs-boot</filename>
739 is compiled, it is checked for scope and type errors.
740 When its parent module <filename>A.hs</filename> is compiled, the two are compared, and
741 an error is reported if the two are inconsistent.
745 <para> Just as compiling <filename>A.hs</filename> produces an
746 interface file <filename>A.hi</filename>, and an object file
747 <filename>A.o</filename>, so compiling
748 <filename>A.hs-boot</filename> produces an interface file
749 <filename>A.hi-boot</filename>, and an pseudo-object file
750 <filename>A.o-boot</filename>: </para>
754 <para>The pseudo-object file <filename>A.o-boot</filename> is
755 empty (don't link it!), but it is very useful when using a
756 Makefile, to record when the <filename>A.hi-boot</filename> was
757 last brought up to date (see <xref
758 linkend="using-make"/>).</para>
762 <para>The <filename>hi-boot</filename> generated by compiling a
763 <filename>hs-boot</filename> file is in the same
764 machine-generated binary format as any other GHC-generated
765 interface file (e.g. <filename>B.hi</filename>). You can
766 display its contents with <command>ghc
767 --show-iface</command>. If you specify a directory for
768 interface files, the <option>-ohidir</option> flag, then that
769 affects <filename>hi-boot</filename> files
775 <listitem><para> If hs-boot files are considered distinct from their parent source
776 files, and if a <literal>{-# SOURCE #-}</literal> import is considered to refer to the
777 hs-boot file, then the module import graph must have no cycles. The command
778 <command>ghc -M</command> will report an error if a cycle is found.
781 <listitem><para> A module <literal>M</literal> that is
782 <literal>{-# SOURCE #-}</literal>-imported in a program will usually also be
783 ordinarily imported elsewhere. If not, <command>ghc --make</command>
784 automatically adds <literal>M</literal> to the set of modules it tries to
785 compile and link, to ensure that <literal>M</literal>'s implementation is included in
791 A hs-boot file need only contain the bare
792 minimum of information needed to get the bootstrapping process
793 started. For example, it doesn't need to contain declarations
794 for <emphasis>everything</emphasis> that module
795 <literal>A</literal> exports, only the things required by the
796 module(s) that import <literal>A</literal> recursively.</para>
797 <para>A hs-boot file is written in a subset of Haskell:
799 <listitem><para> The module header (including the export list), and import statements, are exactly as in
800 Haskell, and so are the scoping rules.
801 Hence, to mention a non-Prelude type or class, you must import it.</para></listitem>
803 <listitem><para> There must be no value declarations, but there can be type signatures for
806 double :: Int -> Int
809 <listitem><para> Fixity declarations are exactly as in Haskell.</para></listitem>
810 <listitem><para> Type synonym declarations are exactly as in Haskell.</para></listitem>
811 <listitem><para> A data type declaration can either be given in full, exactly as in Haskell, or it
812 can be given abstractly, by omitting the '=' sign and everything that follows. For example:
816 In a <emphasis>source</emphasis> program
817 this would declare TA to have no constructors (a GHC extension: see <xref linkend="nullary-types"/>),
818 but in an hi-boot file it means "I don't know or care what the constructors are".
819 This is the most common form of data type declaration, because it's easy to get right.
820 You <emphasis>can</emphasis> also write out the constructors but, if you do so, you must write
821 it out precisely as in its real definition.</para>
823 If you do not write out the constructors, you may need to give a kind
824 annotation (<xref linkend="kinding"/>), to tell
825 GHC the kind of the type variable, if it is not "*". (In source files, this is worked out
826 from the way the type variable is used in the constructors.) For example:
828 data R (x :: * -> *) y
830 You cannot use <literal>deriving</literal> on a data type declaration; write an
831 <literal>instance</literal> declaration instead.
833 <listitem><para> Class declarations is exactly as in Haskell, except that you may not put
834 default method declarations. You can also omit all the superclasses and class
835 methods entirely; but you must either omit them all or put them all in.
837 <listitem><para> You can include instance declarations just as in Haskell; but omit the "where" part.
844 <sect2 id="using-make">
845 <title>Using <command>make</command></title>
847 <indexterm><primary><literal>make</literal></primary></indexterm>
849 <para>It is reasonably straightforward to set up a
850 <filename>Makefile</filename> to use with GHC, assuming you name
851 your source files the same as your modules. Thus:</para>
855 HC_OPTS = -cpp $(EXTRA_HC_OPTS)
857 SRCS = Main.lhs Foo.lhs Bar.lhs
858 OBJS = Main.o Foo.o Bar.o
860 .SUFFIXES : .o .hs .hi .lhs .hc .s
864 $(HC) -o $@ $(HC_OPTS) $(OBJS)
866 # Standard suffix rules
871 $(HC) -c $< $(HC_OPTS)
874 $(HC) -c $< $(HC_OPTS)
880 $(HC) -c $< $(HC_OPTS)
883 $(HC) -c $< $(HC_OPTS)
885 # Inter-module dependencies
886 Foo.o Foo.hc Foo.s : Baz.hi # Foo imports Baz
887 Main.o Main.hc Main.s : Foo.hi Baz.hi # Main imports Foo and Baz
890 <para>(Sophisticated <command>make</command> variants may
891 achieve some of the above more elegantly. Notably,
892 <command>gmake</command>'s pattern rules let you write the more
893 comprehensible:</para>
897 $(HC) -c $< $(HC_OPTS)
900 <para>What we've shown should work with any
901 <command>make</command>.)</para>
903 <para>Note the cheesy <literal>.o.hi</literal> rule: It records
904 the dependency of the interface (<filename>.hi</filename>) file
905 on the source. The rule says a <filename>.hi</filename> file
906 can be made from a <filename>.o</filename> file by
907 doing…nothing. Which is true.</para>
908 <para> Note that the suffix rules are all repeated twice, once
909 for normal Haskell source files, and once for <filename>hs-boot</filename>
910 files (see <xref linkend="mutual-recursion"/>).</para>
912 <para>Note also the inter-module dependencies at the end of the
913 Makefile, which take the form
916 Foo.o Foo.hc Foo.s : Baz.hi # Foo imports Baz
919 They tell <command>make</command> that if any of
920 <literal>Foo.o</literal>, <literal>Foo.hc</literal> or
921 <literal>Foo.s</literal> have an earlier modification date than
922 <literal>Baz.hi</literal>, then the out-of-date file must be
923 brought up to date. To bring it up to date,
924 <literal>make</literal> looks for a rule to do so; one of the
925 preceding suffix rules does the job nicely. These dependencies
926 can be generated automatically by <command>ghc</command>; see
927 <xref linkend="makefile-dependencies"/></para>
931 <sect2 id="makefile-dependencies">
932 <title>Dependency generation</title>
933 <indexterm><primary>dependencies in Makefiles</primary></indexterm>
934 <indexterm><primary>Makefile dependencies</primary></indexterm>
936 <para>Putting inter-dependencies of the form <literal>Foo.o :
937 Bar.hi</literal> into your <filename>Makefile</filename> by
938 hand is rather error-prone. Don't worry, GHC has support for
939 automatically generating the required dependencies. Add the
940 following to your <filename>Makefile</filename>:</para>
944 ghc -M $(HC_OPTS) $(SRCS)
947 <para>Now, before you start compiling, and any time you change
948 the <literal>imports</literal> in your program, do
949 <command>make depend</command> before you do <command>make
950 cool_pgm</command>. The command <command>ghc -M</command> will
951 append the needed dependencies to your
952 <filename>Makefile</filename>.</para>
954 <para>In general, <command>ghc -M Foo</command> does the following.
955 For each module <literal>M</literal> in the set
956 <literal>Foo</literal> plus all its imports (transitively),
957 it adds to the Makefile:
959 <listitem><para>A line recording the dependence of the object file on the source file.
963 (or <literal>M.lhs</literal> if that is the filename you used).
965 <listitem><para> For each import declaration <literal>import X</literal> in <literal>M</literal>,
966 a line recording the dependence of <literal>M</literal> on <literal>X</literal>:
969 </programlisting></para></listitem>
970 <listitem><para> For each import declaration <literal>import {-# SOURCE #-} X</literal> in <literal>M</literal>,
971 a line recording the dependence of <literal>M</literal> on <literal>X</literal>:
975 (See <xref linkend="mutual-recursion"/> for details of
976 <literal>hi-boot</literal> style interface files.)
979 If <literal>M</literal> imports multiple modules, then there will
980 be multiple lines with <filename>M.o</filename> as the
982 <para>There is no need to list all of the source files as arguments to the <command>ghc -M</command> command;
983 <command>ghc</command> traces the dependencies, just like <command>ghc --make</command>
984 (a new feature in GHC 6.4).</para>
986 <para>Note that <literal>ghc -M</literal> needs to find a <emphasis>source
987 file</emphasis> for each module in the dependency graph, so that it can
988 parse the import declarations and follow dependencies. Any pre-compiled
989 modules without source files must therefore belong to a
990 package<footnote><para>This is a change in behaviour relative to 6.2 and
994 <para>By default, <command>ghc -M</command> generates all the
995 dependencies, and then concatenates them onto the end of
996 <filename>makefile</filename> (or
997 <filename>Makefile</filename> if <filename>makefile</filename>
998 doesn't exist) bracketed by the lines "<literal># DO NOT
999 DELETE: Beginning of Haskell dependencies</literal>" and
1000 "<literal># DO NOT DELETE: End of Haskell
1001 dependencies</literal>". If these lines already exist in the
1002 <filename>makefile</filename>, then the old dependencies are
1003 deleted first.</para>
1005 <para>Don't forget to use the same <option>-package</option>
1006 options on the <literal>ghc -M</literal> command line as you
1007 would when compiling; this enables the dependency generator to
1008 locate any imported modules that come from packages. The
1009 package modules won't be included in the dependencies
1010 generated, though (but see the
1011 <option>––include-pkg-deps</option> option below).</para>
1013 <para>The dependency generation phase of GHC can take some
1014 additional options, which you may find useful. For historical
1015 reasons, each option passed to the dependency generator from
1016 the GHC command line must be preceded by
1017 <literal>-optdep</literal>. For example, to pass <literal>-f
1018 .depend</literal> to the dependency generator, you say
1021 ghc -M -optdep-f -optdep.depend ...
1024 The options which affect dependency generation are:</para>
1028 <term><option>-ddump-mod-cycles</option></term>
1030 <para>Display a list of the cycles in the module graph. This is
1031 useful when trying to eliminate such cycles. You do not need the <literal>-optdep</literal> prefix
1032 for this flag.</para>
1037 <term><option>-w</option></term>
1039 <para>Turn off warnings about interface file shadowing.</para>
1044 <term><option>-v2</option></term>
1046 <para>Print a full list of the module dependencies to stdout.
1047 (This is the standard verbosity flag, so the list will
1048 also be displayed with <option>-v3</option> and
1049 <option>-v4</option>;
1050 <xref linkend ="options-help"/>.)</para>
1055 <term><option>-f</option> <replaceable>file</replaceable></term>
1057 <para>Use <replaceable>file</replaceable> as the makefile,
1058 rather than <filename>makefile</filename> or
1059 <filename>Makefile</filename>. If
1060 <replaceable>file</replaceable> doesn't exist,
1061 <command>mkdependHS</command> creates it. We often use
1062 <option>-f .depend</option> to put the dependencies in
1063 <filename>.depend</filename> and then
1064 <command>include</command> the file
1065 <filename>.depend</filename> into
1066 <filename>Makefile</filename>.</para>
1070 <!-- Retired with the move away from 'mkdependHS'.
1072 <term><option>-o <osuf></option></term>
1074 <para>Use <filename>.<osuf></filename> as the
1075 "target file" suffix ( default: <literal>o</literal>).
1076 Multiple <option>-o</option> flags are permitted
1077 (GHC2.05 onwards). Thus "<option>-o hc -o o</option>"
1078 will generate dependencies for <filename>.hc</filename>
1079 and <filename>.o</filename> files.</para>
1084 <term><option>-s <suf></option></term>
1086 <para>Make extra dependencies that declare that files
1088 <filename>.<suf>_<osuf></filename>
1089 depend on interface files with suffix
1090 <filename>.<suf>_hi</filename>, or (for
1091 <literal>{-# SOURCE #-}</literal>
1092 imports) on <filename>.hi-boot</filename>. Multiple
1093 <option>-s</option> flags are permitted. For example,
1094 <option>-o hc -s a -s b</option> will make dependencies
1095 for <filename>.hc</filename> on
1096 <filename>.hi</filename>,
1097 <filename>.a_hc</filename> on
1098 <filename>.a_hi</filename>, and
1099 <filename>.b_hc</filename> on
1100 <filename>.b_hi</filename>. (Useful in
1101 conjunction with NoFib "ways".)</para>
1106 <term><option>––exclude-module=<file></option></term>
1108 <para>Regard <filename><file></filename> as
1109 "stable"; i.e., exclude it from having dependencies on
1115 <term><option>-x</option></term>
1117 <para>same as <option>––exclude-module</option></para>
1121 <!-- Not currently implemented:
1123 <term><option>––exclude-directory=<dirs></option></term>
1125 <para>Regard the colon-separated list of directories
1126 <filename><dirs></filename> as containing stable,
1127 don't generate any dependencies on modules
1133 <term><option>––include-module=<file></option></term>
1135 <para>Regard <filename><file></filename> as not
1136 "stable"; i.e., generate dependencies on it (if
1137 any). This option is normally used in conjunction with
1138 the <option>––exclude-directory</option> option.</para>
1144 <term><option>––include-pkg-deps</option></term>
1146 <para>Regard modules imported from packages as unstable,
1147 i.e., generate dependencies on any imported package modules
1148 (including <literal>Prelude</literal>, and all other
1149 standard Haskell libraries). Dependencies are not traced
1150 recursively into packages; dependencies are only generated for
1151 home-package modules on external-package modules directly imported
1152 by the home package module.
1153 This option is normally
1154 only used by the various system libraries.</para>
1161 <sect2 id="orphan-modules">
1162 <title>Orphan modules and instance declarations</title>
1164 <para> Haskell specifies that when compiling module M, any instance
1165 declaration in any module "below" M is visible. (Module A is "below"
1166 M if A is imported directly by M, or if A is below a module that M imports directly.)
1167 In principle, GHC must therefore read the interface files of every module below M,
1168 just in case they contain an instance declaration that matters to M. This would
1169 be a disaster in practice, so GHC tries to be clever. </para>
1171 <para>In particular, if an instance declaration is in the same module as the definition
1172 of any type or class mentioned in the <emphasis>head</emphasis> of the instance declaration
1173 (the part after the “<literal>=></literal>”; see <xref linkend="instance-rules"/>), then
1174 GHC has to visit that interface file anyway. Example:</para>
1177 instance C a => D (T a) where ...
1180 <para> The instance declaration is only relevant if the type T is in use, and if
1181 so, GHC will have visited A's interface file to find T's definition. </para>
1183 <para> The only problem comes when a module contains an instance declaration
1184 and GHC has no other reason for visiting the module. Example:
1187 instance C a => D (T a) where ...
1190 Here, neither D nor T is declared in module Orphan.
1191 We call such modules “orphan modules”.
1192 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.
1198 Functional dependencies complicate matters. Suppose we have:
1201 instance E T Int where ...
1204 Is this an orphan module? Apparently not, because <literal>T</literal>
1205 is declared in the same module. But suppose class <literal>E</literal> had a
1206 functional dependency:
1209 class E x y | y -> x where ...
1211 Then in some importing module M, the constraint <literal>(E a Int)</literal> should be "improved" by setting
1212 <literal>a = T</literal>, <emphasis>even though there is no explicit mention
1213 of <literal>T</literal> in M</emphasis>.</para>
1215 These considerations lead to the following definition of an orphan module:
1217 <listitem> <para> An <emphasis>orphan module</emphasis>
1218 <indexterm><primary>orphan module</primary></indexterm>
1219 contains at least one <emphasis>orphan instance</emphasis> or at
1220 least one <emphasis>orphan rule</emphasis>.</para> </listitem>
1222 <listitem><para> An instance declaration in a module M is an <emphasis>orphan instance</emphasis> if
1223 <indexterm><primary>orphan instance</primary></indexterm>
1226 The class of the instance declaration is not declared in M, and
1229 <para> <emphasis>Either</emphasis> the class has no functional dependencies, and none of the type constructors
1230 in the instance head is declared in M; <emphasis>or</emphasis> there
1231 is a functional dependency for which none of the type constructors mentioned
1232 in the <emphasis>non-determined</emphasis> part of the instance head is defined in M.
1236 <para> Only the instance head
1237 counts. In the example above, it is not good enough for C's declaration
1238 to be in module A; it must be the declaration of D or T.</para>
1241 <listitem><para> A rewrite rule in a module M is an <emphasis>orphan rule</emphasis>
1242 <indexterm><primary>orphan rule</primary></indexterm>
1243 if none of the variables, type constructors,
1244 or classes that are free in the left hand side of the rule are declared in M.
1250 <para>If you use the flag <option>-fwarn-orphans</option>, GHC will warn you
1251 if you are creating an orphan module.
1252 Like any warning, you can switch the warning off with <option>-fno-warn-orphans</option>,
1253 and <option>-Werror</option>
1254 will make the compilation fail if the warning is issued.
1257 You can identify an orphan module by looking in its interface
1258 file, <filename>M.hi</filename>, using the
1259 <link linkend="modes"><option>--show-iface</option> mode</link>. If there is a <literal>[orphan module]</literal> on the
1260 first line, GHC considers it an orphan module.
1267 ;;; Local Variables: ***
1269 ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter" "sect1") ***