<varlistentry>
<term>Build GHC from intermediate C <Filename>.hc</Filename> files<indexterm><primary>hc files</primary></indexterm>:</term>
<listitem>
+ <para><emphasis>NOTE: GHC version 5.xx is significantly
+ harder to bootstrap from C than previous versions. We
+ recommend starting from version 4.08.2 if you need to
+ bootstrap in this way.</emphasis></para>
+
<para>You need a working GHC to use a source distribution.
What if you don't have a working GHC? Then you may be able
to bootstrap up from the intermediate C
</varlistentry>
<varlistentry>
- <term>i386-unknown-cygwin32:</term>
- <indexterm><primary>i386-unknown-cygwin32</primary></indexterm>
+ <term>i386-unknown-mingw32:</term>
+ <indexterm><primary>i386-unknown-mingw32</primary></indexterm>
<listitem>
- <para>Fully supported under Win9x/NT, including a native
- code generator. Requires the <Literal>cygwin32</Literal>
- compatibility library and a healthy collection of GNU
- tools (i.e., gcc, GNU ld, bash etc.).</para>
+ <para>Fully supported under Win9x, WinNT, Win2k, and
+ WinXP. Includes a native code generator. Building from
+ source requires a recent <Literal>cygwin32</Literal>
+ distribution to be installed.</para>
</listitem>
</varlistentry>
</Sect2>
-<Sect2 id="sec-ways">
-<Title>Way management
-
-<indexterm><primary>way management</primary></indexterm></Title>
-
-<para>
-We sometimes want to build essentially the same system in several
-different ``ways''. For example, we want to build GHC's <Literal>Prelude</Literal>
-libraries with and without profiling, with and without concurrency,
-and so on, so that there is an appropriately-built library archive to
-link with when the user compiles his program. It would be possible to
-have a completely separate build tree for each such ``way'', but it
-would be horribly bureaucratic, especially since often only parts of
-the build tree need to be constructed in multiple ways.
-</para>
-
-<para>
-Instead, the <filename>target.mk</filename><indexterm><primary>target.mk</primary></indexterm> contains some clever magic to
-allow you to build several versions of a system; and to control
-locally how many versions are built and how they differ. This section
-explains the magic.
-</para>
-
-<para>
-The files for a particular way are distinguished by munging the
-suffix. The ``normal way'' is always built, and its files have the
-standard suffices <filename>.o</filename>, <filename>.hi</filename>, and so on. In addition, you can build
-one or more extra ways, each distinguished by a <Emphasis>way tag</Emphasis>. The
-object files and interface files for one of these extra ways are
-distinguished by their suffix. For example, way <Literal>mp</Literal> has files
-<filename>.mp_o</filename> and <filename>.mp_hi</filename>. Library archives have their way tag the other
-side of the dot, for boring reasons; thus, <filename>libHS_mp.a</filename>.
-</para>
-
-<para>
-A <Command>make</Command> variable called <constant>way</constant> holds the current way tag. <Emphasis><constant>way</constant>
-is only ever set on the command line of a recursive invocation of
-<Command>gmake</Command>.</Emphasis> It is never set inside a <filename>Makefile</filename>. So it is a global
-constant for any one invocation of <Command>gmake</Command>. Two other <Command>make</Command>
-variables, <constant>way_</constant> and <constant>_way</constant> are immediately derived from <constant>$(way)</constant> and
-never altered. If <constant>way</constant> is not set, then neither are <constant>way_</constant> and
-<constant>_way</constant>, and the invocation of <Command>make</Command> will build the ``normal way''.
-If <constant>way</constant> is set, then the other two variables are set in sympathy.
-For example, if <constant>$(way)</constant> is ``<Literal>mp</Literal>'', then <constant>way_</constant> is set to ``<Literal>mp_</Literal>''
-and <constant>_way</constant> is set to ``<Literal>_mp</Literal>''. These three variables are then used
-when constructing file names.
-</para>
-
-<para>
-So how does <Command>make</Command> ever get recursively invoked with <constant>way</constant> set? There
-are two ways in which this happens:
-</para>
-
-<para>
-
-<ItemizedList>
-<listitem>
+ <sect2 id="sec-ways">
+ <title>Way management</title>
+ <indexterm><primary>way management</primary></indexterm>
+
+ <para>We sometimes want to build essentially the same system in
+ several different ``ways''. For example, we want to build GHC's
+ <literal>Prelude</literal> libraries with and without profiling,
+ so that there is an appropriately-built library archive to link
+ with when the user compiles his program. It would be possible
+ to have a completely separate build tree for each such ``way'',
+ but it would be horribly bureaucratic, especially since often
+ only parts of the build tree need to be constructed in multiple
+ ways.</para>
+
+ <para>Instead, the
+ <filename>target.mk</filename><indexterm><primary>target.mk</primary></indexterm>
+ contains some clever magic to allow you to build several
+ versions of a system; and to control locally how many versions
+ are built and how they differ. This section explains the
+ magic.</para>
+
+ <para>The files for a particular way are distinguished by
+ munging the suffix. The <quote>normal way</quote> is always
+ built, and its files have the standard suffices
+ <filename>.o</filename>, <filename>.hi</filename>, and so on.
+ In addition, you can build one or more extra ways, each
+ distinguished by a <emphasis>way tag</emphasis>. The object
+ files and interface files for one of these extra ways are
+ distinguished by their suffix. For example, way
+ <literal>mp</literal> has files
+ <filename>.mp_o</filename> and
+ <filename>.mp_hi</filename>. Library archives have their
+ way tag the other side of the dot, for boring reasons; thus,
+ <filename>libHS_mp.a</filename>.</para>
+
+ <para>A <Command>make</Command> variable called
+ <constant>way</constant> holds the current way tag.
+ <emphasis><constant>way</constant> is only ever set on the
+ command line of <Command>gmake</Command></emphasis> (usually in
+ a recursive invocation of <command>gmake</command> by the
+ system). It is never set inside a
+ <filename>Makefile</filename>. So it is a global constant for
+ any one invocation of <Command>gmake</Command>. Two other
+ <Command>make</Command> variables,
+ <constant>way_</constant> and
+ <constant>_way</constant> are immediately derived from
+ <constant>$(way)</constant> and never altered. If
+ <constant>way</constant> is not set, then neither are
+ <constant>way_</constant> and
+ <constant>_way</constant>, and the invocation of
+ <Command>make</Command> will build the <quote>normal
+ way</quote>. If <constant>way</constant> is set, then the other
+ two variables are set in sympathy. For example, if
+ <constant>$(way)</constant> is ``<Literal>mp</Literal>'',
+ then <constant>way_</constant> is set to
+ ``<Literal>mp_</Literal>'' and
+ <constant>_way</constant> is set to
+ ``<Literal>_mp</Literal>''. These three variables are
+ then used when constructing file names.</para>
+
+ <para>So how does <Command>make</Command> ever get recursively
+ invoked with <constant>way</constant> set? There are two ways
+ in which this happens:</para>
-<para>
- For some (but not all) of the standard targets, when in a leaf
-sub-directory, <Command>make</Command> is recursively invoked for each way tag in
-<constant>$(WAYS)</constant>. You set <constant>WAYS</constant> to the list of way tags you want these
-targets built for. The mechanism here is very much like the recursive
-invocation of <Command>make</Command> in sub-directories (<Xref LinkEnd="sec-subdirs">).
-
-It is up to you to set <constant>WAYS</constant> in your <filename>Makefile</filename>; this is how you
-control what ways will get built.
-</para>
-</listitem>
-<listitem>
-
-<para>
- For a useful collection of
-targets (such as <filename>libHS_mp.a</filename>, <filename>Foo.mp_o</filename>) there is a rule which
-recursively invokes <Command>make</Command> to make the specified target, setting the
-<constant>way</constant> variable. So if you say <Command>gmake Foo.mp_o</Command> you should see a
-recursive invocation <Command>gmake Foo.mp_o way=mp</Command>, and <Emphasis>in this
-recursive invocation the pattern rule for compiling a Haskell file
-into a <filename>.o</filename> file will match</Emphasis>. The key pattern rules (in <filename>suffix.mk</filename>)
-look like this:
+ <itemizedlist>
+ <listitem>
+ <para>For some (but not all) of the standard targets, when
+ in a leaf sub-directory, <Command>make</Command> is
+ recursively invoked for each way tag in
+ <constant>$(WAYS)</constant>. You set
+ <constant>WAYS</constant> in the
+ <filename>Makefile</filename> to the list of way tags you
+ want these targets built for. The mechanism here is very
+ much like the recursive invocation of
+ <Command>make</Command> in sub-directories (<Xref
+ LinkEnd="sec-subdirs">). It is up to you to set
+ <constant>WAYS</constant> in your
+ <filename>Makefile</filename>; this is how you control what
+ ways will get built.</para>
+ </listitem>
+ <listitem>
+ <para>For a useful collection of targets (such as
+ <filename>libHS_mp.a</filename>,
+ <filename>Foo.mp_o</filename>) there is a rule which
+ recursively invokes <Command>make</Command> to make the
+ specified target, setting the <constant>way</constant>
+ variable. So if you say <Command>gmake
+ Foo.mp_o</Command> you should see a recursive
+ invocation <Command>gmake Foo.mp_o way=mp</Command>,
+ and <Emphasis>in this recursive invocation the pattern rule
+ for compiling a Haskell file into a <filename>.o</filename>
+ file will match</Emphasis>. The key pattern rules (in
+ <filename>suffix.mk</filename>) look like this:
<ProgramListing>
%.$(way_)o : %.lhs
$(HC) $(HC_OPTS) $< -o $@
</ProgramListing>
+ Neat, eh?</para>
+ </listitem>
-Neat, eh?
-</para>
-</listitem>
+ <listitem>
+ <para>You can invoke <command>make</command> with a
+ particular <literal>way</literal> setting yourself, in order
+ to build files related to a particular
+ <literal>way</literal> in the current directory. eg.
-</ItemizedList>
+<screen>
+$ make way=p
+</screen>
-</para>
+ will build files for the profiling way only in the current
+ directory. </para>
+ </listitem>
+ </itemizedlist>
</Sect2>
<indexterm><primary>booting GHC from .hc files</primary></indexterm>
<indexterm><primary>porting GHC</primary></indexterm></Title>
+ <para><emphasis>NOTE: GHC version 5.xx is significantly harder to
+ bootstrap from C than previous versions. We recommend starting
+ from version 4.08.2 if you need to bootstrap in this
+ way.</emphasis></para>
+
<para>
This section is for people trying to get GHC going by using the supplied
intermediate C (<filename>.hc</filename>) files. This would probably be
</listitem>
<listitem>
-<para>GHC uses the <emphasis>mingwin</emphasis> C compiler to
-generate code, so you have to install that. Just pick up a mingwin bundle at
+<para>GHC uses the <emphasis>mingw</emphasis> C compiler to
+generate code, so you have to install that. Just pick up a mingw bundle at
<ulink url="http://www.mingw.org/">http://www.mingw.org/</ulink>.
We install it in <filename>c:/mingw</filename>.
</para>
<listitem>
<para>
-Install a version of GHC, and put it in your <constant>PATH</constant>.
-The InstallShield tells you the path when you install it.
+Install a version of GHC, and put it in your
+<constant>PATH</constant> (the installer tells you the path element
+you need to add upon completion.)
</para>
</listitem>
+<!--
<listitem>
<para>
Because of various hard-wired infelicities, you need to copy
-<Filename>bash.exe</Filename> (from GHC's <Filename>extra-bin</Filename>
-directory), and <Filename>perl.exe</Filename> and
-<Filename>cat.exe</Filename> (from GHC's <Filename>bin</Filename> directory)
-to <Filename>/bin</Filename> (discover where your Cygwin root directory is
-by typign <Command>mount</Command>).
+<Filename>bash.exe</Filename>, <Filename>perl.exe</Filename> and
+<Filename>cat.exe</Filename> (from Cygwin's <Filename>bin</Filename>
+directory), to <Filename>/bin</Filename> (discover where your Cygwin
+root directory is by typing <Command>mount</Command>). If
+<Command>/bin</Command> points to the Cygwin <Filename>bin</Filename>
+directory, there's no need to copy anything.
+</para>
+</listitem>
+
+<listitem>
+<para>
+By default, cygwin provides the command shell <filename>ash</filename>
+as <filename>sh.exe</filename>. It has a couple of 'issues', so
+in your <filename>/bin</filename> directory, make sure that <filename>
+bash.exe</filename> is also provided as <filename>sh.exe</filename>.
</para>
</listitem>
+
<listitem>
-<para> You should not need to install <command>ssh</command>
-and <command>cvs</command>: they come with Cygwin.</para>
+<para> Both <command>cvs</command> and <command>ssh</command>
+come with Cygwin, but make sure you select them when running
+the Cygwin installer.
</listitem>
<listitem>
</para>
</listitem>
- <listitem>
- <para>
- After <command>autoconf</command> run <command>./configure</command> in
- <filename>fptools/</filename> thus:
+<listitem>
+<para>
+You either need to add <filename>ghc</filename> to your
+<constant>PATH</constant> before you invoke
+<Command>configure</Command>, or use the <Command>configure</Command>
+option <option>--with-ghc=c:/ghc/ghc-some-version/bin/ghc</option>.
+
+</para>
+<para>
+The Windows installer for GHC tells you at the end what
+additions you need to make to your <constant>PATH</constant>.
+</para>
+</listitem>
+
+<listitem>
+ <para>
+ After <command>autoconf</command> run <command>./configure</command> in
+ <filename>fptools/</filename> thus:
+
<Screen>
./configure --host=i386-unknown-mingw32 --with-gcc=/mingw/bin/gcc
</Screen>
- Both these options are important!
- It's possible to get into trouble using the
- wrong C compiler!
- </para>
- </listitem>
-
+Both these options are important! It's possible to get into
+trouble using the wrong C compiler!
+</para>
+</listitem>
</ItemizedList>
-
</Sect2>
+
+<!--
<sect2>
<title>Building the Windows InstallShield® Installer</title>
</sect3>
</sect2>
+-->
</Sect1>
projects / ghc-hetmet.git / blobdiff