Download The Glorious Glasgow Haskell Compilation System User`s Guide

The Glorious Glasgow Haskell Compilation System User’s Guide, Version 7.10.2
51 / 327
You should think of the object file and the interface file as a pair, since the interface file is in a sense a compiler-readable
description of the contents of the object file. If the interface file and object file get out of sync for any reason, then the compiler
may end up making assumptions about the object file that aren’t true; trouble will almost certainly follow. For this reason, we
recommend keeping object files and interface files in the same place (GHC does this by default, but it is possible to override the
defaults as we’ll explain shortly).
Every module has a module name defined in its source code (module A.B.C where ...).
The name of the object file generated by GHC is derived according to the following rules, where osuf is the object-file suffix
(this can be changed with the -osuf option).
• If there is no -odir option (the default), then the object filename is derived from the source filename (ignoring the module
name) by replacing the suffix with osuf .
• If -odir dir has been specified, then the object filename is dir /mod .osuf , where mod is the module name with dots replaced
by slashes. GHC will silently create the necessary directory structure underneath dir , if it does not already exist.
The name of the interface file is derived using the same rules, except that the suffix is hisuf (.hi by default) instead of osuf ,
and the relevant options are -hidir and -hisuf instead of -odir and -osuf respectively.
For example, if GHC compiles the module A.B.C in the file src/A/B/C.hs, with no -odir or -hidir flags, the interface
file will be put in src/A/B/C.hi and the object file in src/A/B/C.o.
For any module that is imported, GHC requires that the name of the module in the import statement exactly matches the name
of the module in the interface file (or source file) found using the strategy specified in Section 4.7.3. This means that for most
modules, the source file name should match the module name.
However, note that it is reasonable to have a module Main in a file named foo.hs, but this only works because GHC never
needs to search for the interface for module Main (because it is never imported). It is therefore possible to have several Main
modules in separate source files in the same directory, and GHC will not get confused.
In batch compilation mode, the name of the object file can also be overridden using the -o option, and the name of the interface
file can be specified directly using the -ohi option.
4.7.3
The search path
In your program, you import a module Foo by saying import Foo. In --make mode or GHCi, GHC will look for a source
file for Foo and arrange to compile it first. Without --make, GHC will look for the interface file for Foo, which should have
been created by an earlier compilation of Foo. GHC uses the same strategy in each of these cases for finding the appropriate file.
This strategy is as follows: GHC keeps a list of directories called the search path. For each of these directories, it tries appending
basename.extension to the directory, and checks whether the file exists. The value of basename is the module name with
dots replaced by the directory separator (’/’ or ’\’, depending on the system), and extension is a source extension (hs, lhs) if
we are in --make mode or GHCi, or hisuf otherwise.
For example, suppose the search path contains directories d1, d2, and d3, and we are in --make mode looking for the source
file for a module A.B.C. GHC will look in d1/A/B/C.hs, d1/A/B/C.lhs, d2/A/B/C.hs, and so on.
The search path by default contains a single directory: “.” (i.e. the current directory). The following options can be used to add
to or change the contents of the search path:
-idirs This flag appends a colon-separated list of dirs to the search path.
-i resets the search path back to nothing.
This isn’t the whole story: GHC also looks for modules in pre-compiled libraries, known as packages. See the section on
packages (Section 4.9) for details.