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
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:
% ghc -c parse/Foo.hs parse/Bar.hs gurgle/Bumble.hs -odir `arch`
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.
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.
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.
EXOTICA: The -osuf suffix 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 -hisuf suffix will change the .hi file suffix for non-system interface files (see Section 4.9.4).
Finally, the option -hcsuf suffix 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:
ghc ... -osuf prof.o -hisuf prof.hi -prof -auto-all
The following options are useful for keeping certain intermediate files around, when normally GHC would throw these away after compilation:
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 intermediate .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.
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).