ghc ––make Main.hs
</screen>
- <para>The command line must contain one source file or module
- name; GHC will figure out all the modules in the program by
- following the imports from this initial module. It will then
- attempt to compile each module which is out of date, and finally
- if the top module is <literal>Main</literal>, the program
+ <para>The command line may contain any number of source file names
+ or module names; GHC will figure out all the modules in the
+ program by following the imports from these initial modules. It
+ will then attempt to compile each module which is out of date, and
+ finally if there is a <literal>Main</literal> module, the program
will also be linked into an executable.</para>
<para>The main advantages to using <literal>ghc ––make</literal>
linkend="source-file-options">).</para>
<para>If the program needs to be linked with additional objects
- (say, some auxilliary C code), these can be specified on the
- command line as usual.</para>
+ (say, some auxilliary C code), then the object files can be
+ given on the command line and GHC will include them when linking
+ the executable.</para>
<para>Note that GHC can only follow dependencies if it has the
source file available, so if your program includes a module for
intermediate C files.</para>
<para>The <option>-hisuf</option>/<option>-osuf</option>
- 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 <filename>.hi</filename>/<filename>.o</filename>
- suffixes; add <option>-hisuf g_hi -osuf
- g_o</option> to your <command>make</command> rule for
- GHC compiling…</para>
+ 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>
generated during compilation. By default, you get a standard set
of warnings which are generally likely to indicate bugs in your
program. These are:
- <option>-fwarn-overlpapping-patterns</option>,
+ <option>-fwarn-overlapping-patterns</option>,
<option>-fwarn-deprecations</option>,
<option>-fwarn-duplicate-exports</option>,
<option>-fwarn-missing-fields</option>, and
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><option>-Werror</option>:</term>
+ <listitem>
+ <indexterm><primary><option>-Werror</option></primary></indexterm>
+ <para>Makes any warning into a fatal error. Useful so that you don't
+ miss warnings when doing batch compilation. </para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
<para>The full set of warning options is described below. To turn
an instance declaration is missing one or more methods, and
the corresponding class declaration has no default
declaration for them.</para>
+ <para>The warning is suppressed if the method name
+ begins with an underscore. Here's an example where this is useful:
+ <programlisting>
+ class C a where
+ _simpleFn :: a -> String
+ complexFn :: a -> a -> String
+ complexFn x y = ... _simpleFn ...
+ </programlisting>
+ The idea is that: (a) users of the class will only call <literal>complexFn</literal>;
+ never <literal>_simpleFn</literal>; and (b)
+ instance declarations can define either <literal>complexFn</literal> or <literal>_simpleFn</literal>.
+ </para>
</listitem>
</varlistentry>
<para>Report all unused variables which arise from pattern
matches, including patterns consisting of a single variable.
For instance <literal>f x y = []</literal> would report
- <VarName>x</VarName> and <VarName>y</VarName> as unused. To
- eliminate the warning, all unused variables can be replaced
- with wildcards.</para>
+ <VarName>x</VarName> and <VarName>y</VarName> as unused. The
+ warning is suppressed if the variable name begins with an underscore, thus:
+ <programlisting>
+ f _x = True
+ </programlisting>
+ </para>
</listitem>
</varlistentry>
&runtime;
<sect1 id="ext-core">
- <title>Generating External Core Files</title>
+ <title>Generating and compiling External Core Files</title>
<indexterm><primary>intermediate code generation</primary></indexterm>
files is <emphasis>different</emphasis> (though similar) to the Core output format generated
for debugging purposes (<xref linkend="options-debugging">).</para>
+ <para>The Core format natively supports notes which you can add to
+ your source code using the <literal>CORE</literal> pragma (see <xref
+ linkend="pragmas">).</para>
+
<variablelist>
<varlistentry>
</variablelist>
+<para>GHC can also read in External Core files as source; just give the <literal>.hcr</literal> file on
+the command line, instead of the <literal>.hs</literal> or <literal>.lhs</literal> Haskell source.
+A current infelicity is that you need to give teh <literal>-fglasgow-exts</literal> flag too, because
+ordinary Haskell 98, when translated to External Core, uses things like rank-2 types.</para>
</sect1>
&debug;
projects / ghc-hetmet.git / blobdiff