<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>
+ <screen>/cvs : no such repository</screen></para>
</listitem>
<listitem>
<para>Run the command</para>
-<programlisting>
- $ cvs login
-</programlisting>
+<screen>$ cvs login</screen>
<para>The password is simply <literal>cvs</literal>. This
sets up a file in your home directory called
<literal>.cvspass</literal>, which squirrels away the
<listitem>
<para>Generate a DSA private-key/public-key pair, thus:</para>
-<screen>
- $ ssh-keygen -d
-</screen>
+<screen>$ ssh-keygen -d</screen>
<para>(<literal>ssh-keygen</literal> comes with
<literal>ssh</literal>.) Running <literal>ssh-keygen
-d</literal> creates the private and public keys in
you have Version 2 <literal>ssh</literal> installed; it
will fail harmlessly otherwise. If you only have Version
1 you can instead generate an RSA key pair using plain</para>
-<screen>
- $ ssh-keygen
-</screen>
+<screen>$ ssh-keygen</screen>
<para>Doing so creates the private and public RSA keys in
<literal>$HOME/.ssh/identity</literal> and
2 <literal>ssh</literal> to use the Version 1 protocol by
creating <literal>$HOME/config</literal> with the
following in it:</para>
-<screen>
- BatchMode Yes
+<programlisting>BatchMode Yes
- Host cvs.haskell.org
- Protocol 1
-</screen>
+Host cvs.haskell.org
+Protocol 1</programlisting>
<para>In both cases, <literal>ssh-keygen</literal> will
ask for a <firstterm>passphrase</firstterm>. The
Put the following in <filename>$HOME/.cvsrc</filename>:
</para>
- <programlisting>
- checkout -P
- release -d
- update -P
- diff -u
- </programlisting>
+<programlisting>checkout -P
+release -d
+update -P
+diff -u</programlisting>
<para>
These are the default options for the specified CVS commands,
methods above. The Approved Way to check out a source tree
is as follows:</para>
-<screen>
- $ cvs checkout fpconfig
-</screen>
+<screen>$ cvs checkout fpconfig</screen>
<para>At this point you have a new directory called
<literal>fptools</literal> which contains the basic stuff
some other junk. </para>
<para>[Windows users.] The following messages appear to be harmless:
-<screen>
-setsockopt IPTOS_LOWDELAY: Invalid argument
-setsockopt IPTOS_THROUGHPUT: Invalid argument
-</screen>
+<screen>setsockopt IPTOS_LOWDELAY: Invalid argument
+setsockopt IPTOS_THROUGHPUT: Invalid argument</screen>
</para>
<para>You can call the fptools directory whatever you like,
CVS won't mind: </para>
-<screen>
- $ mv fptools <replaceable>directory</replaceable>
-</screen>
+<screen>$ mv fptools <replaceable>directory</replaceable></screen>
<para> NB: after you've read the CVS manual you might be
tempted to try</para>
-<screen>
- $ cvs checkout -d <replaceable>directory</replaceable> fpconfig
-</screen>
+<screen>$ cvs checkout -d <replaceable>directory</replaceable> fpconfig</screen>
<para>instead of checking out <literal>fpconfig</literal>
and then renaming it. But this doesn't work, and will
result in checking out the entire repository instead of just
the <literal>fpconfig</literal> bit.</para>
-<screen>
- $ cd <replaceable>directory</replaceable>
- $ cvs checkout ghc hslibs libraries
-</screen>
+<screen>$ cd <replaceable>directory</replaceable>
+$ cvs checkout ghc hslibs libraries</screen>
<para>The second command here checks out the relevant
modules you want to work on. For a GHC build, for instance,
<listitem>
<para>Test them. You can see exactly what changes you've
made by using the <literal>cvs diff</literal> command:</para>
-<screen>
-$ cvs diff
-</screen>
+<screen>$ cvs diff</screen>
<para>lists all the changes (using the
<literal>diff</literal> command) in and below the current
directory. In emacs, <literal>C-c C-v =</literal> runs
<para>Before checking in a change, you need to update your
source tree:</para>
-<screen>
-$ cd fptools
-$ cvs update
-</screen>
+<screen>$ cd fptools
+$ cvs update</screen>
<para>This pulls in any changes that other people have made,
and merges them with yours. If there are any conflicts, CVS
will tell you, and you'll have to resolve them before you
<para>When you're happy that your change isn't going to
break anything, check it in. For a one-file change:</para>
-<screen>
-$ cvs commit <replaceable>filename</replaceable>
-</screen>
+<screen>$ cvs commit <replaceable>filename</replaceable></screen>
<para>CVS will then pop up an editor for you to enter a
"commit message", this is just a short description
way I find easiest. First type the commit message into a
temporary file. Then either</para>
-<screen>
-$ cvs commit -F <replaceable>commit-message</replaceable> <replaceable>file_1</replaceable> .... <replaceable>file_n</replaceable>
-</screen>
+<screen>$ cvs commit -F <replaceable>commit-message</replaceable> <replaceable>file_1</replaceable> .... <replaceable>file_n</replaceable></screen>
<para>or, if nothing else has changed in this part of the
source tree, </para>
-<screen>
-$ cvs commit -F <replaceable>commit-message</replaceable> <replaceable>directory</replaceable>
-</screen>
+<screen>$ cvs commit -F <replaceable>commit-message</replaceable> <replaceable>directory</replaceable></screen>
<para>where <replaceable>directory</replaceable> is a common
parent directory for all your changes, and
<para>So, to avoid a lot of hassle, follow this recipe for
updating your tree:</para>
-<screen>
-$ cd fptools
+<screen>$ cd fptools
$ cvs update -P 2>&1 | tee log</screen>
<para>Look at the log file, and fix any conflicts (denoted by a
<quote>C</quote> in the first column). New directories may have
appeared in the repository; CVS doesn't check these out by
default, so to get new directories you have to explicitly do
-<screen>
-$ cvs update -d</screen>
+<screen>$ cvs update -d</screen>
in each project subdirectory. Don't do this at the top level,
because then <emphasis>all</emphasis> the projects will be
checked out.</para>
tree you have pointing at this source tree, you need to update
the links in case any new files have appeared: </para>
-<screen>
-$ cd <replaceable>build-tree</replaceable>
-$ lndir <replaceable>source-tree</replaceable>
-</screen>
+<screen>$ cd <replaceable>build-tree</replaceable>
+$ lndir <replaceable>source-tree</replaceable></screen>
<para>Some files might have been removed, so you need to remove
the links pointing to these non-existent files:</para>
-<screen>
-$ find . -xtype l -exec rm '{}' \;
-</screen>
+<screen>$ find . -xtype l -exec rm '{}' \;</screen>
<para>To be <emphasis>really</emphasis> safe, you should do
</para>
<para>So, to check out a fresh GHC 4.06 tree you would
do:</para>
-<screen>
- $ cvs co -r ghc-4-06 fpconfig
- $ cd fptools
- $ cvs co -r ghc-4-06 ghc hslibs
-</screen>
+<screen>$ cvs co -r ghc-4-06 fpconfig
+$ cd fptools
+$ cvs co -r ghc-4-06 ghc hslibs</screen>
</sect2>
<sect2 id="cvs-hints">
checked-out fptools tree containing just ghc, and you want
to add nofib to it:</para>
-<screen>
-$ cd fptools
-$ cvs checkout nofib
-</screen>
+<screen>$ cd fptools
+$ cvs checkout nofib</screen>
<para>or: </para>
-<screen>
-$ cd fptools
-$ cvs update -d nofib
-</screen>
+<screen>$ cd fptools
+$ cvs update -d nofib</screen>
<para>(the -d flag tells update to create a new
directory). If you just want part of the nofib suite, you
can do </para>
-<screen>
-$ cd fptools
-$ cvs checkout nofib/spectral
-</screen>
+<screen>$ cd fptools
+$ cvs checkout nofib/spectral</screen>
<para>This works because <literal>nofib</literal> is a
module in its own right, and spectral is a subdirectory of
<screen>$ autoreconf
$ ./configure
$ make
-$ make install
-</screen>
+$ make install</screen>
<para>For GHC, this will do a 2-stage bootstrap build of the
compiler, with profiling libraries, and install the
<para>Change directory to
<constant>$(FPTOOLS_TOP)</constant> and
issue the command</para>
-<programlisting>
-autoreconf
-</programlisting>
+<programlisting>autoreconf</programlisting>
<indexterm><primary>autoreconf</primary></indexterm>
<para>(with no arguments). This GNU program (recursively) converts
<filename>$(FPTOOLS_TOP)/configure.ac</filename> and
<para>Runs the newly-created <command>configure</command>
script, thus:</para>
-<programlisting>
-./configure <optional><parameter>args</parameter></optional>
-</programlisting>
+<programlisting>./configure <optional><parameter>args</parameter></optional></programlisting>
<para><command>configure</command>'s mission is to scurry
round your computer working out what architecture it has,
<para>For example, <filename>config.mk.in</filename> contains
the definition:</para>
-<programlisting>
-GhcHcOpts=-O -Rghc-timing
-</programlisting>
+<programlisting>GhcHcOpts=-O -Rghc-timing</programlisting>
<para>The accompanying comment explains that this is the list of
flags passed to GHC when building GHC itself. For doing
<para>or, if you prefer,</para>
-<programlisting>
-GhcHcOpts += -DDEBUG
-</programlisting>
+<programlisting>GhcHcOpts += -DDEBUG</programlisting>
<para>GNU <command>make</command> allows existing definitions to
have new text appended using the “<literal>+=</literal>”
lot quicker), you can just override
<literal>GhcLibHcOpts</literal> altogether:</para>
-<programlisting>
-GhcHcOpts=-DDEBUG -Rghc-timing
-</programlisting>
+<programlisting>GhcHcOpts=-DDEBUG -Rghc-timing</programlisting>
<para>When reading <filename>config.mk.in</filename>, remember
that anything between “@...@” signs is going to be substituted
you want, but you need to be a bit surer what you are doing.
For example, there's a line that says:</para>
-<programlisting>
-TAR = @TarCmd@
-</programlisting>
+<programlisting>TAR = @TarCmd@</programlisting>
<para>This defines the Make variables <constant>TAR</constant>
to the pathname for a <command>tar</command> that
own pet <command>tar</command> you want to use instead, that's
fine. Just add this line to <filename>mk/build.mk</filename>:</para>
-<programlisting>
-TAR = mytar
-</programlisting>
+<programlisting>TAR = mytar</programlisting>
<para>You do not <emphasis>have</emphasis> to have a
<filename>mk/build.mk</filename> file at all; if you don't,
<para>(Optional) Use <command>lndir</command> or
<command>mkshadowdir</command> to create a build tree.</para>
-<programlisting>
-$ cd myfptools
-$ mkshadowdir . /scratch/joe-bloggs/myfptools-sun4
-</programlisting>
+<programlisting>$ cd myfptools
+$ mkshadowdir . /scratch/joe-bloggs/myfptools-sun4</programlisting>
<para>(N.B. <command>mkshadowdir</command>'s first argument
is taken relative to its second.) You probably want to give
<para>Change directory to the build tree. Everything is
going to happen there now.</para>
-<programlisting>
-$ cd /scratch/joe-bloggs/myfptools-sun4
-</programlisting>
+<programlisting>$ cd /scratch/joe-bloggs/myfptools-sun4</programlisting>
</listitem>
<listitem>
<para>Prepare for system configuration:</para>
-<programlisting>
-$ autoreconf
-</programlisting>
+<programlisting>$ autoreconf</programlisting>
<para>(You can skip this step if you are starting from a
source distribution, and you already have
<listitem>
<para>Do system configuration:</para>
-<programlisting>
-$ ./configure
-</programlisting>
+<programlisting>$ ./configure</programlisting>
<para>Don't forget to check whether you need to add any
arguments to <literal>configure</literal>; for example, a
adding definitions for your desired configuration
options.</para>
-<programlisting>
-$ emacs mk/build.mk
-</programlisting>
+<programlisting>$ emacs mk/build.mk</programlisting>
</listitem>
</orderedlist>
generated <filename>.depend</filename> file will contain
the dependency:</para>
-<programlisting>
-Foo.o : Baz.hi
-</programlisting>
+<programlisting>Foo.o : Baz.hi</programlisting>
<para>which says that the object file
<filename>Foo.o</filename> depends on the interface file
<command>make</command> is going to rebuild everything anyway,
the following hack may be useful:</para>
-<programlisting>
-gmake FAST=YES
-</programlisting>
+<programlisting>gmake FAST=YES</programlisting>
<para>This tells the make system to ignore dependencies and just
build what you tell it to. In other words, it's equivalent to
the contents of any make variable in the context of the current
<filename>Makefile</filename>:</para>
-<screen>$ make show VALUE=HS_SRCS</screen>
+<screen>$ make show VALUE=HS_SRCS</screen>
<para>where you can replace <literal>HS_SRCS</literal> with the
name of any variable you wish to see the value of.</para>
<indexterm><primary>Makefile, minimal</primary></indexterm>
-<programlisting>
-# Makefile for fptools project "small"
+<programlisting># Makefile for fptools project "small"
TOP = ..
include $(TOP)/mk/boilerplate.mk
SRCS = $(wildcard *.lhs) $(wildcard *.c)
HS_PROG = small
-include $(TOP)/target.mk
-</programlisting>
+include $(TOP)/target.mk</programlisting>
<para>this <filename>Makefile</filename> has three
sections:</para>
directory in which the <filename>boilerplate.mk</filename>
file is. It is <emphasis>not</emphasis> OK to simply say</para>
-<programlisting>
-include ../mk/boilerplate.mk # NO NO NO
-</programlisting>
+<programlisting>include ../mk/boilerplate.mk # NO NO NO</programlisting>
<para>Why? Because the <filename>boilerplate.mk</filename>
rare.) To give you the idea, here's part of the directory
structure for the (rather large) GHC project:</para>
-<screen>
-$(FPTOOLS_TOP)/ghc/
+<screen>$(FPTOOLS_TOP)/ghc/
Makefile
mk/
boilerplate.mk
Makefile
parser/...source files for parser...
renamer/...source files for renamer...
- ...etc...
-</screen>
+ ...etc...</screen>
<para>The sub-directories <filename>docs</filename>,
<filename>driver</filename>, <filename>compiler</filename>, and
<emphasis>augment</emphasis> them. For example, a
<filename>Makefile</filename> might say:</para>
-<programlisting>
-SRC_HC_OPTS += -O
-</programlisting>
+<programlisting>SRC_HC_OPTS += -O</programlisting>
<para>thereby adding “<option>-O</option>” to
the end of
<filename>target.mk</filename> has a rule that looks
like this:</para>
-<programlisting>
-$(HS_PROG) : $(OBJS)
- $(HC) $(LD_OPTS) $< -o $@
-</programlisting>
+<programlisting>$(HS_PROG) : $(OBJS)
+ $(HC) $(LD_OPTS) $< -o $@</programlisting>
<para>If this rule was in
<filename>boilerplate.mk</filename> then
<para>Almost all the rules look something like this:</para>
-<programlisting>
-%.o : %.c
+<programlisting>%.o : %.c
$(RM) $@
- $(CC) $(CC_OPTS) -c $< -o $@
-</programlisting>
+ $(CC) $(CC_OPTS) -c $< -o $@</programlisting>
<para>Here's how to understand the rule. It says that
<emphasis>something</emphasis><filename>.o</filename> (say
defined in <filename>mk/opts.mk</filename>. Almost all of them
are defined like this:</para>
-<programlisting>
-CC_OPTS = \
- $(SRC_CC_OPTS) $(WAY$(_way)_CC_OPTS) $($*_CC_OPTS) $(EXTRA_CC_OPTS)
-</programlisting>
+<programlisting>CC_OPTS = \
+ $(SRC_CC_OPTS) $(WAY$(_way)_CC_OPTS) $($*_CC_OPTS) $(EXTRA_CC_OPTS)</programlisting>
<para>The four variables from which
<constant>CC_OPTS</constant> is built have the following
<para>extra options to pass to all C compilations. This
is intended for command line use, thus:</para>
-<programlisting>
-gmake libHS.a EXTRA_CC_OPTS="-v"
-</programlisting>
+<programlisting>gmake libHS.a EXTRA_CC_OPTS="-v"</programlisting>
</listitem>
</varlistentry>
</variablelist>
<para>All of these rules are “double-colon” rules,
thus</para>
-<programlisting>
-install :: $(HS_PROG)
- ...how to install it...
-</programlisting>
+<programlisting>install :: $(HS_PROG)
+ ...how to install it...</programlisting>
<para>GNU <command>make</command> treats double-colon rules as
separate entities. If there are several double-colon rules for
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>
+<programlisting>%.$(way_)o : %.lhs
+ $(HC) $(HC_OPTS) $< -o $@</programlisting>
Neat, eh?</para>
</listitem>
to build files related to a particular
<literal>way</literal> in the current directory. eg.
-<screen>
-$ make way=p
-</screen>
+<screen>$ make way=p</screen>
will build files for the profiling way only in the current
directory. </para>
FreeBSD mirror site).</para>
<para>To use the ports tree, do this:
-<screen>
- $ cd /usr/ports/textproc/docproj
- $ make install
-</screen>
+<screen>$ cd /usr/ports/textproc/docproj
+$ make install</screen>
This installs the FreeBSD documentation project tools, which
includes everything needed to format the GHC
documentation.</para>
<filename>dsssl</filename> subdirectory. (If you get the
error:
-<screen>
-! LaTeX Error: Unknown option implicit=false' for package hyperref'.
-</screen>
+<screen>! LaTeX Error: Unknown option implicit=false' for package hyperref'.</screen>
your version of <command>hyperref</command> is out of date;
download it from CTAN
<para>To build documentation in a certain format, you can
say, for example,</para>
-<screen>
-$ make html
-</screen>
+<screen>$ make html</screen>
<para>to build HTML documentation below the current directory.
The available formats are: <literal>dvi</literal>,
to a list of them. For example, in
<filename>build.mk</filename> you might have a line:</para>
-<screen>
-SGMLDocWays = html ps
-</screen>
+<screen>SGMLDocWays = html ps</screen>
<para>This will cause the documentation to be built in the requested
formats as part of the main build (the default is not to build
<para>To install the documentation, use:</para>
-<screen>
-$ make install-docs
-</screen>
+<screen>$ make install-docs</screen>
<para>This will install the documentation into
<literal>$(datadir)</literal> (which defaults to
command will execute the whole build process (it won't
install yet):</para>
-<screen>
-foo% distrib/hc-build --prefix=<replaceable>dir</replaceable>
-</screen>
+<screen>foo% distrib/hc-build --prefix=<replaceable>dir</replaceable></screen>
<indexterm><primary>--hc-build</primary></indexterm>
<para>By default, the installation directory is
build process, you can install the resulting system, as
normal, with</para>
-<screen>
-foo% make install
-</screen>
+<screen>foo% make install</screen>
</listitem>
</itemizedlist>
</sect2>
</listitem>
<listitem>
-<screen>
-$ cd <replaceable>T</replaceable>
-$ ./configure --enable-hc-boot --enable-hc-boot-unregisterised
-</screen>
+<screen>$ cd <replaceable>T</replaceable>
+$ ./configure --enable-hc-boot --enable-hc-boot-unregisterised</screen>
<para>You might need to update
<filename>configure.in</filename> to recognise the new
</listitem>
<listitem>
-<screen>
-$ cd <replaceable>T</replaceable>/ghc/includes
-$ make config.h
-</screen>
+<screen>$ cd <replaceable>T</replaceable>/ghc/includes
+$ make config.h</screen>
</listitem>
</itemizedlist>
</listitem>
</listitem>
<listitem>
-<screen>
-$ cd <replaceable>H</replaceable>
-$ ./configure
-</screen>
+<screen>$ cd <replaceable>H</replaceable>
+$ ./configure</screen>
</listitem>
<listitem>
<filename><replaceable>H</replaceable>/mk/build.mk</filename>,
with the following contents:</para>
-<programlisting>
-GhcUnregisterised = YES
+<programlisting>GhcUnregisterised = YES
GhcLibHcOpts = -O -H32m -keep-hc-files
GhcLibWays =
SplitObjs = NO
GhcWithNativeCodeGen = NO
GhcWithInterpreter = NO
GhcStage1HcOpts = -O -H32m -fasm
-GhcStage2HcOpts = -O -fvia-C -keep-hc-files
-</programlisting>
+GhcStage2HcOpts = -O -fvia-C -keep-hc-files</programlisting>
</listitem>
<listitem>
<listitem>
<para>Touch <literal>config.h</literal>, just to make
sure it doesn't get replaced during the build:</para>
-<screen>
-$ touch <replaceable>H</replaceable>/ghc/includes/config.h</screen>
+<screen>$ touch <replaceable>H</replaceable>/ghc/includes/config.h</screen>
</listitem>
<listitem>
<para>Now build the compiler:</para>
-<screen>
-$ cd <replaceable>H</replaceable>/glafp-utils && make boot && make
-$ cd <replaceable>H</replaceable>/ghc && make boot && make
-</screen>
+<screen>$ cd <replaceable>H</replaceable>/glafp-utils && make boot && make
+$ cd <replaceable>H</replaceable>/ghc && make boot && make</screen>
<para>Don't worry if the build falls over in the RTS, we
don't need the RTS yet.</para>
</listitem>
<listitem>
-<screen>
-$ cd <replaceable>H</replaceable>/libraries
-$ make boot && make
-</screen>
+<screen>$ cd <replaceable>H</replaceable>/libraries
+$ make boot && make</screen>
</listitem>
<listitem>
-<screen>
-$ cd <replaceable>H</replaceable>/ghc
-$ make boot stage=2 && make stage=2
-</screen>
+<screen>$ cd <replaceable>H</replaceable>/ghc
+$ make boot stage=2 && make stage=2</screen>
</listitem>
<listitem>
- <screen>
-$ cd <replaceable>H</replaceable>/ghc/utils
+<screen>$ cd <replaceable>H</replaceable>/ghc/utils
$ make clean
$ make -k HC=<replaceable>H</replaceable>/ghc/compiler/stage1/ghc-inplace \
- EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'
-</screen>
+ EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'</screen>
</listitem>
<listitem>
-<screen>
-$ cd <replaceable>H</replaceable>
-$ make hc-file-bundle Project=Ghc
-</screen>
+<screen>$ cd <replaceable>H</replaceable>
+$ make hc-file-bundle Project=Ghc</screen>
</listitem>
<listitem>
script in <literal>distrib/hc-build</literal>, and is
described in <xref linkend="sec-booting-from-hc"/>.</para>
-<screen>
-$ ./distrib/hc-build --enable-hc-boot-unregisterised
-</screen>
+<screen>$ ./distrib/hc-build --enable-hc-boot-unregisterised</screen>
<para>However, since this is a bootstrap on a new machine,
the automated process might not run to completion the
to check that the bootstrapped compiler is generating
working binaries:</para>
-<screen>
-$ cat >hello.hs
+<screen>$ cat >hello.hs
main = putStrLn "Hello World!\n"
^D
$ <replaceable>T</replaceable>/ghc/compiler/ghc-inplace hello.hs -o hello
$ ./hello
-Hello World!
-</screen>
+Hello World!</screen>
<para>Once you have the unregisterised compiler up and
running, you can use it to start a registerised port. The
The best way around it is to say
-<programlisting>
-export TMPDIR=<dir>
-</programlisting>
+<programlisting>export TMPDIR=<dir></programlisting>
in your <filename>build.mk</filename> file.
Then GHC and the other <literal>fptools</literal> programs will use the appropriate directory
Similarly, <command>ar</command>chiving warning messages like the following are not
a problem:
-<screen>
-ar: filename GlaIOMonad__1_2s.o truncated to GlaIOMonad_
+<screen>ar: filename GlaIOMonad__1_2s.o truncated to GlaIOMonad_
ar: filename GlaIOMonad__2_2s.o truncated to GlaIOMonad_
-...
-</screen>
+...</screen>
</para>
Alternatively, just cut to the chase:
-<screen>
-% cd ghc/compiler
-% make EXTRA_HC_OPTS=-optCrts-M128M
-</screen>
+<screen>% cd ghc/compiler
+% make EXTRA_HC_OPTS=-optCrts-M128M</screen>
</para>
You <emphasis>may</emphasis> need to re-<command>ranlib</command><indexterm><primary>ranlib</primary></indexterm> your libraries (on Sun4s).
-<screen>
-% cd $(libdir)/ghc-x.xx/sparc-sun-sunos4
+<screen>% cd $(libdir)/ghc-x.xx/sparc-sun-sunos4
% foreach i ( `find . -name '*.a' -print` ) # or other-shell equiv...
? ranlib $i
? # or, on some machines: ar s $i
-? end
-</screen>
+? end</screen>
We'd be interested to know if this is still necessary.
like this:
-<programlisting>
-SLIT("Hello, world")
-</programlisting>
+<programlisting>SLIT("Hello, world")</programlisting>
Some <command>cpp</command>s treat the comma inside the string as separating two macro
arguments, so you get
-<screen>
-:731: macro `SLIT' used with too many (2) args
-</screen>
+<screen>:731: macro `SLIT' used with too many (2) args</screen>
Alas, <command>cpp</command> doesn't tell you the offending file!
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>
+<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>
<para>
In the source code you'll find various ifdefs looking like:
-<programlisting>
- #ifdef mingw32_HOST_OS
- ...blah blah...
- #endif
-</programlisting>
+<programlisting>#ifdef mingw32_HOST_OS
+ ...blah blah...
+#endif</programlisting>
and
-<programlisting>
- #ifdef mingw32_TARGET_OS
- ...blah blah...
- #endif
-</programlisting>
+<programlisting>#ifdef mingw32_TARGET_OS
+ ...blah blah...
+#endif</programlisting>
These macros are set by the configure script (via the file config.h).
Which is which? The criterion is this. In the ifdefs in GHC's source code:
<itemizedlist>
Set <constant>MAKE_MODE</constant> to <literal>UNIX</literal>. If you
don't do this you get very weird messages when you type
<command>make</command>, such as:
-<screen>
-/c: /c: No such file or directory
-</screen>
+<screen>/c: /c: No such file or directory</screen>
</para>
</listitem>
seem to lock up <command>bash</command> entirely if they try to get user input (e.g. if
they ask for a password). To solve this, start up <filename>cmd.exe</filename>
and run it as follows:
- <screen>
- c:\tmp> set CYGWIN32=tty
- c:\tmp> c:/user/local/bin/ssh-keygen1
- </screen> </para>
+<screen>c:\tmp> set CYGWIN32=tty
+c:\tmp> c:/user/local/bin/ssh-keygen1</screen> </para>
</listitem>
<listitem><para> (Cygwin-only problem, I think.)
there with your userid, it'll use that entry to determine your home directory, <emphasis>ignoring
the setting of the environment variable $HOME</emphasis>. If the home directory is
bogus, <command>ssh</command> fails horribly. The best way to see what is going on is to say
-<programlisting>
- ssh -v cvs.haskell.org
-</programlisting>
+<programlisting>ssh -v cvs.haskell.org</programlisting>
which makes <command>ssh</command> print out information about its activity.
</para>
<para> You can fix this problem, either by correcting the home-directory field in
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. Under MSYS or Cygwin you can easily
build it from the source distribution using
-<programlisting>
- ./configure
- make
- make install
-</programlisting>
+<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
configuring in ghc
running /bin/sh ./configure --cache-file=.././config.cache --srcdir=.
./configure: ./configure: No such file or directory
-configure: error: ./configure failed for ghc
-</screen>
+configure: error: ./configure failed for ghc</screen>
</para>
</listitem>
<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
-</screen>
+<screen>/usr/bin/autoconf: cannot create configure: permission denied</screen>
Solution: delete <filename>configure</filename> first.
</para></listitem>
After <command>autoreconf</command> run <command>./configure</command> in
<filename>fptools/</filename> thus:
-<screen>
- ./configure --host=i386-unknown-mingw32 --with-gcc=c:/mingw/bin/gcc
-</screen>
+<screen>./configure --host=i386-unknown-mingw32 --with-gcc=c:/mingw/bin/gcc</screen>
This is the point at which you specify that you are building GHC-mingw
(see <xref linkend="ghc-mingw"/>). </para>
time it tries to invoke it. Worse, the failure comes with
no error message whatsoever. GHC simply fails silently when first invoked,
typically leaving you with this:
-<programlisting>
-make[4]: Leaving directory `/cygdrive/e/fptools-stage1/ghc/rts/gmp'
+<screen>make[4]: Leaving directory `/cygdrive/e/fptools-stage1/ghc/rts/gmp'
../../ghc/compiler/ghc-inplace -optc-mno-cygwin -optc-O
-optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes
-optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
make[2]: *** [Adjustor.o] Error 1
make[1]: *** [all] Error 1
make[1]: Leaving directory `/cygdrive/e/fptools-stage1/ghc'
-make: *** [all] Error 1
-</programlisting>
+make: *** [all] Error 1</screen>
Be warned!
</para>
<para>
If you want to build GHC-cygwin (<xref linkend="ghc-cygwin"/>)
you'll have to do something more like:
-<screen>
- ./configure --with-gcc=...the Cygwin gcc...
-</screen>
+<screen>./configure --with-gcc=...the Cygwin gcc...</screen>
</para>
</listitem>
</listitem>
<listitem><para> You almost certainly want to set
-<programlisting>
- SplitObjs = NO
-</programlisting>
+<programlisting>SplitObjs = NO</programlisting>
in your <filename>build.mk</filename> configuration file (see <xref linkend="sec-build-config"/>).
This tells the build system not to split each library into a myriad of little object files, one
for each function. Doing so reduces binary sizes for statically-linked binaries, but on Windows
projects / ghc-hetmet.git / commitdiff