text: 7.8. Filenames and separate compilation¶
  This.
  7.8.1. Haskell source files¶.
  7.8.2. Output files¶).
  - If there is no
  -odiroption (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. 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..
  7.8.3. The search path¶ isn’t the whole story: GHC also looks for modules in pre-compiled libraries, known as packages. See the section on packages (Packages) for details.
  7.8.4. Redirecting the compilation output(s)¶
  -o
  ⟨file⟩¶
  GHC’s compiled output normally goes into a
  .hc,
  .o, etc., file, depending on the last-run compilation phase. The option
  -o filere-directs the output of that last-run phase to ⟨file⟩.
  Note
  This “feature” can be counterintuitive:
  ghc -C -o foo.o foo.hswill put the intermediate C code in the file
  foo.o, name notwithstanding!
  This option is most often used when creating an executable file, to set the filename of the executable. For example:
  ghc -o prog --make Main
  will compile the program starting with module
  Mainand put the executable in the file
  prog.
  Note: on Windows, if the result is an executable file, the extension “
  .exe” is added if the specified filename does not already have an extension. Thus
  ghc -o foo Main.hs
  will compile and link the module
  Main.hs, and put the resulting executable in
  foo.exe(not
  foo).
  If you use
  ghc --makeand you don’t use the
  -o, the name GHC will choose for the executable will be based on the name of the file containing the module
  Main. Note that with GHC the
  Mainmodule doesn’t have to be put in file
  Main.hs. Thus both
  ghc --make Prog
  and
  ghc --make Prog.hs
  will produce
  Prog(or
  Prog.exeif you are on Windows).
  -odir
  ⟨dir⟩¶
  Redirects object files to directory ⟨dir⟩. For example:
  $ ghc -c parse/Foo.hs parse/Bar.hs gurgle/Bumble.hs -odir `uname -m`
  The object files,
  Foo.o,
  Bar.o, and
  Bumble.owould be put into a subdirectory named after the architecture of the executing machine (
  x86,
  mips, etc).
  Note that the
  -odiroption does not affect where the interface files are put; use the
  -hidiroption for that. In the above example, they would still be put in
  parse/Foo.hi,
  parse/Bar.hi, and
  gurgle/Bumble.hi.
  -ohi
  ⟨file⟩¶
  The interface output may be directed to another file
  bar2/Wurble.ifacewand
  -hisufoptions instead, if possible.
  To avoid generating an interface at all, you could use this option to redirect the interface into the bit bucket:
  -ohi /dev/null, for example.
  -stubdir
  ⟨dir⟩¶
  Redirects all generated FFI stub files into ⟨dir⟩. Stub files are generated when the Haskell source contains a
  foreign exportor
  foreign import "&wrapper"declaration (see Using foreign export and foreign import ccall “wrapper” with GHC). The
  -stubdiroption behaves in exactly the same way as
  -odirand
  -hidirwith respect to hierarchical modules.
  -dumpdir
  ⟨dir⟩¶
  Redirects all dump files into ⟨dir⟩. Dump files are generated when
  -ddump-to-fileis used with other
  -ddump-*flags.
  -outputdir
  ⟨dir⟩¶
  The
  -outputdiroption is shorthand for the combination of
  -odir ⟨dir⟩,
  -hidir ⟨dir⟩,
  -stubdir ⟨dir⟩and
  -dumpdir ⟨dir⟩.
  -osuf
  ⟨suffix⟩¶
  The
  -osuf⟨suffix⟩ will change the
  .ofile suffix for object files to whatever you specify. We use this when compiling libraries, so that objects for the profiling versions of the libraries don’t clobber the normal ones.
  -hisuf
  ⟨suffix⟩¶
  Similarly, the
  -hisuf⟨suffix⟩ will change the
  .hifile suffix for non-system interface files (see Other options related to interface files).
  The
  -hisuf/
  -osufgame is particularly useful if you want to compile a program both with and without profiling, in the same directory. You can say:
  ghc ...
  to get the ordinary version, and
  ghc ... -osuf prof.o -hisuf prof.hi -prof -fprof-auto
  to get the profiled version.
  7.8.5. Keeping Intermediate Files¶
  The following options are useful for keeping (or not keeping) certain intermediate files around, when normally GHC would throw these away after compilation:
  -keep-hc-file¶
  -keep-hc-files¶
  Keep intermediate
  .hcfiles when doing
  .hs-to-
  .ocompilations via C (Note:
  .hcfiles are only generated by unregisterised compilers).
  -keep-hi-files¶
  Keep intermediate
  .hifiles. This is the default. You may use
  -no-keep-hi-filesif you are not interested in the
  .hifiles.
  -keep-llvm-file¶
  -keep-llvm-files¶
  Keep intermediate
  .llfiles when doing
  .hs-to-
  .ocompilations via LLVM (Note:
  .llfiles aren’t generated when using the native code generator, you may need to use
  -fllvmto force them to be produced).
  -keep option to specify an alternate directory. For example,
  -tmpdir .says to put temporary files in the current working directory.
  Alternatively, use your
  TMPDIRenvironment variable. Set it to the name of the directory where temporary files should be put. GCC and other programs will honour the
  TMPDIRvariable as well.
  7.8.8. The recompilation checker¶
  -fforce-recomp¶
  Turn off recompilation checking (which is on by default). Recompilation checking normally stops compilation early, leaving an existing
  .ofile module
  A might require
  module
  C to be recompiled, and hence when
  A.hi changes we should
  check whether
  C should be recompiled. However, the dependencies of
  C will only list
  B.hi, not
  A.hi, and some changes to
  A
  (changing the definition of a function that appears in an inlining of a
  function exported by
  B, say) may conceivably not change
  B.hi one
  jot. So now…
  GHC.
  7.8.9. How to compile mutually recursive modules¶is a programmer-written source file. It must live in the same directory as its parent source file
  A.hs. Currently, if you use a literate source file
  A.lhsyou must also use a literate boot file,
  A.lhs-boot; and vice versa.
  A
  hs-bootfile is compiled by GHC, just like a
  hsfile:
  ghc -c A.hs-boot
  When a hs-boot file
  A.hs-bootis compiled, it is checked for scope and type errors. When its parent module
  A.hsis compiled, the two are compared, and an error is reported if the two are inconsistent.
  Just as compiling
  A.hsproduces an interface file
  A.hi, and an object file
  A.o, so compiling
  A.hs-bootproduces an interface file
  A.hi-boot, and a pseudo-object file
  A.o-boot:
  - The pseudo-object file
  A.o-bootis empty (don’t link it!), but it is very useful when using a Makefile, to record when the
  A.hi-bootwas last brought up to date (see Using make).
  - The
  hi-bootgenerated by compiling a
  hs-bootfile is in the same machine-generated binary format as any other GHC-generated interface file (e.g.
  B.hi). You can display its contents with
  ghc --show-iface. If you specify a directory for interface files, the
  -ohidirflag, then that affects
  hi-bootfiles too.
  If hs-boot files are considered distinct from their parent source files, and if a
  {-# SOURCE #-}import is considered to refer to the hs-boot file, then the module import graph must have no cycles. The command
  ghc -Mwill report an error if a cycle is found.
  A module
  Mthat is
  {-# SOURCE #-}-imported in a program will usually also be ordinarily imported elsewhere. If not,
  ghc --makeautomatically adds
  Mtoclauseon a data type declaration; write an
  instancedeclaration.)
  7.8.10. Module signatures¶:
  - The ability to define an
  hsigfile, containing type definitions and type signature for values which can be used by modules that import the signature, and must be provided by the eventual implementing module, and
  - The ability to inherit required signatures from packages we depend upon, combining the signatures into a single merged signature which reflects the requirements of any locally defined signature, as well as the requirements of our dependencies.
  Awould have to export the function
  doublewith a type definitionally equal to the signature. Note that this means you can’t implement
  doubleusingclauseor
  typedeclarations.fromfor
  []and
  Charwhich:
  - Pattern synonyms are not supported.
  - Algebraic data types specified in a signature cannot be implemented using pattern synonyms. See Trac #12717
  7.8.11. Using
  make¶
  It is reasonably straightforward to set up a
  Makefile to use with
  GHC, assuming you name your source files the same as your modules. Thus:
  HC = ghc HC_OPTS = -cpp $(EXTRA_HC_OPTS) SRCS = Main.lhs Foo.lhs Bar.lhs OBJS = Main.o Foo.o Bar.o .SUFFIXES : .o .hs .hi .lhs .hc .s cool_pgm : $(OBJS) rm -f $@ $(HC) -o $@ $(HC_OPTS) $(OBJS) # Standard suffix rules .o.hi: @: .lhs.o: $(HC) -c $< $(HC_OPTS) .hs.o: $(HC) -c $< $(HC_OPTS)  pattern rules let you write the more comprehensible:
  %.o : %.lhs $(HC) -c $< $(HC_OPTS)
  What we’ve shown should work with any
  make.
  Note the cheesy
  .o.hi rule: It records the dependency of the
  interface (
  .hi) file on the source. The rule says a
  .hi file can
  be made from a
  .o file by doing…nothing. Which is true.
  Note that the suffix rules are all repeated twice, once for normal
  Haskell source files, and once for
  hs-boot files (see
  How to compile mutually recursive modules).
  Note also the inter-module dependencies at the end of the Makefile, which take the form
  Foo.o Foo.hc Foo.s : Baz.hi # Foo imports Baz. These dependencies can be generated automatically by
  ghc;
  see Dependency generation
  7.8.12. Dependency generation¶if that is the filename you used).
  For each import declaration
  import Xin
  M, a line recording the dependence of
  Mon
  X:
  M.o : X.hi
  For each import declaration
  import {-# SOURCE #-} Xin
  M, a line recording the dependence of
  Mon
  X:
  M.o : X.hi-boot
  (See How to compile mutually recursive modules for details of
  hi-bootstyle:
  -ddump-mod-cycles¶
  Display a list of the cycles in the module graph. This is useful when trying to eliminate such cycles.
  -v2
  Print a full list of the module dependencies to stdout. (This is the standard verbosity flag, so the list will also be displayed with
  -v3and
  -v4; see Verbosity options.)
  -dep-makefile
  ⟨file⟩¶
  Use ⟨file⟩ as the makefile, rather than
  makefileor
  Makefile. If ⟨file⟩ doesn’t exist,
  mkdependHScreates it. We often use
  -dep-makefile .dependto put the dependencies in
  .dependand then
  includethe file
  .dependinto
  Makefile.
  -dep-suffix
  ⟨as “stable”; i.e., exclude it from having dependencies on it.
  -include-pkg-deps¶.
  7.8.13. Orphan modules and instance declarations¶  definition.
  The only problem comes when a module contains an instance declaration and GHC has no other reason for visiting the module. Example:
  module Orphan where instance C a => D (T a) where ... class C a where ...
  Here, neither
  D nor
  T is declared in module
  Orphan. We call such modules
  “orphan modules”.
  Mis an orphan instance if orphan instance
  - The class of the instance declaration is not declared in
  M, and
  - Either the class has no functional dependencies, and none of the type constructors in the instance head is declared in
  M; or there is a functional dependency for which none of the type constructors mentioned in the non-determined part of the instance head is defined in
  M.
  Only the instance head counts. In the example above, it is not good enough for
  C‘s declaration to be in module
  A; it must be the declaration of
  Dor
  T.
  A rewrite rule in a module
  Mis an orphan rule orphan rule if none of the variables, type constructors, or classes that are free in the left hand side of the rule are declared in
  M..