+ <para>resets the search path back to nothing.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>This isn't the whole story: GHC also looks for modules in
+ pre-compiled libraries, known as packages. See the section on
+ packages (<xref linkend="packages">), for details.</para>
+ </sect2>
+
+ <sect2 id="options-output">
+ <title>Redirecting the compilation output(s)</title>
+
+ <indexterm><primary>output-directing options</primary></indexterm>
+ <indexterm><primary>redirecting compilation output</primary></indexterm>
+
+ <variablelist>
+ <varlistentry>
+ <term><option>-o</option> <replaceable>file</replaceable></term>
+ <indexterm><primary><option>-o</option></primary></indexterm>
+ <listitem>
+ <para>GHC's compiled output normally goes into a
+ <filename>.hc</filename>, <filename>.o</filename>, etc.,
+ file, depending on the last-run compilation phase. The
+ option <option>-o <replaceable>file</replaceable></option>
+ re-directs the output of that last-run phase to
+ <replaceable>file</replaceable>.</para>
+
+ <para>Note: this “feature” can be
+ counterintuitive: <command>ghc -C -o foo.o
+ foo.hs</command> will put the intermediate C code in the
+ file <filename>foo.o</filename>, name
+ notwithstanding!</para>
+
+ <para>This option is most often used when creating an
+ executable file, to set the filename of the executable.
+ For example:
+<screen> ghc -o prog --make Main</screen>
+
+ will compile the program starting with module
+ <literal>Main</literal> and put the executable in the
+ file <literal>prog</literal>.</para>
+
+ <para>Note: on Windows, if the result is an executable
+ file, the extension "<filename>.exe</filename>" is added
+ if the specified filename does not already have an
+ extension. Thus
+<programlisting>
+ ghc -o foo Main.hs
+</programlisting>
+ will compile and link the module
+ <filename>Main.hs</filename>, and put the resulting
+ executable in <filename>foo.exe</filename> (not
+ <filename>foo</filename>).</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-odir</option> <replaceable>dir</replaceable></term>
+ <indexterm><primary><option>-odir</option></primary></indexterm>
+ <listitem>
+ <para>Redirects object files to directory
+ <replaceable>dir</replaceable>. For example:</para>
+
+<Screen>
+$ ghc -c parse/Foo.hs parse/Bar.hs gurgle/Bumble.hs -odir `arch`
+</Screen>
+
+ <para>The object files, <filename>Foo.o</filename>,
+ <filename>Bar.o</filename>, and
+ <filename>Bumble.o</filename> would be put into a
+ subdirectory named after the architecture of the executing
+ machine (<filename>x86</filename>,
+ <filename>mips</filename>, etc).</para>
+
+ <para>Note that the <option>-odir</option> option does
+ <emphasis>not</emphasis> affect where the interface files
+ are put; use the <option>-hidir</option> option for that.
+ In the above example, they would still be put in
+ <filename>parse/Foo.hi</filename>,
+ <filename>parse/Bar.hi</filename>, and
+ <filename>gurgle/Bumble.hi</filename>.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-ohi</option> <replaceable>file</replaceable></term>
+ <indexterm><primary><option>-ohi</option></primary>
+ </indexterm>
+ <listitem>
+ <para>The interface output may be directed to another file
+ <filename>bar2/Wurble.iface</filename> with the option
+ <option>-ohi bar2/Wurble.iface</option> (not
+ recommended).</para>
+
+ <para>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 <option>-hidir</option> and
+ <option>-hisuf</option> options instead, if
+ possible.</para>
+
+ <para>To avoid generating an interface at all, you could
+ use this option to redirect the interface into the bit
+ bucket: <literal>-ohi /dev/null</literal>, for
+ example.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-hidir</option> <replaceable>dir</replaceable></term>
+ <indexterm><primary><option>-hidir</option></primary>
+ </indexterm>
+ <listitem>
+ <para>Redirects all generated interface files into
+ <replaceable>dir</replaceable>, instead of the
+ default.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-osuf</option> <replaceable>suffix</replaceable></term>
+ <term><option>-hisuf</option> <replaceable>suffix</replaceable></term>
+ <term><option>-hcsuf</option> <replaceable>suffix</replaceable></term>
+ <indexterm><primary><option>-osuf</option></primary></indexterm>
+ <indexterm><primary><option>-hisuf</option></primary></indexterm>
+ <indexterm><primary><option>-hcsuf</option></primary></indexterm>
+ <listitem>
+ <para>The <option>-osuf</option>
+ <replaceable>suffix</replaceable> will change the
+ <literal>.o</literal> 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.</para>
+
+ <para>Similarly, the <option>-hisuf</option>
+ <replaceable>suffix</replaceable> will change the
+ <literal>.hi</literal> file suffix for non-system
+ interface files (see <XRef LinkEnd="hi-options">).</para>
+
+ <para>Finally, the option <option>-hcsuf</option>
+ <replaceable>suffix</replaceable> will change the
+ <literal>.hc</literal> file suffix for compiler-generated
+ intermediate C files.</para>
+
+ <para>The <option>-hisuf</option>/<option>-osuf</option>
+ game is particularly useful if you want to compile a
+ program both with and without profiling, in the same
+ directory. You can say:
+ <Screen>
+ ghc ...</Screen>
+ to get the ordinary version, and
+ <Screen>
+ ghc ... -osuf prof.o -hisuf prof.hi -prof -auto-all</Screen>
+ to get the profiled version.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </sect2>
+
+ <sect2 id="keeping-intermediates">
+ <title>Keeping Intermediate Files</title>
+ <indexterm><primary>intermediate files, saving</primary>
+ </indexterm>
+ <indexterm><primary><literal>.hc</literal> files, saving</primary>
+ </indexterm>
+ <indexterm><primary><literal>.s</literal> files, saving</primary>
+ </indexterm>
+
+ <para>The following options are useful for keeping certain
+ intermediate files around, when normally GHC would throw these
+ away after compilation:</para>
+
+ <variablelist>
+ <varlistentry>
+ <term><option>-keep-hc-files</option></term>
+ <indexterm>
+ <primary><option>-keep-hc-files</option></primary>
+ </indexterm>
+ <listitem>
+ <para>Keep intermediate <literal>.hc</literal> files when
+ doing <literal>.hs</literal>-to-<literal>.o</literal>
+ compilations via C (NOTE: <literal>.hc</literal> files
+ aren't generated when using the native code generator, you
+ may need to use <option>-fvia-C</option> to force them
+ to be produced).</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-keep-s-files</option></term>
+ <indexterm>
+ <primary><option>-keep-s-files</option></primary>
+ </indexterm>
+ <listitem>
+ <para>Keep intermediate <literal>.s</literal> files.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-keep-raw-s-files</option></term>
+ <indexterm>
+ <primary><option>-keep-raw-s-files</option></primary>
+ </indexterm>
+ <listitem>
+ <para>Keep intermediate <literal>.raw-s</literal> files.
+ These are the direct output from the C compiler, before
+ GHC does “assembly mangling” to produce the
+ <literal>.s</literal> file. Again, these are not produced
+ when using the native code generator.</para>