--- /dev/null
+<?xml version="1.0" encoding="iso-8859-1"?>
+<chapter id="sec-installing-bin-distrib">
+ <title>Installing GHC</title>
+<indexterm><primary>binary installations</primary></indexterm>
+<indexterm><primary>installation, of binaries</primary></indexterm>
+
+<para>
+Installing from binary distributions is easiest, and recommended!
+(Why binaries? Because GHC is a Haskell compiler written in Haskell,
+so you've got to bootstrap it somehow. We provide machine-generated
+C-files-from-Haskell for this purpose, but it's really quite a pain to
+use them. If you must build GHC from its sources, using a
+binary-distributed GHC to do so is a sensible way to proceed. For the
+other <literal>fptools</literal> programs, many are written in
+Haskell, so binary distributions allow you to install them without
+having a Haskell compiler.)
+</para>
+
+<para>This guide is in several parts:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para> Installing on Unix-a-likes (<xref
+ linkend="sec-unix-a-likes"/>). </para>
+ </listitem>
+ <listitem>
+ <para> Installing on Windows (<xref
+ linkend="sec-install-windows"/>). </para>
+ </listitem>
+ <listitem>
+ <para> The layout of installed files (<xref
+ linkend="sec-install-files"/>). You don't need to know this to
+ install GHC, but it's useful if you are changing the
+ implementation.</para>
+ </listitem>
+ </itemizedlist>
+
+ <sect1 id="sec-unix-a-likes"><title>Installing on Unix-a-likes</title>
+
+ <sect2>
+ <title>When a platform-specific package is available</title>
+
+ <para>For certain platforms, we provide GHC binaries packaged
+ using the native package format for the platform. This is
+ likely to be by far the best way to install GHC for your
+ platform if one of these packages is available, since
+ dependencies will automatically be handled and the package
+ system normally provides a way to uninstall the package at a
+ later date.</para>
+
+ <para>We generally provide the following packages:</para>
+
+ <variablelist>
+ <varlistentry>
+ <term>RedHat or SuSE Linux/x86</term>
+ <listitem>
+ <para>RPM source & binary packages for RedHat and SuSE
+ Linux (x86 only) are available for most major
+ releases.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Debian Linux/x86</term>
+ <listitem>
+ <para>Debian packages for Linux (x86 only), also for most
+ major releases.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>FreeBSD/x86</term>
+ <listitem>
+ <para>On FreeBSD/x86, GHC can be installed using either
+ the ports tree (<literal>cd /usr/ports/lang/ghc && make
+ install</literal>) or from a pre-compiled package
+ available from your local FreeBSD mirror.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>Other platform-specific packages may be available, check
+ the GHC download page for details.</para>
+ </sect2>
+
+<sect2>
+<title>GHC binary distributions</title>
+
+<para>
+<indexterm><primary>bundles of binary stuff</primary></indexterm>
+</para>
+
+<para>
+Binary distributions come in “bundles,” one bundle per file called
+<literal><replaceable>bundle</replaceable>-<replaceable>platform</replaceable>.tar.gz</literal>. (See the building guide for the definition of a platform.) Suppose that you untar a binary-distribution bundle, thus:
+</para>
+
+<para>
+
+<screen>
+% cd /your/scratch/space
+% gunzip < ghc-x.xx-sun-sparc-solaris2.tar.gz | tar xvf -</screen>
+
+</para>
+
+<para>
+Then you should find a single directory,
+<literal>ghc-<replaceable>version</replaceable></literal>, with the
+following structure:
+</para>
+
+<para>
+<indexterm><primary>binary distribution, layout</primary></indexterm>
+<indexterm><primary>directory layout (binary distributions)</primary></indexterm>
+<variablelist>
+
+<varlistentry>
+<term><literal>Makefile.in</literal></term>
+<listitem>
+<para>
+the raw material from which the <literal>Makefile</literal>
+will be made (<xref linkend="sec-install"/>).
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>configure</literal></term>
+<listitem>
+<para>
+the configuration script (<xref linkend="sec-install"/>).
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>README</literal></term>
+<listitem>
+<para>
+Contains this file summary.
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>INSTALL</literal></term>
+<listitem>
+<para>
+Contains this description of how to install
+the bundle.
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>ANNOUNCE</literal></term>
+<listitem>
+<para>
+The announcement message for the bundle.
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>NEWS</literal></term>
+<listitem>
+<para>
+release notes for the bundle—a longer version
+of <literal>ANNOUNCE</literal>. For GHC, the release notes are contained in the User
+Guide and this file isn't present.
+</para>
+</listitem></varlistentry>
+<varlistentry>
+ <term><literal>bin/<replaceable>platform</replaceable></literal></term>
+<listitem>
+<para>
+contains platform-specific executable
+files to be invoked directly by the user. These are the files that
+must end up in your path.
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>lib/<replaceable>platform</replaceable>/</literal></term>
+<listitem>
+<para>
+contains platform-specific support
+files for the installation. Typically there is a subdirectory for
+each <literal>fptools</literal> project, whose name is the name of the project with its
+version number. For example, for GHC there would be a sub-directory
+<literal>ghc-x.xx</literal>/ where <literal>x.xx</literal> is the version number of GHC in the bundle.
+</para>
+
+<para>
+These sub-directories have the following general structure:
+</para>
+
+<para>
+<variablelist>
+
+<varlistentry>
+<term><literal>libHSstd.a</literal> etc:</term>
+<listitem>
+<para>
+supporting library archives.
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>ghc-iface.prl</literal> etc:</term>
+<listitem>
+<para>
+support scripts.
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>import/</literal></term>
+<listitem>
+<para>
+<indexterm><primary>Interface files</primary></indexterm> (<literal>.hi</literal>) for the prelude.
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>include/</literal></term>
+<listitem>
+<para>
+A few C <literal>#include</literal> files.
+</para>
+</listitem></varlistentry>
+</variablelist>
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>share/</literal></term>
+<listitem>
+<para>
+contains platform-independent support files
+for the installation. Again, there is a sub-directory for each
+<literal>fptools</literal> project.
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>html/</literal></term>
+<listitem>
+<para>
+contains HTML documentation files (one
+sub-directory per project).
+</para>
+</listitem></varlistentry>
+</variablelist>
+</para>
+
+<sect3 id="sec-install">
+<title>Installing</title>
+
+<para>
+OK, so let's assume that you have unpacked your chosen bundles. What
+next? Well, you will at least need to run the
+<literal>configure</literal><indexterm><primary>configure</primary></indexterm>
+script by changing directory into the top-level directory for the
+bundle and typing <literal>./configure</literal>. That should convert
+<literal>Makefile.in</literal> to <literal>Makefile</literal>.
+</para>
+
+<para>
+<indexterm><primary>installing in-place</primary></indexterm>
+<indexterm><primary>in-place installation</primary></indexterm>
+You can now either start using the tools <emphasis>in-situ</emphasis> without going
+through any installation process, just type <literal>make in-place</literal> to set the
+tools up for this. You'll also want to add the path which <literal>make</literal> will
+now echo to your <literal>PATH</literal> environment variable. This option is useful if
+you simply want to try out the package and/or you don't have the
+necessary privileges (or inclination) to properly install the tools
+locally. Note that if you do decide to install the package `properly'
+at a later date, you have to go through the installation steps that
+follow.
+</para>
+
+<para>
+To install a package, you'll have to do the following:
+</para>
+
+<para>
+
+<orderedlist>
+<listitem>
+
+<para>
+ Edit the <literal>Makefile</literal> and check the settings of the following variables:
+
+<indexterm><primary>directories, installation</primary></indexterm>
+<indexterm><primary>installation directories</primary></indexterm>
+
+<variablelist>
+
+<varlistentry>
+<term><literal>platform</literal></term>
+<listitem>
+<para>
+the platform you are going to install for.
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>bindir</literal></term>
+<listitem>
+<para>
+the directory in which to install user-invokable
+binaries.
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>libdir</literal></term>
+<listitem>
+<para>
+the directory in which to install
+platform-dependent support files.
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>datadir</literal></term>
+<listitem>
+<para>
+the directory in which to install
+platform-independent support files.
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>infodir</literal></term>
+<listitem>
+<para>
+the directory in which to install Emacs info
+files.
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>htmldir</literal></term>
+<listitem>
+<para>
+the directory in which to install HTML
+documentation.
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>dvidir</literal></term>
+<listitem>
+<para>
+the directory in which to install DVI
+documentation.
+</para>
+</listitem></varlistentry>
+</variablelist>
+
+The values for these variables can be set through invocation of the
+<command>configure</command><indexterm><primary>configure</primary></indexterm>
+script that comes with the distribution, but doing an optical diff to
+see if the values match your expectations is always a Good Idea.
+</para>
+
+<para>
+<emphasis>Instead of running <command>configure</command>, it is
+perfectly OK to copy <filename>Makefile.in</filename> to
+<filename>Makefile</filename> and set all these variables directly
+yourself. But do it right!</emphasis>
+</para>
+
+</listitem>
+<listitem>
+
+<para>
+Run <literal>make install</literal>. This <emphasis>
+should</emphasis> work with ordinary Unix
+<literal>make</literal>—no need for fancy stuff like GNU
+<literal>make</literal>.
+
+</para>
+</listitem>
+<listitem>
+
+<para>
+<literal>rehash</literal> (t?csh or zsh users), so your shell will see the new
+stuff in your bin directory.
+
+</para>
+</listitem>
+<listitem>
+
+<para>
+ Once done, test your “installation” as suggested in
+<xref linkend="sec-GHC-test"/>. Be sure to use a <literal>-v</literal>
+option, so you can see exactly what pathnames it's using.
+
+If things don't work as expected, check the list of known pitfalls in
+the building guide.
+</para>
+</listitem>
+
+</orderedlist>
+
+</para>
+
+<para>
+<indexterm><primary>link, installed as ghc</primary></indexterm>
+When installing the user-invokable binaries, this installation
+procedure will install GHC as <literal>ghc-x.xx</literal> where <literal>x.xx</literal> is the version
+number of GHC. It will also make a link (in the binary installation
+directory) from <literal>ghc</literal> to <literal>ghc-x.xx</literal>. If you install multiple versions
+of GHC then the last one “wins”, and “<literal>ghc</literal>” will invoke the last
+one installed. You can change this manually if you want. But
+regardless, <literal>ghc-x.xx</literal> should always invoke GHC version <literal>x.xx</literal>.
+</para>
+
+</sect3>
+
+
+<sect3>
+<title>What bundles there are</title>
+
+<para>
+<indexterm><primary>bundles, binary</primary></indexterm> There are
+plenty of “non-basic” GHC bundles. The files for them are
+called
+<literal>ghc-x.xx-<replaceable>bundle</replaceable>-<replaceable>platform</replaceable>.tar.gz</literal>,
+where the <replaceable>platform</replaceable> is as above, and
+<replaceable>bundle</replaceable> is one of these:
+</para>
+
+<para>
+<variablelist>
+
+<varlistentry>
+<term><literal>prof</literal>:</term>
+<listitem>
+<para>
+Profiling with cost-centres. You probably want this.
+<indexterm><primary>profiling bundles</primary></indexterm>
+<indexterm><primary>bundles, profiling</primary></indexterm>
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>par</literal>:</term>
+<listitem>
+<para>
+Parallel Haskell features (sits on top of PVM).
+You'll want this if you're into that kind of thing.
+<indexterm><primary>parallel bundles</primary></indexterm>
+<indexterm><primary>bundles, parallel</primary></indexterm>
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>gran</literal>:</term>
+<listitem>
+<para>
+The “GranSim” parallel-Haskell simulator
+(hmm… mainly for implementors).
+<indexterm><primary>bundles, gransim</primary></indexterm>
+<indexterm><primary>gransim bundles</primary></indexterm>
+</para>
+</listitem></varlistentry>
+<varlistentry>
+<term><literal>ticky</literal>:</term>
+<listitem>
+<para>
+“Ticky-ticky” profiling; very detailed
+information about “what happened when I ran this program”—really
+for implementors.
+<indexterm><primary>bundles, ticky-ticky</primary></indexterm>
+<indexterm><primary>ticky-ticky bundles</primary></indexterm>
+</para>
+</listitem></varlistentry>
+</variablelist>
+</para>
+
+<para>
+One likely scenario is that you will grab <emphasis>two</emphasis>
+binary bundles—basic, and profiling. We don't usually make the
+rest, although you can build them yourself from a source distribution.
+</para>
+
+<para>The various GHC bundles are designed to be unpacked into the
+same directory; then installing as per the directions above will
+install the whole lot in one go. Note: you <emphasis>must</emphasis>
+at least have the basic GHC binary distribution bundle, these extra
+bundles won't install on their own.</para>
+
+</sect3>
+
+<sect3 id="sec-GHC-test">
+<title>Testing that GHC seems to be working
+</title>
+
+<para>
+<indexterm><primary>testing a new GHC</primary></indexterm>
+</para>
+
+<para>
+The way to do this is, of course, to compile and run <emphasis>this</emphasis> program
+(in a file <literal>Main.hs</literal>):
+</para>
+
+<para>
+
+<programlisting>
+main = putStr "Hello, world!\n"
+</programlisting>
+
+</para>
+
+<para>
+Compile the program, using the <literal>-v</literal> (verbose) flag to verify that
+libraries, etc., are being found properly:
+
+<screen>
+% ghc -v -o hello Main.hs</screen>
+
+</para>
+
+<para>
+Now run it:
+
+<screen>
+% ./hello
+Hello, world!</screen>
+
+</para>
+
+<para>
+Some simple-but-profitable tests are to compile and run the notorious
+<literal>nfib</literal><indexterm><primary>nfib</primary></indexterm> program, using different numeric types. Start with
+<literal>nfib :: Int -> Int</literal>, and then try <literal>Integer</literal>, <literal>Float</literal>, <literal>Double</literal>,
+<literal>Rational</literal> and perhaps the overloaded version. Code for this is
+distributed in <literal>ghc/misc/examples/nfib/</literal> in a source distribution.
+</para>
+
+<para>For more information on how to “drive” GHC, read
+on...</para>
+
+</sect3>
+
+</sect2>
+
+</sect1>
+
+
+<sect1 id="sec-install-windows"><title>Installing on Windows</title>
+
+<para>
+Getting the Glasgow Haskell Compiler (post 5.02) to run on Windows platforms is
+a snap: the Installshield does everything you need.
+</para>
+
+<sect2><title>Installing GHC on Windows</title>
+
+<para>
+To install GHC, use the following steps:
+</para>
+<itemizedlist>
+<listitem><para>Download the Installshield <filename>setup.exe</filename>
+from the GHC download page
+<ulink
+url="http://www.haskell.org/ghc">haskell.org</ulink>.
+</para></listitem>
+
+<listitem><para>Run <filename>setup.exe</filename>.
+On Windows, all of GHC's files are installed in a single directory.
+If you choose ``Custom'' from the list of install options, you will be given a
+choice about where this directory is; otherwise it will be installed
+in <filename>c:/ghc/<replaceable>ghc-version</replaceable></filename>.
+The executable binary for GHC will be installed in the <filename>bin/</filename> sub-directory
+of the installation directory you choose.
+</para>
+<para>(If you have already installed the same version of GHC, Installshield will offer to "modify",
+or "remove" GHC. Choose "remove"; then run <filename>setup.exe</filename> a
+second time. This time it should offer to install.)
+</para>
+<para>
+When installation is complete, you should find GHCi and the GHC documentation are
+available in your Start menu under "Start/Programs/Glasgow Haskell Compiler".
+</para>
+</listitem>
+
+<listitem><para>
+The final dialogue box from the install process reminds you where the GHC binary
+has been installed (usually <filename>c:/ghc/<replaceable>ghc-version</replaceable>/bin/</filename>.
+If you want to invoke GHC from a command line, add this
+to your PATH environment variable.
+</para></listitem>
+
+<listitem><para>
+GHC needs a directory in which to create, and later delete, temporary files.
+It uses the standard Windows procedure <literal>GetTempPath()</literal> to
+find a suitable directory. This procedure returns:
+<itemizedlist>
+<listitem><para>The path in environment variable TMP,
+if TMP is set.</para></listitem>
+<listitem><para>Otherwise, the path in environment variable TEMP,
+if TEMP is set.</para></listitem>
+<listitem><para>Otherwise, there is a per-user default which varies
+between versions of Windows. On NT and XP-ish versions, it might
+be:
+<filename>c:\Documents and Settings\<username>\Local Settings\Temp</filename>
+</para></listitem>
+</itemizedlist>
+The main point is that if you don't do anything GHC will work fine;
+but if you want to control where the directory is, you can do so by
+setting TMP or TEMP.
+</para></listitem>
+
+<listitem>
+<para>
+To test the fruits of your labour, try now to compile a simple
+Haskell program:
+</para>
+
+<screen>
+bash$ cat main.hs
+module Main(main) where
+
+main = putStrLn "Hello, world!"
+bash$ ghc -o main main.hs
+..
+bash$ ./main
+Hello, world!
+bash$ </screen>
+</listitem>
+</itemizedlist>
+
+<para>
+You do <emphasis>not</emphasis> need the Cygwin toolchain, or anything
+else, to install and run GHC.
+</para>
+<para>
+An installation of GHC requires about 140M of disk space.
+To run GHC comfortably, your machine should have at least
+64M of memory.
+</para>
+</sect2>
+
+<sect2><title>Moving GHC around</title>
+<para>
+At the moment, GHC installs in a fixed place (<filename>c:/ghc/ghc-x.yy</filename>,
+but once it is installed, you can freely move the entire GHC tree just by copying
+the <filename>ghc-x.yy</filename> directory. (You may need to fix up
+the links in "Start/Programs/Glasgow Haskell Compiler" if you do this.)
+</para>
+<para>
+It is OK to put GHC tree in a directory whose path involves spaces. However,
+don't do this if you use want to use GHC with the Cygwin tools,
+because Cygwin can get confused when this happens.
+We havn't quite got to the bottom of this, but so far as we know it's not
+a problem with GHC itself. Nevertheless, just to keep life simple we usually
+put GHC in a place with a space-free path.
+</para>
+</sect2>
+
+<sect2 id="winfaq">
+<title>Installing ghc-win32 FAQ</title>
+
+ <variablelist>
+ <varlistentry>
+ <term>I'm having trouble with symlinks.</term>
+ <listitem>
+ <para>Symlinks only work under Cygwin (<xref linkend="sec-install" />), so binaries not linked to the Cygwin
+ DLL, in particular those built for Mingwin, will not work with
+ symlinks.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>I'm getting “permission denied” messages from the
+ <command>rm</command> or <command>mv</command>.</term>
+ <listitem>
+ <para>This can have various causes: trying to rename a directory
+ when an Explorer window is open on it tends to fail. Closing the
+ window generally cures the problem, but sometimes its cause is
+ more mysterious, and logging off and back on or rebooting may be
+ the quickest cure.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+<!-- doesn't add much value any longer; leave out [sof 7/2002].
+<para>
+Further information on using GHC under Windows can be found in <ulink
+url="http://www.dcs.gla.ac.uk/~sof/ghc-win32.html">Sigbjørn Finne's
+pages</ulink>. Note: ignore the installation instructions, which are rather
+out of date; the <emphasis>Miscellaneous</emphasis> section at the bottom of
+the page is of most interest, covering topics beyond the scope of this
+manual.
+</para>
+-->
+</sect2>
+
+</sect1>
+
+
+<sect1 id="sec-install-files"><title>The layout of installed files</title>
+
+<para>
+This section describes what files get installed where. You don't need to know it
+if you are simply installing GHC, but it is vital information if you are changing
+the implementation.
+</para>
+<para> GHC is installed in two directory trees:</para>
+<variablelist>
+<varlistentry>
+<term>Library directory,</term>
+<listitem> <para> known as <filename>$(libdir)</filename>, holds all the
+support files needed to run GHC. On Unix, this
+directory is usually something like <filename>/usr/lib/ghc/ghc-5.02</filename>. </para>
+</listitem>
+</varlistentry>
+<varlistentry>
+<term>Binary directory</term>
+<listitem> <para> known as <filename>$(bindir)</filename>, holds executables that
+the user is expected to invoke.
+Notably, it contains
+<filename>ghc</filename> and <filename>ghci</filename>. On Unix, this directory
+can be anywhere, but is typically something like <filename>/usr/local/bin</filename>. On Windows,
+however, this directory <emphasis>must be</emphasis> <filename>$(libdir)/bin</filename>.
+</para>
+</listitem>
+</varlistentry>
+</variablelist>
+
+<para>
+When GHC runs, it must know where its library directory is.
+It finds this out in one of two ways:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+<filename>$(libdir)</filename> is passed to GHC using the <option>-B</option> flag.
+On Unix (but not Windows), the installed <filename>ghc</filename> is just a one-line
+shell script that invokes the real GHC, passing a suitable <option>-B</option> flag.
+[All the user-supplied flags
+follow, and a later <option>-B</option> flag overrides an earlier one, so a user-supplied
+one wins.]
+</para>
+</listitem>
+<listitem>
+<para> On Windows (but not Unix), if no <option>-B</option> flag is given, GHC uses a system
+call to find the directory in which the running GHC executable lives, and derives
+<filename>$(libdir)</filename> from that. [Unix lacks such a system call.]
+That is why <filename>$(bindir)</filename> must be <filename>$(libdir)/bin</filename>.
+</para>
+</listitem>
+</itemizedlist>
+
+<sect2> <title>The binary directory</title>
+
+<para>The binary directory, <filename>$(bindir)</filename> contains user-visible
+executables, notably <filename>ghc</filename> and <filename>ghci</filename>.
+You should add it to your <literal>$PATH</literal>
+</para>
+
+<para>On Unix, the user-invokable <filename>ghc</filename> invokes <filename>$(libdir)/ghc-<replaceable>version</replaceable></filename>,
+passing a suitable <option>-B</option> flag to tell <filename>ghc-<replaceable>version</replaceable></filename> where
+<filename>$(libdir)</filename> is.
+Similarly <filename>ghci</filename>, except the extra flag <literal>--interactive</literal> is passed.
+</para>
+
+<para>On Win32, the user-invokable <filename>ghc</filename> binary
+is the Real Thing (no intervening
+shell scripts or <filename>.bat</filename> files).
+Reason: we sometimes invoke GHC with very long command lines,
+and <filename>cmd.exe</filename> (which executes <filename>.bat</filename> files)
+truncates them. Similarly <filename>ghci</filename> is a C wrapper program that invokes <filename>ghc --interactive</filename>
+(passing on all other arguments), not a <filename>.bat</filename> file.
+</para>
+
+
+</sect2>
+
+<sect2> <title>The library directory</title>
+
+<para>The layout of the library directory, <filename>$(libdir)</filename> is almost identical on
+Windows and Unix, as follows. Differences between Windows and Unix
+are noted thus <literal>[Win32 only]</literal> and are commented below.</para>
+
+<programlisting>
+ $(libdir)/
+ package.conf GHC package configuration
+ ghc-usage.txt Message displayed by ghc ––help
+
+ bin/ [Win32 only] User-visible binaries
+ ghc.exe
+ ghci.exe
+
+ unlit Remove literate markup
+
+ touchy.exe [Win32 only]
+ perl.exe [Win32 only]
+ gcc.exe [Win32 only]
+
+ ghc-x.xx GHC executable [Unix only]
+
+ ghc-split Asm code splitter
+ ghc-asm Asm code mangler
+
+ gcc-lib/ [Win32 only] Support files for gcc
+ specs gcc configuration
+
+ cpp0.exe gcc support binaries
+ as.exe
+ ld.exe
+
+ crt0.o Standard
+ ..etc.. binaries
+
+ libmingw32.a Standard
+ ..etc.. libraries
+
+ *.h Include files
+
+ imports/ GHC interface files
+ std/*.hi 'std' library
+ lang/*.hi 'lang' library
+ ..etc..
+
+ include/ C header files
+ StgMacros.h GHC-specific
+ ..etc... header files
+
+ mingw/*.h [Win32 only] Mingwin header files
+
+ libHSrts.a GHC library archives
+ libHSstd.a
+ libHSlang.a
+ ..etc..
+
+ HSstd1.o GHC library linkables
+ HSstd2.o (used by ghci, which does
+ HSlang.o not grok .a files yet)
+</programlisting>
+
+<para>Note that:
+<itemizedlist>
+
+ <listitem>
+ <para><filename>$(libdir)</filename> also contains support
+ binaries. These are <emphasis>not</emphasis> expected to be
+ on the user's <filename>PATH</filename>, but and are invoked
+ directly by GHC. In the Makefile system, this directory is
+ also called <filename>$(libexecdir)</filename>, but
+ <emphasis>you are not free to change it</emphasis>. It must
+ be the same as <filename>$(libdir)</filename>.</para>
+ </listitem>
+
+<listitem>
+<para>We distribute <filename>gcc</filename> with the Win32 distribution of GHC, so that users
+don't need to install <filename>gcc</filename>, nor need to care about which version it is.
+All <filename>gcc</filename>'s support files are kept in <filename>$(libdir)/gcc-lib/</filename>.
+</para>
+</listitem>
+
+<listitem>
+<para>Similarly, we distribute <filename>perl</filename> and a <filename>touch</filename>
+replacement (<filename>touchy.exe</filename>)
+with the Win32 distribution of GHC. </para>
+</listitem>
+
+ <listitem>
+ <para>The support programs <filename>ghc-split</filename>
+ and <filename>ghc-asm</filename> are Perl scripts. The
+ first line says <literal>#!/bin/perl</literal>; on Unix, the
+ script is indeed invoked as a shell script, which invokes
+ Perl; on Windows, GHC invokes
+ <filename>$(libdir)/perl.exe</filename> directly, which
+ treats the <literal>#!/bin/perl</literal> as a comment.
+ Reason: on Windows we want to invoke the Perl distributed
+ with GHC, rather than assume some installed one. </para>
+ </listitem>
+</itemizedlist>
+</para>
+
+</sect2>
+
+</sect1>
+
+</chapter>
+
+<!-- Emacs stuff:
+ ;;; Local Variables: ***
+ ;;; mode: xml ***
+ ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter") ***
+ ;;; End: ***
+ -->
projects / ghc-hetmet.git / blobdiff