the parser specifications. If you don't want to alter the
parser then this saves you having to find and install
<command>happy</command>. You will still need a working
- version of GHC (preferably version 4.08+) on your machine in
+ version of GHC (version 5.x or later) on your machine in
order to compile (most of) the sources, however.</para>
</listitem>
</varlistentry>
remember is that most mistakes can be undone, but if there's
anything you're not sure about feel free to bug the local CVS
meister (namely Jeff Lewis
- <email>jlewis@galconn.com</email>). </para>
+ <email>jlewis@galois.com</email>). </para>
<sect2 id="cvs-access">
<title>Getting access to the CVS Repository</title>
<listitem>
<para>Set your <literal>$CVSROOT</literal> environment variable to
<literal>:pserver:anoncvs@glass.cse.ogi.edu:/cvs</literal></para>
+ <para>If you set <literal>$CVSROOT</literal> in a shell script, be sure not to
+ have any trailing spaces on that line, otherwise CVS will respond with
+ a perplexing message like
+ <programlisting>
+ /cvs : no such repository
+ </programlisting></para>
</listitem>
<listitem>
<para>Run the command</para>
<listitem>
<para>Send a message to to the CVS repository
administrator (currently Jeff Lewis
- <email>jeff@galconn.com</email>), containing:</para>
+ <email>jeff@galois.com</email>), containing:</para>
<itemizedlist>
<listitem>
<para>Your desired user-name.</para>
</varlistentry>
<varlistentry>
- <term>i386-unknown-netbsd (PCs running NetBSD and
- OpenBSD)</term>
+ <term>i386-unknown-netbsd (PCs running NetBSD)</term>
<indexterm><primary>i386-unknown-netbsd</primary></indexterm>
<listitem>
<para>Will require some minor porting effort, but should
</varlistentry>
<varlistentry>
+ <term>amd64-unknown-openbsd</term>
+ <indexterm><primary>amd64-unknown-linux</primary></indexterm>
+ <listitem>
+ <para>(This is the same as x86_64-unknown-openbsd). GHC
+ currently works unregisterised. A registerised port is in
+ progress.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term>mips-sgi-irix5</term>
<indexterm><primary>mips-sgi-irix[5-6]</primary></indexterm>
<listitem>
</varlistentry>
<varlistentry>
- <term>Autoconf</term>
- <indexterm><primary>pre-supposed: Autoconf</primary></indexterm>
- <indexterm><primary>Autoconf, pre-supposed</primary></indexterm>
+ <term>autoconf</term>
+ <indexterm><primary>pre-supposed: autoconf</primary></indexterm>
+ <indexterm><primary>autoconf, pre-supposed</primary></indexterm>
<listitem>
- <para>GNU Autoconf is needed if you intend to build from the
+ <para>GNU autoconf is needed if you intend to build from the
CVS sources, it is <emphasis>not</emphasis> needed if you
just intend to build a standard source distribution.</para>
- <para>Version 2.52 or later of autoconf is required.
- NB. vesrion 2.13 will no longer work, as of GHC version
+ <para>Version 2.52 or later of the autoconf package is required.
+ NB. version 2.13 will no longer work, as of GHC version
6.1.</para>
- <para>Autoconf builds the <command>configure</command>
- script from <filename>configure.ac</filename> and
- <filename>aclocal.m4</filename>. If you modify either of
- these files, you'll need <command>autoconf</command> to
- rebuild <filename>configure</filename>.</para>
+ <para><command>autoreconf</command> (from the autoconf package)
+ recursively builds <command>configure</command> scripts from
+ the corresponding <filename>configure.ac</filename> and
+ <filename>aclocal.m4</filename> files. If you modify one of
+ the latter files, you'll need <command>autoreconf</command> to
+ rebuild the corresponding <filename>configure</filename>.</para>
</listitem>
</varlistentry>
want a completely standard build, then the following should
work:</para>
-<screen>$ ./configure
+<screen>$ autoreconf
+$ ./configure
$ make
$ make install
</screen>
<para>Change directory to
<constant>$(FPTOOLS_TOP)</constant> and
- issue the command
- <command>autoconf</command><indexterm><primary>autoconf</primary></indexterm>
- (with no arguments). This GNU program converts
- <filename><constant>$(FPTOOLS_TOP)</constant>/configure.ac</filename>
+ issue the command</para>
+<ProgramListing>
+autoreconf
+</ProgramListing>
+ <indexterm><primary>autoreconf</primary></indexterm>
+ <para>(with no arguments). This GNU program (recursively) converts
+ <filename><constant>$(FPTOOLS_TOP)</constant>/configure.ac</filename> and
+ <filename><constant>$(FPTOOLS_TOP)</constant>/aclocal.m4</filename>
to a shell script called
<filename><constant>$(FPTOOLS_TOP)</constant>/configure</filename>.
+ If <command>autoreconf</command> bleats that it can't write the file <filename>configure</filename>,
+ then delete the latter and try again. Note that you must use <command>autoreconf</command>,
+ and not the old <command>autoconf</command>! If you erroneously use the latter, you'll get
+ a message like "No rule to make target 'mk/config.h.in'".
</para>
- <para>Some projects, including GHC, have their own
- configure script. If there's an
- <constant>$(FPTOOLS_TOP)/<project>/configure.ac</constant>,
- then you need to run <command>autoconf</command> in that
- directory too.</para>
-
- <para>Both these steps are completely
- platform-independent; they just mean that the
- human-written file (<filename>configure.ac</filename>) can
- be short, although the resulting shell script,
- <command>configure</command>, and
- <filename>mk/config.h.in</filename>, are long.</para>
+ <para>Some projects, including GHC, have their own configure script.
+ <command>autoreconf</command> takes care of that, too, so all you have
+ to do is calling <command>autoreconf</command> in the top-level directory
+ <constant>$(FPTOOLS_TOP)</constant>.</para>
+
+ <para>These steps are completely platform-independent; they just mean
+ that the human-written files (<filename>configure.ac</filename> and
+ <filename>aclocal.m4</filename>) can be short, although the resulting
+ files (the <command>configure</command> shell scripts and the C header
+ template <filename>mk/config.h.in</filename>) are long.</para>
</listitem>
</varlistentry>
</listitem>
</varlistentry>
</variablelist>
-
- <para><command>configure</command> caches the results of
- its run in <filename>config.cache</filename>. Quite often
- you don't want that; you're running
- <command>configure</command> a second time because
- something has changed. In that case, simply delete
- <filename>config.cache</filename>.</para>
</listitem>
</varlistentry>
<para>Prepare for system configuration:</para>
<programlisting>
-$ autoconf
+$ autoreconf
</programlisting>
<para>(You can skip this step if you are starting from a
source distribution, and you already have
<filename>configure</filename> and
<filename>mk/config.h.in</filename>.)</para>
-
- <para>Some projects, including GHC itself, have their own
- configure scripts, so it is necessary to run autoconf again
- in the appropriate subdirectories. eg:</para>
-
-<programlisting>
-$ (cd ghc; autoconf)
-</programlisting>
</listitem>
<listitem>
</sect1>
-<Sect1 id="winbuild"><Title>Notes for building under Windows</Title>
-
+<Sect1 id="platforms"><Title>Platforms, scripts, and file names</Title>
<para>
-This section summarises how to get the utilities you need on your
-Win95/98/NT/2000 machine to use CVS and build GHC. Similar notes for
-installing and running GHC may be found in the user guide. In general,
-Win95/Win98 behave the same, and WinNT/Win2k behave the same.
-You should read the GHC installation guide sections on Windows (in the user
-guide) before continuing to read these notes.
+GHC is designed both to be built, and to run, on both Unix and Windows. This flexibility
+gives rise to a good deal of brain-bending detail, which we have tried to collect in this chapter.
</para>
+<sect2 id="cygwin-and-mingw"><Title>Windows platforms: Cygwin, MSYS, and MinGW</Title>
-<sect2 id="cygwin-and-mingw"><Title>Cygwin and MinGW</Title>
-
-<para> The Windows situation for building GHC is rather confusing. This section
+<para> The build system is built around Unix-y makefiles. Because it's not native,
+the Windows situation for building GHC is particularly confusing. This section
tries to clarify, and to establish terminology.</para>
-<sect3 id="ghc-mingw"><title>GHC-mingw</title>
+<sect3 id="ghc-mingw"><title>MinGW</title>
<para> <ulink url="http://www.mingw.org">MinGW (Minimalist GNU for Windows)</ulink>
is a collection of header
Utilities (Binutils), GNU debugger (Gdb), GNU make, and a assorted
other utilities.
</para>
-<para>The GHC that we distribute includes, inside the distribution itself, the MinGW <command>gcc</command>,
-<command>as</command>, <command>ld</command>, and a bunch of input/output libraries.
-GHC compiles Haskell to C (or to
-assembly code), and then invokes these MinGW tools to generate an executable binary.
-The resulting binaries can run on any Win32 system.
+
+<para> The down-side of MinGW is that the MinGW libraries do not support anything like the full
+Posix interface.
</para>
-<para> We will call a GHC that targets MinGW in this way <emphasis>GHC-mingw</emphasis>.</para>
+</sect3>
-<para> The down-side of GHC-mingw is that the MinGW libraries do not support anything like the full
-Posix interface. So programs compiled with GHC-mingw cannot import the (Haskell) Posix
+<sect3 id="ghc-cygwin"><title>Cygwin and MSYS</title>
+
+<para>You can't use the MinGW to <emphasis>build</emphasis> GHC, because MinGW doesn't have a shell,
+or the standard Unix commands such as <command>mv</command>, <command>rm</command>,
+<command>ls</command>, nor build-system stuff such as <command>make</command> and <command>cvs</command>.
+For that, there are two choices: <ulink url="http://www.cygwin.com">Cygwin</ulink>
+and <ulink url="http://www.mingw.org/msys.shtml">MSYS</ulink>:
+
+<itemizedlist>
+<listitem><para>
+Cygwin comes with compilation tools (<command>gcc</command>, <command>ld</command> and so on), which
+compile code that has access to all of Posix. The price is that the executables must be
+dynamically linked with the Cygwin DLL, so that <emphasis>you cannot run a Cywin-compiled program on a machine
+that doesn't have Cygwin</emphasis>. Worse, Cygwin is a moving target. The name of the main DLL, <literal>cygwin1.dll</literal>
+does not change, but the implementation certainly does. Even the interfaces to functions
+it exports seem to change occasionally. </para>
+</listitem>
+
+<listitem><para>
+MSYS is a fork of the Cygwin tree, so they
+are fundamentally similar. However, MSYS is by design much smaller and simpler. Access to the file system goes
+through fewer layers, so MSYS is quite a bit faster too.
+</para>
+
+<para>Furthermore, MSYS provides no compilation tools; it relies instead on the MinGW tools. These
+compile binaries that run with no DLL support, on any Win32 system.
+However, MSYS does come with all the make-system tools, such as <command>make</command>, <command>autoconf</command>,
+<command>cvs</command>, <command>ssh</command> etc. To get these, you have to download the
+MsysDTK (Developer Tool Kit) package, as well as the base MSYS package.
+</para>
+<para>MSYS does have a DLL, but it's only used by MSYS commands (<command>sh</command>, <command>rm</command>,
+<command>ssh</command> and so on),
+not by programs compiled under MSYS.
+</para></listitem>
+
+</itemizedlist>
+
+</para>
+</sect3>
+
+<sect3><title>Targeting MinGW</title>
+
+<para>We want GHC to compile programs that work on any Win32 system. Hence:
+<itemizedlist>
+<listitem><para>
+GHC does invoke a C compiler, assembler, linker and so on, but we ensure that it only
+invokes the MinGW tools, not the Cygwin ones. That means that the programs GHC compiles
+will work on any system, but it also means that the programs GHC compiles do not have access
+to all of Posix. In particular, they cannot import the (Haskell) Posix
library; they have to do
-their input output using standard Haskell I/O libraries, or native Win32 bindings.
+their input output using standard Haskell I/O libraries, or native Win32 bindings.</para>
+<para> We will call a GHC that targets MinGW in this way <emphasis>GHC-mingw</emphasis>.</para>
+</listitem>
+
+<listitem><para>
+To make the GHC distribution self-contained, the GHC distribution includes the MinGW <command>gcc</command>,
+<command>as</command>, <command>ld</command>, and a bunch of input/output libraries.
+</para></listitem>
+</itemizedlist>
+So <emphasis>GHC targets MinGW</emphasis>, not Cygwin.
+It is in principle possible to build a version of GHC, <emphasis>GHC-cygwin</emphasis>,
+that targets Cygwin instead. The up-side of GHC-cygwin is
+that Haskell programs compiled by GHC-cygwin can import the (Haskell) Posix library.
+<emphasis>We do not support GHC-cygwin, however; it is beyond our resources.</emphasis>
+</para>
+
+<para>While GHC <emphasis>targets</emphasis> MinGW, that says nothing about
+how GHC is <emphasis>built</emphasis>. We use both MSYS and Cygwin as build environments for
+GHC; both work fine, though MSYS is rather lighter weight.</para>
+
+<para>In your build tree, you build a compiler called <Command>ghc-inplace</Command>. It
+uses the <Command>gcc</Command> that you specify using the
+<option>--with-gcc</option> flag when you run
+<Command>configure</Command> (see below).
+The makefiles are careful to use <Command>ghc-inplace</Command> (not <Command>gcc</Command>)
+to compile any C files, so that it will in turn invoke the correct <Command>gcc</Command> rather that
+whatever one happens to be in your path. However, the makefiles do use whatever <Command>ld</Command>
+and <Command>ar</Command> happen to be in your path. This is a bit naughty, but (a) they are only
+used to glom together .o files into a bigger .o file, or a .a file,
+so they don't ever get libraries (which would be bogus; they might be the wrong libraries), and (b)
+Cygwin and MinGW use the same .o file format. So its ok.
</para>
</sect3>
-<sect3 id="ghc-cygwin"><title>GHC-cygwin</title>
+<sect3><title> File names </title>
-<para>There <emphasis>is</emphasis> a way to get the full Posix interface, which is to use Cygwin.
-<ulink url="http://www.cygwin.com">Cygwin</ulink> is a complete Unix simulation that runs on Win32.
-Cygwin comes with a shell, and all the usual Unix commands: <command>mv</command>, <command>rm</command>,
-<command>ls</command>, plus of course <command>gcc</command>, <command>ld</command> and so on.
-A C program compiled with the Cygwin <command>gcc</command> certainly can use all of Posix.
+<para>Cygwin, MSYS, and the underlying Windows file system all understand file paths of form <literal>c:/tmp/foo</literal>.
+However:
+<itemizedlist>
+<listitem><para>
+MSYS programs understand <filename>/bin</filename>, <filename>/usr/bin</filename>, and map Windows's lettered drives as
+<filename>/c/tmp/foo</filename> etc. The exact mount table is given in the doc subdirectory of the MSYS distribution.
</para>
-<para>So why doesn't GHC use the Cygwin <command>gcc</command> and libraries? Because
-Cygwin comes with a DLL <emphasis>that must be linked with every runnable Cygwin-compiled program</emphasis>.
-A program compiled by the Cygwin tools cannot run at all unless Cygwin is installed.
-If GHC targeted Cygwin, users would have to install Cygwin just to run the Haskell programs
-that GHC compiled; and the Cygwin DLL would have to be in the DLL load path.
-Worse, Cygwin is a moving target. The name of the main DLL, <literal>cygwin1.dll</literal>
-does not change, but the implementation certainly does. Even the interfaces to functions
-it exports seem to change occasionally. So programs compiled by GHC might only run with
-particular versions of Cygwin. All of this seems very undesirable.
+<para> When it invokes a command, the MSYS shell sees whether the invoked binary lives in the MSYS <filename>/bin</filename>
+directory. If so, it just invokes it. If not, it assumes the program is no an MSYS program, and walks over the command-line
+arguments changing MSYS paths into native-compatible paths. It does this inside sub-arguments and inside quotes. For example,
+if you invoke
+<programlisting>
+ foogle -B/c/tmp/baz
+</programlisting>
+the MSYS shell will actually call <literal>foogle</literal> with argument <literal>-Bc:/tmp/baz</literal>.
+</para></listitem>
+
+<listitem><para>
+Cygwin programs have a more complicated mount table, and map the lettered drives as <filename>/cygdrive/c/tmp/foo</filename>.
</para>
-<para>
-Nevertheless, it is certainly possible to build a version of GHC that targets Cygwin;
-we will call that <emphasis>GHC-cygwin</emphasis>. The up-side of GHC-cygwin is
-that Haskell programs compiled by GHC-cygwin can import the (Haskell) Posix library.
+<para>The Cygwin shell does no argument processing when invoking non-Cygwin programs.
+</para></listitem>
+</itemizedlist>
</para>
</sect3>
</para>
</sect3>
-<sect3><title>Summary</title>
+</sect2>
+
+<sect2><title>Wrapper scripts</title>
+
+<para>
+Many programs, including GHC itself and hsc2hs, need to find associated binaries and libraries.
+For <emphasis>installed</emphasis> programs, the strategy depends on the platform. We'll use
+GHC itself as an example:
+<itemizedlist>
+ <listitem> <para>
+ On Unix, the command <command>ghc</command> is a shell script, generated by adding installation
+ paths to the front of the source file <filename>ghc.sh</filename>,
+ that invokes the real binary, passing "-B<emphasis>path</emphasis>" as an argument to tell <command>ghc</command>
+ where to find its supporting files.
+ </para> </listitem>
+
+ <listitem> <para>
+ On vanilla Windows, it turns out to be much harder to make reliable script to be run by the
+ native Windows shell <command>cmd</command> (e.g. limits on the length
+ of the command line). So instead we invoke the GHC binary directly, with no -B flag.
+ GHC uses the Windows <literal>getExecDir</literal> function to find where the executable is,
+ and from that figures out where the supporting files are.
+ </para> </listitem>
+</itemizedlist>
+(You can find the layout of GHC's supporting files in the
+ section "Layout of installed files" of Section 2 of the GHC user guide.)
+</para>
+<para>
+Things work differently for <emphasis>in-place</emphasis> execution, where you want to
+execute a program that has just been built in a build tree. The difference is that the
+layout of the supporting files is different.
+In this case, whether on Windows or Unix, we always use a shell script. This works OK
+on Windows because the script is executed by MSYS or Cygwin, which don't have the
+shortcomings of the native Windows <command>cmd</command> shell.
+</para>
+
+</sect2>
-<para>Notice that "GHC-mingw" means "GHC that <emphasis>targets</emphasis> MinGW". It says nothing about
-how that GHC was <emphasis>built</emphasis>. It is entirely possible to have a GHC-mingw that was built
-by compiling GHC's Haskell sources with a GHC-cygwin, or vice versa.</para>
+</sect1>
+
+<Sect1 id="winbuild"><Title>Instructions for building under Windows</Title>
+
+<para>
+This section gives detailed instructions for how to build
+GHC from source on your Windows machine. Similar instructions for
+installing and running GHC may be found in the user guide. In general,
+Win95/Win98 behave the same, and WinNT/Win2k behave the same.
+</para>
+<para>
+Make sure you read the preceding section on platforms (<xref linkend="platforms">)
+before reading section.
+You don't need Cygwin or MSYS to <emphasis>use</emphasis> GHC,
+but you do need one or the other to <emphasis>build</emphasis> GHC.</para>
-<para>We distribute only a GHC-mingw built by a GHC-mingw; supporting
-GHC-cygwin too is beyond our resources. The GHC we distribute
-therefore does not require Cygwin to run, nor do the programs it
-compiles require Cygwin.</para>
-<para>The instructions that follow describe how to build GHC-mingw. It is
-possible to build GHC-cygwin, but it's not a supported route, and the build system might
-be flaky.</para>
+<Sect2 id=msys-install><Title>Installing and configuring MSYS</Title>
-<para>In your build tree, you build a compiler called <Command>ghc-inplace</Command>. It
-uses the <Command>gcc</Command> that you specify using the
-<option>--with-gcc</option> flag when you run
-<Command>configure</Command> (see below).
-The makefiles are careful to use <Command>ghc-inplace</Command> (not <Command>gcc</Command>)
-to compile any C files, so that it will in turn invoke the right <Command>gcc</Command> rather that
-whatever one happens to be in your path. However, the makefiles do use whatever <Command>ld</Command>
-and <Command>ar</Command> happen to be in your path. This is a bit naughty, but (a) they are only
-used to glom together .o files into a bigger .o file, or a .a file,
-so they don't ever get libraries (which would be bogus; they might be the wrong libraries), and (b)
-Cygwin and Mingw use the same .o file format. So its ok.
+<para>
+MSYS is a lightweight alternative to Cygwin.
+You don't need MSYS to <emphasis>use</emphasis> GHC,
+but you do need it or Cygwin to <emphasis>build</emphasis> GHC.
+Here's how to install MSYS.
+<itemizedlist>
+<listitem><para>
+Go to <ulink url="http://www.mingw.org/download.shtml">http://www.mingw.org/download.shtml</ulink> and
+download the following (of course, the version numbers will differ):
+<itemizedlist>
+ <listitem><para>The main MSYS package (binary is sufficient): <literal>MSYS-1.0.9.exe</literal>
+ </para></listitem>
+ <listitem><para>The MSYS developer's toolkit (binary is sufficient): <literal>msysDTK-1.0.1.exe</literal>.
+ This provides <command>make</command>, <command>autoconf</command>,
+ <command>ssh</command>, <command>cvs</command> and probably more besides.
+ </para></listitem>
+</itemizedlist>
+Run both executables (in the order given above) to install them. I put them in <literal>c:/msys</literal>
+</para></listitem>
+
+<listitem><para>
+Set the following environment variables
+<itemizedlist>
+ <listitem><para><literal>PATH</literal>: add <literal>c:/msys/1.0/bin</literal> to your path. (Of course, the version number may differ.)
+ </para></listitem>
+
+ <listitem><para><literal>HOME</literal>: set to your home directory (e.g. <literal>c:/userid</literal>).
+ This is where, among other things, <command>ssh</command> will look for your <literal>.ssh</literal> directory.
+ </para></listitem>
+
+ <listitem><para><literal>SHELL</literal>: set to <literal>c:/msys/1.0/bin/sh.exe</literal>
+ </para></listitem>
+
+ <listitem><para><literal>CVS_RSH</literal>: set to <literal>c:/msys/1.0/bin/ssh.exe</literal>. Only necessary if
+ you are using CVS.
+ </para></listitem>
+
+ <listitem><para><literal>MAKE_MODE</literal>: set to <literal>UNIX</literal>. (I'm not certain this is necessary for MSYS.)
+ </para></listitem>
+
+</itemizedlist>
+</para></listitem>
+
+<listitem><para>
+Check that the <literal>CYGWIN</literal> environment variable is <emphasis>not</emphasis> set. It's a bad bug
+that MSYS is affected by this, but if you have CYGWIN set to "ntsec ntea", which is right for Cygwin, it
+causes the MSYS <command>ssh</command> to bogusly fail complaining that your <filename>.ssh/identity</filename>
+file has too-liberal permissinos.
+</para></listitem>
+
+</itemizedlist>
+</para>
+<para>Here are some points to bear in mind when using MSYS:
+<itemizedlist>
+<listitem> <para> MSYS does some kind of special magic to binaries stored in
+<filename>/bin</filename> and <filename>/usr/bin</filename>, which are by default both mapped
+to <filename>c:/msys/1.0/bin</filename> (assuming you installed MSYS in <filename>c:/msys</filename>).
+Do not put any other binaries (such as GHC or Alex) in this directory or its sub-directories:
+they fail in mysterious ways. However, it's fine to put other binaries in <filename>/usr/local/bin</filename>,
+which maps to <filename>c:/msys/1.0/local/bin</filename>.</para></listitem>
+
+<listitem> <para> MSYS seems to implement symbolic links by copying, so sharing is lost.
+</para></listitem>
+
+<listitem> <para>
+Win32 has a <command>find</command> command which is not the same as MSYS's find.
+You will probably discover that the Win32 <command>find</command> appears in your <constant>PATH</constant>
+before the MSYS one, because it's in the <emphasis>system</emphasis> <constant>PATH</constant>
+environment variable, whereas you have probably modified the <emphasis>user</emphasis> <constant>PATH</constant>
+variable. You can always invoke <command>find</command> with an absolute path, or rename it.
+</para></listitem>
+
+<listitem> <para>
+MSYS comes with <command>bzip</command>, and MSYS's <command>tar</command>'s <literal>-j</literal>
+will bunzip an archive (e.g. <literal>tar xvjf foo.tar.bz2</literal>). Useful when you get a
+bzip'd dump.</para></listitem>
+
+</itemizedlist>
</para>
-</sect3>
</sect2>
<Sect2><Title>Installing and configuring Cygwin</Title>
-<para>You don't need Cygwin to <emphasis>use</emphasis> GHC,
-but you do need it to <emphasis>build</emphasis> GHC.</para>
-
<para> Install Cygwin from <ulink url="http://www.cygwin.com/">http://www.cygwin.com/</ulink>.
The installation process is straightforward; we install it in <Filename>c:/cygwin</Filename>.
-During the installation dialogue, make sure that you select:
-<command>cvs</command>, <command>openssh</command>,
-<command>autoconf</command>,
-<command>binutils</command> (includes ld and (I think) ar),
-<command>gcc</command>,
-<command>flex</command>,
-<command>make</command>.
-
+During the installation dialogue, make sure that you select all of the following:
+ <command>cvs</command>,
+ <command>openssh</command>,
+ <command>autoconf</command>,
+ <command>binutils</command> (includes ld and (I think) ar),
+ <command>gcc</command>,
+ <command>flex</command>,
+ <command>make</command>.
+If you miss out any of these, strange things will happen to you. To see thse packages,
+click on the "View" button in the "Select Packages"
+stage of Cygwin's installation dialogue, until the view says "Full". The default view, which is
+"Category" isn't very helpful, and the "View" button is rather unobtrousive.
</para>
<para> Now set the following user environment variables:
<itemizedlist>
</listitem>
<listitem><para> Set <constant>SHELL</constant> to
-<Filename>c:/cygwin/bin/sh</Filename>. When you invoke a shell in Emacs, this
+<Filename>c:/cygwin/bin/bash</Filename>. When you invoke a shell in Emacs, this
<constant>SHELL</constant> is what you get.
</para></listitem>
</para></listitem>
<listitem> <para>
-Win32 has a <command>find</command> command which is not the same as Cygwin's find.
-You will probably discover that the Win32 <command>find</command> appears in your <constant>PATH</constant>
-before the Cygwin one, because it's in the <emphasis>system</emphasis> <constant>PATH</constant>
-environment variable, whereas you have probably modified the <emphasis>user</emphasis> <constant>PATH</constant>
-variable. You can always invoke <command>find</command> with an absolute path, or rename it.
+See the notes in <xref linkend="msys-install"> about <command>find</command> and <command>bzip</command>,
+which apply to Cygwin too.
</para></listitem>
</itemizedlist>
</para>
</Sect2>
+
<Sect2 id="configure-ssh"><Title>Configuring SSH</Title>
<para><command>ssh</command> comes with Cygwin, provided you remember to ask for it when
</Screen> </para>
</listitem>
-<listitem><para>
+<listitem><para> (Cygwin-only problem, I think.)
<command>ssh</command> needs to access your directory <filename>.ssh</filename>, in your home directory.
To determine your home directory <command>ssh</command> first looks in
<filename>c:/cygwin/etc/passwd</filename> (or wherever you have Cygwin installed). If there's an entry
<Sect2><Title>Other things you need to install</Title>
-<para>You have to install the following other things to build GHC:
+<para>You have to install the following other things to build GHC, listed below.</para>
+
+<para>On Windows you often install executables in directories with spaces, such as
+"<filename>Program Files</filename>". However, the <literal>make</literal> system for fptools doesn't
+deal with this situation (it'd have to do more quoting of binaries), so you are strongly advised
+to put binaries for all tools in places with no spaces in their path.
+On both MSYS and Cygwin, it's perfectly OK to install such programs in the standard Unixy places,
+<filename>/usr/local/bin</filename> and <filename>/usr/local/lib</filename>. But it doesn't matter,
+provided they are in your path.
<itemizedlist>
<listitem>
<para>
<listitem>
<para>
Install an executable Happy, from <ulink url="http://www.haskell.org/happy">http://www.haskell.org/happy</ulink>.
-Happy is a parser generator used to compile the Haskell grammar. Add it in your
+Happy is a parser generator used to compile the Haskell grammar. Under MSYS or Cygwin you can easily
+build it from the source distribution using
+<programlisting>
+ ./configure
+ make
+ make install
+</programlisting>
+This should install it in <filename>/usr/local/bin</filename> (which maps to <filename>c:/msys/1.0/local/bin</filename>
+on MSYS).
+Make sure the installation directory is in your
<constant>PATH</constant>.
</para>
</listitem>
<listitem>
<para>Install Alex. This can be done by building from the
- source distribution in the usual way. Sources are
+ source distribution in the same way as Happy. Sources are
available from <ulink
url="http://www.haskell.org/alex">http://www.haskell.org/alex</ulink>.</para>
</listitem>
<ItemizedList>
<listitem>
<para>
-Run <Command>autoconf</Command> both in <filename>fptools</filename>
-and in <filename>fptools/ghc</filename>. If you omit the latter step you'll
-get an error when you run <filename>./configure</filename>:
+If you used <Command>autoconf</Command> instead of <Command>autoreconf</Command>,
+you'll get an error when you run <filename>./configure</filename>:
<Screen>
...lots of stuff...
creating mk/config.h
</para>
</listitem>
-<listitem> <para><command>autoconf</command> seems to create the file <filename>configure</filename>
-read-only. So if you need to run autoconf again (which I sometimes do for safety's sake),
+<listitem> <para><command>autoreconf</command> seems to create the file <filename>configure</filename>
+read-only. So if you need to run autoreconf again (which I sometimes do for safety's sake),
you get
<screen>
/usr/bin/autoconf: cannot create configure: permission denied
</para></listitem>
<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>
-</listitem>
-
-<listitem><para>
-If you are paranoid, delete <filename>config.cache</filename> if it exists.
-This file occasionally remembers out-of-date configuration information, which
-can be really confusing.
-</para>
-</listitem>
-
-<listitem>
<para>
- After <command>autoconf</command> run <command>./configure</command> in
+ After <command>autoreconf</command> run <command>./configure</command> in
<filename>fptools/</filename> thus:
<Screen>
</para>
</listitem>
+<listitem><para>
+If you are paranoid, delete <filename>config.cache</filename> if it exists.
+This file occasionally remembers out-of-date configuration information, which
+can be really confusing.
+</para>
+</listitem>
+
<listitem><para> You almost certainly want to set
<programlisting>
SplitObjs = NO
projects / ghc-hetmet.git / blobdiff