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!
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.
EXOTICA: The -osuf <suffix> will change the .o file suffix for object files to whatever you specify. (We use this in compiling the prelude.).
Similarly, the -hisuf <suffix> will change the .hi file suffix for non-system interface files (see Section 4.9.3).
The -hisuf/-osuf game is useful if you want to compile a program with both GHC and HBC (say) in the same directory. Let HBC use the standard .hi/.o suffixes; add -hisuf g_hi -osuf g_o to your make rule for GHC compiling…
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).