GHC's compiled output normally goes into a
.hc, .o, etc.,
file, depending on the last-run compilation phase. The
option -o foo re-directs the output of that
last-run phase to file foo.
Note: this “feature” can be
counterintuitive: ghc -C -o foo.o foo.hs
will put the intermediate C code in the file
foo.o, name notwithstanding!
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).
-odir
The -o option isn't of much use if
you have several input files…
Non-interface output files are normally put in the same
directory as their corresponding input file came from. You
may specify that they be put in another directory using the
-odir <dir> (the “Oh,
dear” option). For example:
The output files, Foo.o,
Bar.o, and
Bumble.o would be put into a
subdirectory named after the architecture of the executing
machine (sun4,
mips, etc). The directory must already
exist; it won't be created.
Note that the -odir option does
not affect where the interface files
are put. In the above example, they would still be put in
parse/Foo.hi,
parse/Bar.hi, and
gurgle/Bumble.hi.
-ohifile
The interface output may be directed to another file
bar2/Wurble.iface with the option
-ohi bar2/Wurble.iface (not
recommended).
WARNING: if you redirect the interface file somewhere
that GHC can't find it, then the recompilation checker may
get confused (at the least, you won't get any recompilation
avoidance). We recommend using a combination of
-hidir and -hisuf options
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.
-hidirdirectory
Redirects all generated interface files into
directory, instead of the default
which is to place the interface file in the same directory
as the source file.
-osufsuffix, -hisufsuffix, -hcsufsuffix
EXOTICA: The -osufsuffix will change the
.o file 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.
Similarly, the -hisufsuffix will change the
.hi file suffix for non-system interface
files (see Section 4.9.4).
Finally, the option -hcsufsuffix will change the
.hc file suffix for compiler-generated
intermediate C files.
The -hisuf/-osuf
game is particularly useful if you want to compile a program both with and without
profiling, in the same directory. You can say:
The following options are useful for keeping certain
intermediate files around, when normally GHC would throw these
away after compilation:
-keep-hc-files
Keep intermediate .hc files when
doing .hs-to-.o
compilations via C (NOTE: .hc files
aren't generated when using the native code generator, you
may need to use -fvia-C to force them
to be produced).
-keep-s-files
Keep intermediate .s files.
-keep-raw-s-files
Keep intermediate .raw-s files.
These are the direct output from the C compiler, before
GHC does “assembly mangling” to produce the
.s file. Again, these are not produced
when using the native code generator.
-keep-tmp-files
Instructs the GHC driver not to delete any of its
temporary files, which it normally keeps in
/tmp (or possibly elsewhere; see Section 4.7.2). Running GHC with
-v will show you what temporary files
were generated along the way.
If you have trouble because of running out of space
in /tmp (or wherever your
installation thinks temporary files should go), you may
use the -tmpdir
<dir> option to specify
an alternate directory. For example, -tmpdir
. says to put temporary files in the current
working directory.
Alternatively, use your TMPDIR
environment variable. Set it to the
name of the directory where temporary files should be put.
GCC and other programs will honour the
TMPDIR variable as well.
Even better idea: Set the
DEFAULT_TMPDIR make variable when
building GHC, and never worry about
TMPDIR again. (see the build
documentation).