from an existing GHC installation, using the supplied
<literal>ghc-pkg</literal><indexterm><primary><literal>ghc-pkg</literal></primary>
</indexterm> tool, described in <xref
- linkend="package-management">.</para>
+ linkend="package-management"/>.</para>
<sect2 id="using-packages">
<title>Using a package</title>
<indexterm><primary>packages</primary>
<secondary>using</secondary></indexterm>
- <para>Some packages are automatically available: you don't need
+ <para>Some packages, called <emphasis>auto packages</emphasis>,
+ are automatically available: you don't need
to specify any extra flags to use them (except in certain
circumstances; see below). All the packages which contain
hierarchical libraries fall into this category.</para>
be imported in your Haskell source, however). It also
causes the relevant libraries to be linked when linking is
being done.</para>
+ <para>Some packages depend on other packages, for example the
+ <literal>text</literal> package makes use of some of the modules
+ in the <literal>lang</literal> package. The package system
+ takes care of all these dependencies, so that when you say
+ <literal>-package text</literal> on the command line, you
+ automatically get <literal>-package lang</literal> too.</para>
</listitem>
</varlistentry>
</variablelist>
<para>There's one case where you need to use the
<option>-package</option> option even for auto packages: when
- linking a program in batch mode<footnote><para>This is because
+ linking a program in batch mode mode (<xref linkend="options-order"/>)
+ <footnote><para>This is because
GHC can't figure out from the object files which packages are
required; in <option>––make</option> mode and in
GHCi the compiler has more information available to figure out
in the future.</para></footnote>. For example, to link a
program consisting of objects <filename>Foo.o</filename> and
<filename>Main.o</filename>, where we made use of the
- <literal>network</literal> package:</para>
+ <literal>network</literal> package, we need to give GHC the <literal>-package</literal> flag thus:
<screen>$ ghc -o myprog Foo.o Main.o -package network</screen>
- <para>Some packages depend on other packages, for example the
- <literal>text</literal> package makes use of some of the modules
- in the <literal>lang</literal> package. The package system
- takes care of all these dependencies, so that when you say
- <literal>-package text</literal> on the command line, you
- automatically get <literal>-package lang</literal> too.</para>
+ The same flag is necessary even if we compiled the modules from source, because GHC still
+ reckons it's in batch mode:
+<screen>$ ghc -o myprog Foo.hs Main.hs -package network</screen>
+In <literal>--make</literal> and <literal>--interactive</literal> modes (<xref linkend="modes"/>), however, GHC figures out
+the auto packages required for linking without further assistance.
+</para>
+
</sect2>
+
<sect2 id="using-local-packages">
<title>Maintaining a local set of packages</title>
<quote><literal>[]</literal></quote> in it. Packages can be
added to the new configuration file using the
<literal>ghc-pkg</literal> tool, described in <xref
- linkend="package-management">.</para>
+ linkend="package-management"/>.</para>
</sect2>
<sect2 id="building-packages">
make an inter-DLL call rather than an intra-DLL call
(inter-DLL calls require an extra
indirection). <emphasis>Building packages as DLLs doesn't
- work at the moment; see <XRef LinkEnd="win32-dlls-create">
+ work at the moment; see <xref linkend="win32-dlls-create"/>
for the gory details.</emphasis>
</para>
called <filename>HSfoo.o</filename> and load that. On some
systems, the <literal>ghc-pkg</literal> tool can
automatically build the GHCi version of each library, see
- <xref linkend="package-management">. To build these
+ <xref linkend="package-management"/>. To build these
libraries by hand from the <literal>.a</literal> archive, it
is possible to use GNU <command>ld</command> as
follows:</para>
</listitem>
<listitem>
+ <para>(replace
+ <literal>––--whole-archive</literal> with
+ <literal>–all_load</literal> on MacOS X)</para>
+
<para>GHC does not maintain detailed cross-package
dependency information. It does remember which modules in
other packages the current module depends on, but not which
</varlistentry>
<varlistentry>
+ <term><option>––list-local-packages</option></term>
+ <term><option>-L</option></term>
+ <indexterm><primary><option>––list-local-packages</option></primary></indexterm>
+ <listitem>
+ <para>Displays the list of packages installed in the
+ topmost configuration file only: that will be the
+ configuration file specified using <option>-f</option> on
+ the command line, or the system configuration file
+ otherwise.</para>
+
+ <para>This option may be more convenient than
+ <option>-l</option> when the output needs to be parsed by
+ a script.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><option>––remove-package <replaceable>foo</replaceable></option></term>
<term><option>-r <replaceable>foo</replaceable></option></term>
<indexterm><primary><option>––delete-package</option></primary>
<listitem>
<para>Set to <literal>True</literal> if the package should
be automatically available (see <xref
- linkend="using-packages">). This is normally set to
+ linkend="using-packages"/>). This is normally set to
<literal>True</literal> for packages which contain
hierarchical libraries, because in that case there is no
danger of polluting the module namespace.</para>
database as follows:
</para>
<screen>
- $ installdir=/usr/local/lib ghc-pkg -a < mypkg.pkg
+ $ installdir=/usr/local/lib ghc-pkg -a < mypkg.pkg
</screen>
<para>