1 <?xml version="1.0" encoding="iso-8859-1"?>
2 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
4 <!ENTITY hacking SYSTEM "../../ghc/HACKING">
7 <article id="building-guide">
11 <title>Building and developing GHC</title>
12 <author><othername>The GHC Team</othername></author>
13 <address><email>glasgow-haskell-{users,bugs}@haskell.org</email></address>
16 <para>This Guide is primarily aimed at those who want to build and/or
17 hack on GHC. It describes how to get started with building GHC on your
18 machine, and how to tweak the settings to get the kind of build you
19 want. It also describes the inner workings of the build system, so you
20 can extend it, modify it, and use it to build your code.</para>
22 <para>The bulk of this guide applies to building on Unix
23 systems; see <xref linkend="winbuild"/> for Windows notes.</para>
29 <sect1 id="sec-getting">
30 <title>Getting the sources</title>
32 <para>You can get your hands on the GHC sources in two ways:</para>
37 <term><indexterm><primary>Source
38 distributions</primary></indexterm>Source distributions</term>
40 <para>You have a supported platform, but (a) you like
41 the warm fuzzy feeling of compiling things yourself;
42 (b) you want to build something ``extra”—e.g., a
43 set of libraries with strictness-analysis turned off; or
44 (c) you want to hack on GHC yourself.</para>
46 <para>A source distribution contains complete sources for
47 GHC. Not only that, but the more awkward
48 machine-independent steps are done for you. For example, if
50 <command>happy</command><indexterm><primary>happy</primary></indexterm>
51 you'll find it convenient that the source distribution
52 contains the result of running <command>happy</command> on
53 the parser specifications. If you don't want to alter the
54 parser then this saves you having to find and install
55 <command>happy</command>. You will still need a working
56 version of GHC (version 5.x or later) on your machine in
57 order to compile (most of) the sources, however.</para>
62 <term>The CVS repository.<indexterm><primary>CVS repository</primary></indexterm></term>
64 <para>We make releases infrequently. If you want more
65 up-to-the minute (but less tested) source code then you need
66 to get access to our CVS repository.</para>
68 <para>All the GHC source code is held
69 in a CVS repository. CVS is a pretty good source-code
70 control system, and best of all it works over the
73 <para>The repository holds source code only. It holds no
74 mechanically generated files at all. So if you check out a
75 source tree from CVS you will need to install every utility
76 so that you can build all the derived files from
79 <para>More information about our CVS repository can be found
80 in <xref linkend="sec-cvs"/>.</para>
87 <title>Using the CVS repository</title>
89 <para>We use <ulink url="http://www.cvshome.org/">CVS</ulink> (Concurrent Version System) to keep track of our
90 sources for various software projects. CVS lets several people
91 work on the same software at the same time, allowing changes to be
92 checked in incrementally. </para>
94 <para>This section is a set of guidelines for how to use our CVS
95 repository, and will probably evolve in time. The main thing to
96 remember is that most mistakes can be undone, but if there's
97 anything you're not sure about feel free to bug the local CVS
98 meister (namely Jeff Lewis
99 <email>jlewis@galois.com</email>). </para>
101 <sect2 id="cvs-access">
102 <title>Getting access to the CVS Repository</title>
104 <para>You can access the repository in one of two ways:
105 read-only (<xref linkend="cvs-read-only"/>), or read-write (<xref
106 linkend="cvs-read-write"/>).</para>
108 <sect3 id="cvs-read-only">
109 <title>Remote Read-only CVS Access</title>
111 <para>Read-only access is available to anyone - there's no
112 need to ask us first. With read-only CVS access you can do
113 anything except commit changes to the repository. You can
114 make changes to your local tree, and still use CVS's merge
115 facility to keep your tree up to date, and you can generate
116 patches using 'cvs diff' in order to send to us for
119 <para>To get read-only access to the repository:</para>
123 <para>Make sure that <application>cvs</application> is
124 installed on your machine.</para>
127 <para>Set your <literal>$CVSROOT</literal> environment variable to
128 <literal>:pserver:anoncvs@cvs.haskell.org:/cvs</literal></para>
129 <para>If you set <literal>$CVSROOT</literal> in a shell script, be sure not to
130 have any trailing spaces on that line, otherwise CVS will respond with
131 a perplexing message like
132 <screen>/cvs : no such repository</screen></para>
135 <para>Run the command</para>
136 <screen>$ cvs login</screen>
137 <para>The password is simply <literal>cvs</literal>. This
138 sets up a file in your home directory called
139 <literal>.cvspass</literal>, which squirrels away the
140 dummy password, so you only need to do this step once.</para>
144 <para>Now go to <xref linkend="cvs-first"/>.</para>
149 <sect3 id="cvs-read-write">
150 <title>Remote Read-Write CVS Access</title>
152 <para>We generally supply read-write access to folk doing
153 serious development on some part of the source tree, when
154 going through us would be a pain. If you're developing some
155 feature, or think you have the time and inclination to fix
156 bugs in our sources, feel free to ask for read-write
157 access. There is a certain amount of responsibility that goes
158 with commit privileges; we are more likely to grant you access
159 if you've demonstrated your competence by sending us patches
160 via mail in the past.</para>
162 <para>To get remote read-write CVS access, you need to do the
163 following steps.</para>
167 <para>Make sure that <literal>cvs</literal> and
168 <literal>ssh</literal> are both installed on your
173 <para>Generate a DSA private-key/public-key pair, thus:</para>
174 <screen>$ ssh-keygen -d</screen>
175 <para>(<literal>ssh-keygen</literal> comes with
176 <literal>ssh</literal>.) Running <literal>ssh-keygen
177 -d</literal> creates the private and public keys in
178 <literal>$HOME/.ssh/id_dsa</literal> and
179 <literal>$HOME/.ssh/id_dsa.pub</literal> respectively
180 (assuming you accept the standard defaults).</para>
182 <para><literal>ssh-keygen -d</literal> will only work if
183 you have Version 2 <literal>ssh</literal> installed; it
184 will fail harmlessly otherwise. If you only have Version
185 1 you can instead generate an RSA key pair using plain</para>
186 <screen>$ ssh-keygen</screen>
188 <para>Doing so creates the private and public RSA keys in
189 <literal>$HOME/.ssh/identity</literal> and
190 <literal>$HOME/.ssh/identity.pub</literal>
193 <para>[Deprecated.] Incidentally, you can force a Version
194 2 <literal>ssh</literal> to use the Version 1 protocol by
195 creating <literal>$HOME/config</literal> with the
196 following in it:</para>
197 <programlisting>BatchMode Yes
200 Protocol 1</programlisting>
202 <para>In both cases, <literal>ssh-keygen</literal> will
203 ask for a <firstterm>passphrase</firstterm>. The
204 passphrase is a password that protects your private key.
205 In response to the 'Enter passphrase' question, you can
209 <para>[Recommended.] Enter a passphrase, which you
210 will quote each time you use CVS.
211 <literal>ssh-agent</literal> makes this entirely
215 <para>[Deprecated.] Just hit return (i.e. use an empty
216 passphrase); then you won't need to quote the
217 passphrase when using CVS. The downside is that
218 anyone who can see into your <literal>.ssh</literal>
219 directory, and thereby get your private key, can mess
220 up the repository. So you must keep the
221 <literal>.ssh</literal> directory with draconian
222 no-access permissions.</para>
228 <emphasis>Windows users: see the notes in <xref linkend="configure-ssh"/> about <command>ssh</command> wrinkles!</emphasis>
235 <para>Send a message to to the CVS repository
236 administrator (currently Jeff Lewis
237 <email>jeff@galois.com</email>), containing:</para>
240 <para>Your desired user-name.</para>
243 <para>Your <literal>.ssh/id_dsa.pub</literal> (or
244 <literal>.ssh/identity.pub</literal>).</para>
247 <para>He will set up your account.</para>
251 <para>Set the following environment variables:</para>
255 <constant>$HOME</constant>: points to your home directory. This is where CVS
256 will look for its <filename>.cvsrc</filename> file.
262 <constant>$CVS_RSH</constant> to <filename>ssh</filename>
264 <para>[Windows users.] Setting your <literal>CVS_RSH</literal> to
265 <literal>ssh</literal> assumes that your CVS client
266 understands how to execute shell script
267 ("#!"s,really), which is what
268 <literal>ssh</literal> is. This may not be the case on
269 Win32 platforms, so in that case set <literal>CVS_RSH</literal> to
270 <literal>ssh1</literal>.</para>
274 <para><literal>$CVSROOT</literal> to
275 <literal>:ext:</literal><replaceable>your-username</replaceable>
276 <literal>@cvs.haskell.org:/home/cvs/root</literal>
277 where <replaceable>your-username</replaceable> is your user name on
278 <literal>cvs.haskell.org</literal>.
280 <para>The <literal>CVSROOT</literal> environment variable will
281 be recorded in the checked-out tree, so you don't need to set
282 this every time. </para>
288 <constant>$CVSEDITOR</constant>: <filename>bin/gnuclient.exe</filename>
289 if you want to use an Emacs buffer for typing in those long commit messages.
295 <constant>$SHELL</constant>: To use bash as the shell in Emacs, you need to
296 set this to point to <filename>bash.exe</filename>.
307 Put the following in <filename>$HOME/.cvsrc</filename>:
310 <programlisting>checkout -P
313 diff -u</programlisting>
316 These are the default options for the specified CVS commands,
317 and represent better defaults than the usual ones. (Feel
318 free to change them.)
322 [Windows users.] Filenames starting with <filename>.</filename> were illegal in
323 the 8.3 DOS filesystem, but that restriction should have
324 been lifted by now (i.e., you're using VFAT or later filesystems.) If
325 you're still having problems creating it, don't worry; <filename>.cvsrc</filename> is entirely
333 <para>[Experts.] Once your account is set up, you can get
334 access from other machines without bothering Jeff, thus:</para>
337 <para>Generate a public/private key pair on the new
341 <para>Use ssh to log in to
342 <literal>cvs.haskell.org</literal>, from your old
346 <para>Add the public key for the new machine to the file
347 <literal>$HOME/ssh/authorized_keys</literal> on
348 <literal>cvs.haskell.org</literal>.
349 (<literal>authorized_keys2</literal>, I think, for Version
353 <para>Make sure that the new version of
354 <literal>authorized_keys</literal> still has 600 file
363 <sect2 id="cvs-first">
364 <title>Checking Out a Source Tree</title>
368 <para>Make sure you set your <literal>CVSROOT</literal>
369 environment variable according to either of the remote
370 methods above. The Approved Way to check out a source tree
371 is as follows:</para>
373 <screen>$ cvs checkout fpconfig</screen>
375 <para>At this point you have a new directory called
376 <literal>fptools</literal> which contains the basic stuff
377 for the fptools suite, including the configuration files and
378 some other junk. </para>
380 <para>[Windows users.] The following messages appear to be harmless:
381 <screen>setsockopt IPTOS_LOWDELAY: Invalid argument
382 setsockopt IPTOS_THROUGHPUT: Invalid argument</screen>
386 <para>You can call the fptools directory whatever you like,
387 CVS won't mind: </para>
389 <screen>$ mv fptools <replaceable>directory</replaceable></screen>
391 <para> NB: after you've read the CVS manual you might be
392 tempted to try</para>
393 <screen>$ cvs checkout -d <replaceable>directory</replaceable> fpconfig</screen>
395 <para>instead of checking out <literal>fpconfig</literal>
396 and then renaming it. But this doesn't work, and will
397 result in checking out the entire repository instead of just
398 the <literal>fpconfig</literal> bit.</para>
399 <screen>$ cd <replaceable>directory</replaceable>
400 $ cvs checkout ghc libraries</screen>
402 <para>The second command here checks out the relevant
403 modules you want to work on. For a GHC build, for instance,
404 you need at least the <literal>ghc</literal>,
405 and <literal>libraries</literal>
406 modules (for a full list of the projects available, see
407 <xref linkend="projects"/>).</para>
409 <para>Remember that if you do not have
410 <literal>happy</literal> and/or <literal>Alex</literal>
411 installed, you need to check them out as well.</para>
416 <sect2 id="cvs-committing">
417 <title>Committing Changes</title>
419 <para>This is only if you have read-write access to the
420 repository. For anoncvs users, CVS will issue a "read-only
421 repository" error if you try to commit changes.</para>
425 <para>Build the software, if necessary. Unless you're just
426 working on documentation, you'll probably want to build the
427 software in order to test any changes you make.</para>
431 <para>Make changes. Preferably small ones first.</para>
435 <para>Test them. You can see exactly what changes you've
436 made by using the <literal>cvs diff</literal> command:</para>
437 <screen>$ cvs diff</screen>
438 <para>lists all the changes (using the
439 <literal>diff</literal> command) in and below the current
440 directory. In emacs, <literal>C-c C-v =</literal> runs
441 <literal>cvs diff</literal> on the current buffer and shows
442 you the results.</para>
446 <para>If you changed something in the
447 <literal>fptools/libraries</literal> subdirectories, also run
448 <literal>make html</literal> to check if the documentation can
449 be generated successfully, too.</para>
453 <para>Before checking in a change, you need to update your
457 $ cvs update</screen>
458 <para>This pulls in any changes that other people have made,
459 and merges them with yours. If there are any conflicts, CVS
460 will tell you, and you'll have to resolve them before you
461 can check your changes in. The documentation describes what
462 to do in the event of a conflict.</para>
464 <para>It's not always necessary to do a full cvs update
465 before checking in a change, since CVS will always tell you
466 if you try to check in a file that someone else has changed.
467 However, you should still update at regular intervals to
468 avoid making changes that don't work in conjuction with
469 changes that someone else made. Keeping an eye on what goes
470 by on the mailing list can help here.</para>
474 <para>When you're happy that your change isn't going to
475 break anything, check it in. For a one-file change:</para>
477 <screen>$ cvs commit <replaceable>filename</replaceable></screen>
479 <para>CVS will then pop up an editor for you to enter a
480 "commit message", this is just a short description
481 of what your change does, and will be kept in the history of
484 <para>If you're using emacs, simply load up the file into a
485 buffer and type <literal>C-x C-q</literal>, and emacs will
486 prompt for a commit message and then check in the file for
489 <para>For a multiple-file change, things are a bit
490 trickier. There are several ways to do this, but this is the
491 way I find easiest. First type the commit message into a
492 temporary file. Then either</para>
494 <screen>$ cvs commit -F <replaceable>commit-message</replaceable> <replaceable>file_1</replaceable> .... <replaceable>file_n</replaceable></screen>
496 <para>or, if nothing else has changed in this part of the
499 <screen>$ cvs commit -F <replaceable>commit-message</replaceable> <replaceable>directory</replaceable></screen>
501 <para>where <replaceable>directory</replaceable> is a common
502 parent directory for all your changes, and
503 <replaceable>commit-message</replaceable> is the name of the
504 file containing the commit message.</para>
506 <para>Shortly afterwards, you'll get some mail from the
507 relevant mailing list saying which files changed, and giving
508 the commit message. For a multiple-file change, you should
509 still get only <emphasis>one</emphasis> message.</para>
514 <sect2 id="cvs-update">
515 <title>Updating Your Source Tree</title>
517 <para>It can be tempting to cvs update just part of a source
518 tree to bring in some changes that someone else has made, or
519 before committing your own changes. This is NOT RECOMMENDED!
520 Quite often changes in one part of the tree are dependent on
521 changes in another part of the tree (the
522 <literal>mk/*.mk</literal> files are a good example where
523 problems crop up quite often). Having an inconsistent tree is a
524 major cause of headaches. </para>
526 <para>So, to avoid a lot of hassle, follow this recipe for
527 updating your tree:</para>
530 $ cvs update -P 2>&1 | tee log</screen>
532 <para>Look at the log file, and fix any conflicts (denoted by a
533 <quote>C</quote> in the first column). New directories may have
534 appeared in the repository; CVS doesn't check these out by
535 default, so to get new directories you have to explicitly do
536 <screen>$ cvs update -d</screen>
537 in each project subdirectory. Don't do this at the top level,
538 because then <emphasis>all</emphasis> the projects will be
541 <para>If you're using multiple build trees, then for every build
542 tree you have pointing at this source tree, you need to update
543 the links in case any new files have appeared: </para>
545 <screen>$ cd <replaceable>build-tree</replaceable>
546 $ lndir <replaceable>source-tree</replaceable></screen>
548 <para>Some files might have been removed, so you need to remove
549 the links pointing to these non-existent files:</para>
551 <screen>$ find . -xtype l -exec rm '{}' \;</screen>
553 <para>To be <emphasis>really</emphasis> safe, you should do
556 <screen>$ gmake all</screen>
558 <para>from the top-level, to update the dependencies and build
559 any changed files. </para>
562 <sect2 id="cvs-tags">
563 <title>GHC Tag Policy</title>
565 <para>If you want to check out a particular version of GHC,
566 you'll need to know how we tag versions in the repository. The
567 policy (as of 4.04) is:</para>
571 <para>The tree is branched before every major release. The
572 branch tag is <literal>ghc-x-xx-branch</literal>, where
573 <literal>x-xx</literal> is the version number of the release
574 with the <literal>'.'</literal> replaced by a
575 <literal>'-'</literal>. For example, the 4.04 release lives
576 on <literal>ghc-4-04-branch</literal>.</para>
580 <para>The release itself is tagged with
581 <literal>ghc-x-xx</literal> (on the branch). eg. 4.06 is
582 called <literal>ghc-4-06</literal>.</para>
586 <para>We didn't always follow these guidelines, so to see
587 what tags there are for previous versions, do <literal>cvs
588 log</literal> on a file that's been around for a while (like
589 <literal>fptools/ghc/README</literal>).</para>
593 <para>So, to check out a fresh GHC 4.06 tree you would
596 <screen>$ cvs co -r ghc-4-06 fpconfig
598 $ cvs co -r ghc-4-06 ghc libraries</screen>
601 <sect2 id="cvs-hints">
602 <title>General Hints</title>
606 <para>As a general rule: commit changes in small units,
607 preferably addressing one issue or implementing a single
608 feature. Provide a descriptive log message so that the
609 repository records exactly which changes were required to
610 implement a given feature/fix a bug. I've found this
611 <emphasis>very</emphasis> useful in the past for finding out
612 when a particular bug was introduced: you can just wind back
613 the CVS tree until the bug disappears.</para>
617 <para>Keep the sources at least *buildable* at any given
618 time. No doubt bugs will creep in, but it's quite easy to
619 ensure that any change made at least leaves the tree in a
620 buildable state. We do nightly builds of GHC to keep an eye
621 on what things work/don't work each day and how we're doing
622 in relation to previous verions. This idea is truely wrecked
623 if the compiler won't build in the first place!</para>
627 <para>To check out extra bits into an already-checked-out
628 tree, use the following procedure. Suppose you have a
629 checked-out fptools tree containing just ghc, and you want
630 to add nofib to it:</para>
633 $ cvs checkout nofib</screen>
638 $ cvs update -d nofib</screen>
640 <para>(the -d flag tells update to create a new
641 directory). If you just want part of the nofib suite, you
645 $ cvs checkout nofib/spectral</screen>
647 <para>This works because <literal>nofib</literal> is a
648 module in its own right, and spectral is a subdirectory of
649 the nofib module. The path argument to checkout must always
650 start with a module name. There's no equivalent form of this
651 command using <literal>update</literal>.</para>
657 <sect1 id="projects">
658 <title>What projects are there?</title>
660 <para>The <literal>fptools</literal> suite consists of several
661 <firstterm>projects</firstterm>, most of which can be downloaded,
662 built and installed individually. Each project corresponds to a
663 subdirectory in the source tree, and if checking out from CVS then
664 each project can be checked out individually by sitting in the top
665 level of your source tree and typing <command>cvs checkout
666 <replaceable>project</replaceable></command>.</para>
668 <para>Here is a list of the projects currently available:</para>
673 <literal>alex</literal>
674 <indexterm><primary><literal>alex</literal></primary><secondary>project</secondary></indexterm>
678 url="http://www.haskell.org/alex/">Alex</ulink> lexical
679 analyser generator for Haskell.</para>
685 <literal>ghc</literal>
686 <indexterm><primary><literal>ghc</literal></primary>
687 <secondary>project</secondary></indexterm>
690 <para>The <ulink url="http://www.haskell.org/ghc/">Glasgow
691 Haskell Compiler</ulink> (minus libraries). Absolutely
692 required for building GHC.</para>
698 <literal>glafp-utils</literal>
699 <indexterm><primary><literal>glafp-utils</literal></primary><secondary>project</secondary></indexterm>
702 <para>Utility programs, some of which are used by the
703 build/installation system. Required for pretty much
710 <literal>greencard</literal>
711 <indexterm><primary><literal>greencard</literal></primary><secondary>project</secondary></indexterm>
715 url="http://www.haskell.org/greencard/">GreenCard</ulink>
716 system for generating Haskell foreign function
723 <literal>haggis</literal>
724 <indexterm><primary><literal>haggis</literal></primary><secondary>project</secondary></indexterm>
728 url="http://www.dcs.gla.ac.uk/fp/software/haggis/">Haggis</ulink>
729 Haskell GUI framework.</para>
735 <literal>haddock</literal>
736 <indexterm><primary><literal>haddock</literal></primary><secondary>project</secondary></indexterm>
740 url="http://www.haskell.org/haddock/">Haddock</ulink>
741 documentation tool.</para>
747 <literal>happy</literal>
748 <indexterm><primary><literal>happy</literal></primary><secondary>project</secondary></indexterm>
752 url="http://www.haskell.org/happy/">Happy</ulink> Parser
759 <literal>hdirect</literal>
760 <indexterm><primary><literal>hdirect</literal></primary><secondary>project</secondary></indexterm>
764 url="http://www.haskell.org/hdirect/">H/Direct</ulink>
765 Haskell interoperability tool.</para>
771 <literal>hood</literal>
772 <indexterm><primary><literal>hood</literal></primary><secondary>project</secondary></indexterm>
775 <para>The <ulink url="http://www.haskell.org/hood/">Haskell
776 Object Observation Debugger</ulink>.</para>
782 <literal>hslibs</literal>
783 <indexterm><primary><literal>hslibs</literal></primary><secondary>project</secondary></indexterm>
786 <para>Old, now deprecated, libraries. Everything in here is in <literal>libraries</literal>.</para>
792 <literal>libraries</literal>
793 <indexterm><primary><literal></literal></primary><secondary>project</secondary></indexterm>
796 <para>Hierarchical Haskell library suite
797 (<emphasis>required</emphasis> for building GHC).</para>
803 <literal>mhms</literal>
804 <indexterm><primary><literal></literal></primary><secondary>project</secondary></indexterm>
807 <para>The Modular Haskell Metric System.</para>
813 <literal>nofib</literal>
814 <indexterm><primary><literal>nofib</literal></primary><secondary>project</secondary></indexterm>
817 <para>The NoFib suite: A collection of Haskell programs used
818 primarily for benchmarking.</para>
824 <literal>testsuite</literal>
825 <indexterm><primary><literal>testsuite</literal></primary><secondary>project</secondary></indexterm>
828 <para>A testing framework, including GHC's regression test
834 <para>So, to build GHC you need at least the
835 <literal>ghc</literal> and <literal>libraries</literal>
836 projects (a GHC source distribution will
837 already include the bits you need).</para>
840 <sect1 id="sec-build-checks">
841 <title>Things to check before you start</title>
843 <para>Here's a list of things to check before you get
848 <listitem><para><indexterm><primary>Disk space needed</primary></indexterm>Disk
849 space needed: from about 100Mb for a basic GHC
850 build, up to probably 500Mb for a GHC build with everything
851 included (libraries built several different ways,
856 <para>Use an appropriate machine / operating system. <xref
857 linkend="sec-port-info"/> lists the supported platforms; if
858 yours isn't amongst these then you can try porting GHC (see
859 <xref linkend="sec-porting-ghc"/>).</para>
863 <para>Be sure that the “pre-supposed” utilities are
864 installed. <xref linkend="sec-pre-supposed"/>
869 <para>If you have any problem when building or installing the
870 Glasgow tools, please check the “known pitfalls” (<xref
871 linkend="sec-build-pitfalls"/>). Also check the FAQ for the
872 version you're building, which is part of the User's Guide and
873 available on the <ulink url="http://www.haskell.org/ghc/" >GHC web
876 <indexterm><primary>bugs</primary><secondary>known</secondary></indexterm>
878 <para>If you feel there is still some shortcoming in our
879 procedure or instructions, please report it.</para>
881 <para>For GHC, please see the <ulink
882 url="http://www.haskell.org/ghc/docs/latest/set/bug-reporting.html">bug-reporting
883 section of the GHC Users' Guide</ulink>, to maximise the
884 usefulness of your report.</para>
886 <indexterm><primary>bugs</primary><secondary>seporting</secondary></indexterm>
887 <para>If in doubt, please send a message to
888 <email>glasgow-haskell-bugs@haskell.org</email>.
889 <indexterm><primary>bugs</primary><secondary>mailing
890 list</secondary></indexterm></para>
895 <sect1 id="sec-port-info">
896 <title>What machines GHC runs on</title>
898 <indexterm><primary>ports</primary><secondary>GHC</secondary></indexterm>
899 <indexterm><primary>GHC</primary><secondary>ports</secondary></indexterm>
900 <indexterm><primary>platforms</primary><secondary>supported</secondary></indexterm>
902 <para>The main question is whether or not the Haskell compiler
903 (GHC) runs on your platform.</para>
905 <para>A “platform” is a
906 architecture/manufacturer/operating-system combination, such as
907 <literal>sparc-sun-solaris2</literal>. Other common ones are
908 <literal>alpha-dec-osf2</literal>,
909 <literal>hppa1.1-hp-hpux9</literal>,
910 <literal>i386-unknown-linux</literal>,
911 <literal>i386-unknown-solaris2</literal>,
912 <literal>i386-unknown-freebsd</literal>,
913 <literal>i386-unknown-cygwin32</literal>,
914 <literal>m68k-sun-sunos4</literal>,
915 <literal>mips-sgi-irix5</literal>,
916 <literal>sparc-sun-sunos4</literal>,
917 <literal>sparc-sun-solaris2</literal>,
918 <literal>powerpc-ibm-aix</literal>.</para>
920 <para>Some libraries may only work on a limited number of
921 platforms; for example, a sockets library is of no use unless the
922 operating system supports the underlying BSDisms.</para>
925 <title>What platforms the Haskell compiler (GHC) runs on</title>
927 <indexterm><primary>fully-supported platforms</primary></indexterm>
928 <indexterm><primary>native-code generator</primary></indexterm>
929 <indexterm><primary>registerised ports</primary></indexterm>
930 <indexterm><primary>unregisterised ports</primary></indexterm>
932 <para>The GHC hierarchy of Porting Goodness: (a) Best is a
933 native-code generator; (b) next best is a
934 “registerised” port; (c) the bare minimum is an
935 “unregisterised” port.
936 (“Unregisterised” is so terrible that we won't say
937 more about it).</para>
939 <para>We use Sparcs running Solaris 2.7 and x86 boxes running
940 FreeBSD and Linux, so those are the best supported platforms,
941 unsurprisingly.</para>
943 <para>Here's everything that's known about GHC ports. We
944 identify platforms by their “canonical”
945 CPU/Manufacturer/OS triple.</para>
949 <term>alpha-dec-{osf,linux,freebsd,openbsd,netbsd}:
950 <indexterm><primary>alpha-dec-osf</primary></indexterm>
951 <indexterm><primary>alpha-dec-linux</primary></indexterm>
952 <indexterm><primary>alpha-dec-freebsd</primary></indexterm>
953 <indexterm><primary>alpha-dec-openbsd</primary></indexterm>
954 <indexterm><primary>alpha-dec-netbsd</primary></indexterm>
957 <para>The OSF port is currently working (as of GHC version
958 5.02.1) and well supported. The native code generator is
959 currently non-working. Other operating systems will
960 require some minor porting.</para>
965 <term>sparc-sun-sunos4
966 <indexterm><primary>sparc-sun-sunos4</primary></indexterm>
969 <para>Probably works with minor tweaks, hasn't been tested
975 <term>sparc-sun-solaris2
976 <indexterm><primary>sparc-sun-solaris2</primary></indexterm>
979 <para>Fully supported (at least for Solaris 2.7 and 2.6),
980 including native-code generator.</para>
985 <term>sparc-unknown-openbsd
986 <indexterm><primary>sparc-unknown-openbsd</primary></indexterm>
989 <para>Supported, including native-code generator. The
990 same should also be true of NetBSD</para>
995 <term>hppa1.1-hp-hpux (HP-PA boxes running HPUX 9.x)
996 <indexterm><primary>hppa1.1-hp-hpux</primary></indexterm>
999 <para>A registerised port is available for version 4.08,
1000 but GHC hasn't been built on that platform since (as far
1001 as we know). No native-code generator.</para>
1006 <term>i386-unknown-linux (PCs running Linux, ELF binary format)
1007 <indexterm><primary>i386-*-linux</primary></indexterm>
1010 <para>GHC works registerised and has a native code
1011 generator. You <emphasis>must</emphasis> have GCC 2.7.x
1012 or later. NOTE about <literal>glibc</literal> versions:
1013 GHC binaries built on a system running <literal>glibc
1014 2.0</literal> won't work on a system running
1015 <literal>glibc 2.1</literal>, and vice versa. In general,
1016 don't expect compatibility between
1017 <literal>glibc</literal> versions, even if the shared
1018 library version hasn't changed.</para>
1023 <term>i386-unknown-freebsd (PCs running FreeBSD 2.2 or higher)
1024 <indexterm><primary>i386-unknown-freebsd</primary></indexterm>
1027 <para>GHC works registerised. Pre-built packages are
1028 available in the native package format, so if you just
1029 need binaries you're better off just installing the
1030 package (it might even be on your installation
1036 <term>i386-unknown-openbsd (PCs running OpenBSD)
1037 <indexterm><primary>i386-unknown-openbsd</primary></indexterm>
1040 <para>Supported, with native code generator. Packages are
1041 available through the ports system in the native package
1047 <term>i386-unknown-netbsd (PCs running NetBSD)
1048 <indexterm><primary>i386-unknown-netbsd</primary></indexterm>
1051 <para>Will require some minor porting effort, but should
1052 work registerised.</para>
1057 <term>i386-unknown-mingw32 (PCs running Windows)
1058 <indexterm><primary>i386-unknown-mingw32</primary></indexterm>
1061 <para>Fully supported under Win9x, WinNT, Win2k, and
1062 WinXP. Includes a native code generator. Building from
1063 source requires a recent <ulink
1064 url="http://www.cygwin.com/">Cygwin</ulink> distribution
1065 to be installed.</para>
1070 <term>ia64-unknown-linux
1071 <indexterm><primary>ia64-unknown-linux</primary></indexterm>
1074 <para>Supported, except there is no native code
1080 <term>x86_64-unknown-linux
1081 <indexterm><primary>x86_64-unknown-linux</primary></indexterm>
1083 <term>amd64-unknown-openbsd
1084 <indexterm><primary>amd64-unknown-linux</primary></indexterm>
1087 <para>Fully supported, with a native code generator and GHCi.</para>
1092 <term>mips-sgi-irix5
1093 <indexterm><primary>mips-sgi-irix[5-6]</primary></indexterm>
1096 <para>Port has worked in the past, but hasn't been tested
1097 for some time (and will certainly have rotted in various
1098 ways). As usual, we don't have access to machines and
1099 there hasn't been an overwhelming demand for this port,
1100 but feel free to get in touch.</para>
1105 <term>mips64-sgi-irix6
1106 <indexterm><primary>mips-sgi-irix6</primary></indexterm>
1109 <para>GHC currently works unregisterised.</para>
1114 <term>powerpc-ibm-aix
1115 <indexterm><primary>powerpc-ibm-aix</primary></indexterm>
1118 <para>Port currently doesn't work, needs some minimal
1119 porting effort. As usual, we don't have access to
1120 machines and there hasn't been an overwhelming demand for
1121 this port, but feel free to get in touch.</para>
1126 <term>powerpc-apple-darwin
1127 <indexterm><primary>powerpc-apple-darwin</primary></indexterm>
1130 <para>Supported registerised. Native code generator is
1131 almost working.</para>
1136 <term>powerpc-apple-linux
1137 <indexterm><primary>powerpc-apple-linux</primary></indexterm>
1140 <para>Not supported (yet).</para>
1145 <para>Various other systems have had GHC ported to them in the
1146 distant past, including various Motorola 68k boxes. The 68k
1147 support still remains, but porting to one of these systems will
1148 certainly be a non-trivial task.</para>
1152 <sect1 id="sec-pre-supposed">
1153 <title>Installing pre-supposed utilities</title>
1155 <indexterm><primary>pre-supposed utilities</primary></indexterm>
1156 <indexterm><primary>utilities, pre-supposed</primary></indexterm>
1158 <para>Here are the gory details about some utility programs you
1159 may need; <command>perl</command>, <command>gcc</command> and
1160 <command>happy</command> are the only important
1161 ones. (PVM<indexterm><primary>PVM</primary></indexterm> is
1162 important if you're going for Parallel Haskell.) The
1163 <command>configure</command><indexterm><primary>configure</primary></indexterm>
1164 script will tell you if you are missing something.</para>
1170 <indexterm><primary>pre-supposed: GHC</primary></indexterm>
1171 <indexterm><primary>GHC, pre-supposed</primary></indexterm>
1174 <para>GHC is required to build many of the tools, including
1175 GHC itself. If you need to port GHC to your platform
1176 because there isn't a binary distribution of GHC available,
1177 then see <xref linkend="sec-porting-ghc"/>.</para>
1179 <para>Which version of GHC you need will depend on the
1180 packages you intend to build. GHC itself will normally
1181 build using one of several older versions of itself - check
1182 the announcement or release notes for details.</para>
1188 <indexterm><primary>pre-supposed: Perl</primary></indexterm>
1189 <indexterm><primary>Perl, pre-supposed</primary></indexterm>
1192 <para><emphasis>You have to have Perl to proceed!</emphasis>
1193 Perl version 5 at least is required. GHC has been known to
1194 tickle bugs in Perl, so if you find that Perl crashes when
1195 running GHC try updating (or downgrading) your Perl
1196 installation. Versions of Perl before 5.6 have been known to have
1197 various bugs tickled by GHC, so the configure script
1198 will look for version 5.6 or later.</para>
1200 <para>For Win32 platforms, you should use the binary
1201 supplied in the InstallShield (copy it to
1202 <filename>/bin</filename>). The Cygwin-supplied Perl seems
1205 <para>Perl should be put somewhere so that it can be invoked
1206 by the <literal>#!</literal> script-invoking
1207 mechanism. The full pathname may need to be less than 32
1208 characters long on some systems.</para>
1213 <term>GNU C (<command>gcc</command>)
1214 <indexterm><primary>pre-supposed: GCC (GNU C compiler)</primary></indexterm>
1215 <indexterm><primary>GCC (GNU C compiler), pre-supposed</primary></indexterm>
1218 <para>Most GCC versions should work with the most recent GHC
1219 sources. Expect trouble if you use a recent GCC with
1220 an older GHC, though (trouble in the form of mis-compiled code,
1221 link errors, and errors from the <literal>ghc-asm</literal>
1224 <para>If your GCC dies with “internal error” on
1225 some GHC source file, please let us know, so we can report
1226 it and get things improved. (Exception: on x86
1227 boxes—you may need to fiddle with GHC's
1228 <option>-monly-N-regs</option> option; see the User's
1235 <indexterm><primary>make</primary><secondary>GNU</secondary></indexterm>
1238 <para>The fptools build system makes heavy use of features
1239 specific to GNU <command>make</command>, so you must have
1240 this installed in order to build any of the fptools
1247 <indexterm><primary>Happy</primary></indexterm>
1250 <para>Happy is a parser generator tool for Haskell, and is
1251 used to generate GHC's parsers.</para>
1253 <para>If you start from a source tarball of GHC (i.e. not a CVS
1254 checkout), then you don't need Happy, because we supply the
1255 pre-processed versions of the Happy parsers. If you intend to
1256 modify the compiler and/or you're using a CVS checkout, then you
1259 <para>Happy version 1.15 is currently required to build GHC.</para>
1261 <para>Happy is written in
1262 Haskell, and is a project in the CVS repository
1263 (<literal>fptools/happy</literal>). It can be built from
1264 source, but bear in mind that you'll need GHC installed in
1265 order to build it. To avoid the chicken/egg problem,
1266 install a binary distribution of either Happy or GHC to get
1267 started. Happy distributions are available from <ulink url="http://www.haskell.org/happy/">Happy's Web
1268 Page</ulink>.</para>
1274 <indexterm><primary>Alex</primary></indexterm>
1277 <para>Alex is a lexical-analyser generator for Haskell,
1278 which GHC uses to generate its lexer.</para>
1280 <para>Like Happy, you don't need Alex if you're building GHC from a
1281 source tarball, but you do need it if you're modifying GHC and/or
1282 building a CVS checkout.</para>
1285 written in Haskell and is a project in the CVS repository.
1286 Alex distributions are available from <ulink url="http://www.haskell.org/alex/">Alex's Web
1287 Page</ulink>.</para>
1293 <indexterm><primary>pre-supposed: autoconf</primary></indexterm>
1294 <indexterm><primary>autoconf, pre-supposed</primary></indexterm>
1297 <para>GNU autoconf is needed if you intend to build from the
1298 CVS sources, it is <emphasis>not</emphasis> needed if you
1299 just intend to build a standard source distribution.</para>
1301 <para>Version 2.52 or later of the autoconf package is required.
1302 NB. version 2.13 will no longer work, as of GHC version
1305 <para><command>autoreconf</command> (from the autoconf package)
1306 recursively builds <command>configure</command> scripts from
1307 the corresponding <filename>configure.ac</filename> and
1308 <filename>aclocal.m4</filename> files. If you modify one of
1309 the latter files, you'll need <command>autoreconf</command> to
1310 rebuild the corresponding <filename>configure</filename>.</para>
1315 <term><command>sed</command>
1316 <indexterm><primary>pre-supposed: sed</primary></indexterm>
1317 <indexterm><primary>sed, pre-supposed</primary></indexterm>
1320 <para>You need a working <command>sed</command> if you are
1321 going to build from sources. The build-configuration stuff
1322 needs it. GNU sed version 2.0.4 is no good! It has a bug
1323 in it that is tickled by the build-configuration. 2.0.5 is
1324 OK. Others are probably OK too (assuming we don't create too
1325 elaborate configure scripts.)</para>
1330 <para>One <literal>fptools</literal> project is worth a quick note
1331 at this point, because it is useful for all the others:
1332 <literal>glafp-utils</literal> contains several utilities which
1333 aren't particularly Glasgow-ish, but Occasionally Indispensable.
1334 Like <command>lndir</command> for creating symbolic link
1337 <sect2 id="pre-supposed-gph-tools">
1338 <title>Tools for building parallel GHC (GPH)</title>
1342 <term>PVM version 3:
1343 <indexterm><primary>pre-supposed: PVM3 (Parallel Virtual Machine)</primary></indexterm>
1344 <indexterm><primary>PVM3 (Parallel Virtual Machine), pre-supposed</primary></indexterm>
1347 <para>PVM is the Parallel Virtual Machine on which
1348 Parallel Haskell programs run. (You only need this if you
1349 plan to run Parallel Haskell. Concurrent Haskell, which
1350 runs concurrent threads on a uniprocessor doesn't need
1351 it.) Underneath PVM, you can have (for example) a network
1352 of workstations (slow) or a multiprocessor box
1355 <para>The current version of PVM is 3.3.11; we use 3.3.7.
1356 It is readily available on the net; I think I got it from
1357 <literal>research.att.com</literal>, in
1358 <filename>netlib</filename>.</para>
1360 <para>A PVM installation is slightly quirky, but easy to
1361 do. Just follow the <filename>Readme</filename>
1362 instructions.</para>
1367 <term><command>bash</command>:
1368 <indexterm><primary>bash, presupposed (Parallel Haskell only)</primary></indexterm>
1371 <para>Sadly, the <command>gr2ps</command> script, used to
1372 convert “parallelism profiles” to PostScript,
1373 is written in Bash (GNU's Bourne Again shell). This bug
1374 will be fixed (someday).</para>
1380 <sect2 id="pre-supposed-other-tools">
1381 <title>Other useful tools</title>
1386 <indexterm><primary>pre-supposed: flex</primary></indexterm>
1387 <indexterm><primary>flex, pre-supposed</primary></indexterm>
1390 <para>This is a quite-a-bit-better-than-Lex lexer. Used
1391 to build a couple of utilities in
1392 <literal>glafp-utils</literal>. Depending on your
1393 operating system, the supplied <command>lex</command> may
1394 or may not work; you should get the GNU version.</para>
1399 <para>More tools are required if you want to format the documentation
1400 that comes with GHC and other fptools projects. See <xref
1401 linkend="building-docs"/>.</para>
1405 <sect1 id="sec-building-from-source">
1406 <title>Building from source</title>
1408 <indexterm><primary>Building from source</primary></indexterm>
1409 <indexterm><primary>Source, building from</primary></indexterm>
1411 <para>“I just want to build it!”</para>
1413 <para>No problem. This recipe should build and install a working GHC with
1414 all the default settings. (unless you're
1415 on Windows, in which case go to <xref linkend="winbuild" />).</para>
1417 <screen>$ autoreconf<footnote><para>not necessary if you started from a source tarball</para>
1421 $ make install</screen>
1423 <para>For GHC, this will do a 2-stage bootstrap build of the
1424 compiler, with profiling libraries, and install the
1425 results in the default location (under <filename>/usr/local</filename> on
1426 Unix, for example).</para>
1428 <para>The <literal>configure</literal> script is a standard GNU
1429 <literal>autoconf</literal> script, and accepts the usual options for
1430 changing install locations and the like. Run
1431 <literal>./configure --help</literal> for a list of options.</para>
1433 <para>If you want to do anything at all non-standard, or you
1434 want to do some development, read on...</para>
1437 <sect1 id="quick-start">
1438 <title>Quick start for GHC developers</title>
1440 <para>This section is a copy of the file
1441 <literal>ghc/HACKING</literal> from the GHC source tree. It describes
1442 how to get started with setting up your build tree for developing GHC
1443 or its libraries, and how to start building.</para>
1450 <sect1 id="sec-working-with-the-build-system">
1451 <title>Working with the build system</title>
1453 <para>This rest of this guide is intended for duffers like me, who
1454 aren't really interested in Makefiles and systems configurations,
1455 but who need a mental model of the interlocking pieces so that
1456 they can make them work, extend them consistently when adding new
1457 software, and lay hands on them gently when they don't
1460 <sect2 id="sec-source-tree">
1461 <title>Your source tree</title>
1463 <para>The source code is held in your <emphasis>source
1464 tree</emphasis>. The root directory of your source tree
1465 <emphasis>must</emphasis> contain the following directories and
1470 <para><filename>Makefile</filename>: the root
1475 <para><filename>mk/</filename>: the directory that contains
1476 the main Makefile code, shared by all the
1477 <literal>fptools</literal> software.</para>
1481 <para><filename>configure.ac</filename>,
1482 <filename>config.sub</filename>,
1483 <filename>config.guess</filename>: these files support the
1484 configuration process.</para>
1488 <para><filename>install-sh</filename>.</para>
1492 <para>All the other directories are individual
1493 <emphasis>projects</emphasis> of the <literal>fptools</literal>
1494 system—for example, the Glasgow Haskell Compiler
1495 (<literal>ghc</literal>), the Happy parser generator
1496 (<literal>happy</literal>), the <literal>nofib</literal>
1497 benchmark suite, and so on. You can have zero or more of these.
1498 Needless to say, some of them are needed to build others.</para>
1500 <para>The important thing to remember is that even if you want
1501 only one project (<literal>happy</literal>, say), you must have
1502 a source tree whose root directory contains
1503 <filename>Makefile</filename>, <filename>mk/</filename>,
1504 <filename>configure.ac</filename>, and the project(s) you want
1505 (<filename>happy/</filename> in this case). You cannot get by
1506 with just the <filename>happy/</filename> directory.</para>
1510 <title>Build trees</title>
1511 <indexterm><primary>build trees</primary></indexterm>
1512 <indexterm><primary>link trees, for building</primary></indexterm>
1514 <para>If you just want to build the software once on a single
1515 platform, then your source tree can also be your build tree, and
1516 you can skip the rest of this section.</para>
1518 <para>We often want to build multiple versions of our software
1519 for different architectures, or with different options
1520 (e.g. profiling). It's very desirable to share a single copy of
1521 the source code among all these builds.</para>
1523 <para>So for every source tree we have zero or more
1524 <emphasis>build trees</emphasis>. Each build tree is initially
1525 an exact copy of the source tree, except that each file is a
1526 symbolic link to the source file, rather than being a copy of
1527 the source file. There are “standard” Unix
1528 utilities that make such copies, so standard that they go by
1530 <command>lndir</command><indexterm><primary>lndir</primary></indexterm>,
1531 <command>mkshadowdir</command><indexterm><primary>mkshadowdir</primary></indexterm>
1532 are two (If you don't have either, the source distribution
1533 includes sources for the X11
1534 <command>lndir</command>—check out
1535 <filename>fptools/glafp-utils/lndir</filename>). See <xref
1536 linkend="sec-storysofar"/> for a typical invocation.</para>
1538 <para>The build tree does not need to be anywhere near the
1539 source tree in the file system. Indeed, one advantage of
1540 separating the build tree from the source is that the build tree
1541 can be placed in a non-backed-up partition, saving your systems
1542 support people from backing up untold megabytes of
1543 easily-regenerated, and rapidly-changing, gubbins. The golden
1544 rule is that (with a single exception—<xref
1545 linkend="sec-build-config"/>) <emphasis>absolutely everything in
1546 the build tree is either a symbolic link to the source tree, or
1547 else is mechanically generated</emphasis>. It should be
1548 perfectly OK for your build tree to vanish overnight; an hour or
1549 two compiling and you're on the road again.</para>
1551 <para>You need to be a bit careful, though, that any new files
1552 you create (if you do any development work) are in the source
1553 tree, not a build tree!</para>
1555 <para>Remember, that the source files in the build tree are
1556 <emphasis>symbolic links</emphasis> to the files in the source
1557 tree. (The build tree soon accumulates lots of built files like
1558 <filename>Foo.o</filename>, as well.) You can
1559 <emphasis>delete</emphasis> a source file from the build tree
1560 without affecting the source tree (though it's an odd thing to
1561 do). On the other hand, if you <emphasis>edit</emphasis> a
1562 source file from the build tree, you'll edit the source-tree
1563 file directly. (You can set up Emacs so that if you edit a
1564 source file from the build tree, Emacs will silently create an
1565 edited copy of the source file in the build tree, leaving the
1566 source file unchanged; but the danger is that you think you've
1567 edited the source file whereas actually all you've done is edit
1568 the build-tree copy. More commonly you do want to edit the
1569 source file.)</para>
1571 <para>Like the source tree, the top level of your build tree
1572 must be (a linked copy of) the root directory of the
1573 <literal>fptools</literal> suite. Inside Makefiles, the root of
1574 your build tree is called
1575 <constant>$(FPTOOLS_TOP)</constant><indexterm><primary>FPTOOLS_TOP</primary></indexterm>.
1576 In the rest of this document path names are relative to
1577 <constant>$(FPTOOLS_TOP)</constant> unless
1578 otherwise stated. For example, the file
1579 <filename>ghc/mk/target.mk</filename> is actually
1580 <filename>$(FPTOOLS_TOP)/ghc/mk/target.mk</filename>.</para>
1583 <sect2 id="sec-build-config">
1584 <title>Getting the build you want</title>
1586 <para>When you build <literal>fptools</literal> you will be
1587 compiling code on a particular <emphasis>host
1588 platform</emphasis>, to run on a particular <emphasis>target
1589 platform</emphasis> (usually the same as the host
1590 platform)<indexterm><primary>platform</primary></indexterm>.
1591 The difficulty is that there are minor differences between
1592 different platforms; minor, but enough that the code needs to be
1593 a bit different for each. There are some big differences too:
1594 for a different architecture we need to build GHC with a
1595 different native-code generator.</para>
1597 <para>There are also knobs you can turn to control how the
1598 <literal>fptools</literal> software is built. For example, you
1599 might want to build GHC optimised (so that it runs fast) or
1600 unoptimised (so that you can compile it fast after you've
1601 modified it. Or, you might want to compile it with debugging on
1602 (so that extra consistency-checking code gets included) or off.
1605 <para>All of this stuff is called the
1606 <emphasis>configuration</emphasis> of your build. You set the
1607 configuration using a three-step process.</para>
1611 <term>Step 1: get ready for configuration.</term>
1613 <para>NOTE: if you're starting from a source distribution,
1614 rather than CVS sources, you can skip this step.</para>
1616 <para>Change directory to
1617 <constant>$(FPTOOLS_TOP)</constant> and
1618 issue the command</para>
1619 <screen>$ autoreconf</screen>
1620 <indexterm><primary>autoreconf</primary></indexterm>
1621 <para>(with no arguments). This GNU program (recursively) converts
1622 <filename>$(FPTOOLS_TOP)/configure.ac</filename> and
1623 <filename>$(FPTOOLS_TOP)/aclocal.m4</filename>
1624 to a shell script called
1625 <filename>$(FPTOOLS_TOP)/configure</filename>.
1626 If <command>autoreconf</command> bleats that it can't write the file <filename>configure</filename>,
1627 then delete the latter and try again. Note that you must use <command>autoreconf</command>,
1628 and not the old <command>autoconf</command>! If you erroneously use the latter, you'll get
1629 a message like "No rule to make target 'mk/config.h.in'".
1632 <para>Some projects, including GHC, have their own configure script.
1633 <command>autoreconf</command> takes care of that, too, so all you have
1634 to do is calling <command>autoreconf</command> in the top-level directory
1635 <filename>$(FPTOOLS_TOP)</filename>.</para>
1637 <para>These steps are completely platform-independent; they just mean
1638 that the human-written files (<filename>configure.ac</filename> and
1639 <filename>aclocal.m4</filename>) can be short, although the resulting
1640 files (the <command>configure</command> shell scripts and the C header
1641 template <filename>mk/config.h.in</filename>) are long.</para>
1646 <term>Step 2: system configuration.</term>
1648 <para>Runs the newly-created <command>configure</command>
1649 script, thus:</para>
1651 <screen>$ ./configure <optional><parameter>args</parameter></optional></screen>
1653 <para><command>configure</command>'s mission is to scurry
1654 round your computer working out what architecture it has,
1655 what operating system, whether it has the
1656 <function>vfork</function> system call, where
1657 <command>tar</command> is kept, whether
1658 <command>gcc</command> is available, where various obscure
1659 <literal>#include</literal> files are, whether it's a
1660 leap year, and what the systems manager had for lunch. It
1661 communicates these snippets of information in two
1668 <filename>mk/config.mk.in</filename><indexterm><primary>config.mk.in</primary></indexterm>
1670 <filename>mk/config.mk</filename><indexterm><primary>config.mk</primary></indexterm>,
1671 substituting for things between
1672 “<literal>@</literal>” brackets. So,
1673 “<literal>@HaveGcc@</literal>” will be
1674 replaced by “<literal>YES</literal>” or
1675 “<literal>NO</literal>” depending on what
1676 <command>configure</command> finds.
1677 <filename>mk/config.mk</filename> is included by every
1678 Makefile (directly or indirectly), so the
1679 configuration information is thereby communicated to
1680 all Makefiles.</para>
1684 <para> It translates
1685 <filename>mk/config.h.in</filename><indexterm><primary>config.h.in</primary></indexterm>
1687 <filename>mk/config.h</filename><indexterm><primary>config.h</primary></indexterm>.
1688 The latter is <literal>#include</literal>d by
1689 various C programs, which can thereby make use of
1690 configuration information.</para>
1694 <para><command>configure</command> takes some optional
1695 arguments. Use <literal>./configure --help</literal> to
1696 get a list of the available arguments. Here are some of
1697 the ones you might need:</para>
1701 <term><literal>--with-ghc=<parameter>path</parameter></literal>
1702 <indexterm><primary><literal>--with-ghc</literal></primary></indexterm>
1705 <para>Specifies the path to an installed GHC which
1706 you would like to use. This compiler will be used
1707 for compiling GHC-specific code (eg. GHC itself).
1708 This option <emphasis>cannot</emphasis> be specified
1709 using <filename>build.mk</filename> (see later),
1710 because <command>configure</command> needs to
1711 auto-detect the version of GHC you're using. The
1712 default is to look for a compiler named
1713 <literal>ghc</literal> in your path.</para>
1718 <term><literal>--with-hc=<parameter>path</parameter></literal>
1719 <indexterm><primary><literal>--with-hc</literal></primary></indexterm>
1722 <para>Specifies the path to any installed Haskell
1723 compiler. This compiler will be used for compiling
1724 generic Haskell code. The default is to use
1725 <literal>ghc</literal>.</para>
1730 <term><literal>--with-gcc=<parameter>path</parameter></literal>
1731 <indexterm><primary><literal>--with-gcc</literal></primary></indexterm>
1734 <para>Specifies the path to the installed GCC. This
1735 compiler will be used to compile all C files,
1736 <emphasis>except</emphasis> any generated by the
1737 installed Haskell compiler, which will have its own
1738 idea of which C compiler (if any) to use. The
1739 default is to use <literal>gcc</literal>.</para>
1747 <term>Step 3: build configuration.</term>
1749 <para>Next, you say how this build of
1750 <literal>fptools</literal> is to differ from the standard
1751 defaults by creating a new file
1752 <filename>mk/build.mk</filename><indexterm><primary>build.mk</primary></indexterm>
1753 <emphasis>in the build tree</emphasis>. This file is the
1754 one and only file you edit in the build tree, precisely
1755 because it says how this build differs from the source.
1756 (Just in case your build tree does die, you might want to
1757 keep a private directory of <filename>build.mk</filename>
1758 files, and use a symbolic link in each build tree to point
1759 to the appropriate one.) So
1760 <filename>mk/build.mk</filename> never exists in the
1761 source tree—you create one in each build tree from
1762 the template. We'll discuss what to put in it
1768 <para>And that's it for configuration. Simple, eh?</para>
1770 <para>What do you put in your build-specific configuration file
1771 <filename>mk/build.mk</filename>? <emphasis>For almost all
1772 purposes all you will do is put make variable definitions that
1773 override those in</emphasis>
1774 <filename>mk/config.mk.in</filename>. The whole point of
1775 <filename>mk/config.mk.in</filename>—and its derived
1776 counterpart <filename>mk/config.mk</filename>—is to define
1777 the build configuration. It is heavily commented, as you will
1778 see if you look at it. So generally, what you do is look at
1779 <filename>mk/config.mk.in</filename>, and add definitions in
1780 <filename>mk/build.mk</filename> that override any of the
1781 <filename>config.mk</filename> definitions that you want to
1782 change. (The override occurs because the main boilerplate file,
1783 <filename>mk/boilerplate.mk</filename><indexterm><primary>boilerplate.mk</primary></indexterm>,
1784 includes <filename>build.mk</filename> after
1785 <filename>config.mk</filename>.)</para>
1787 <para>For your convenience, there's a file called <filename>build.mk.sample</filename>
1788 that can serve as a starting point for your <filename>build.mk</filename>.</para>
1790 <para>For example, <filename>config.mk.in</filename> contains
1791 the definition:</para>
1793 <programlisting>GhcHcOpts=-O -Rghc-timing</programlisting>
1795 <para>The accompanying comment explains that this is the list of
1796 flags passed to GHC when building GHC itself. For doing
1797 development, it is wise to add <literal>-DDEBUG</literal>, to
1798 enable debugging code. So you would add the following to
1799 <filename>build.mk</filename>:</para>
1801 <para>or, if you prefer,</para>
1803 <programlisting>GhcHcOpts += -DDEBUG</programlisting>
1805 <para>GNU <command>make</command> allows existing definitions to
1806 have new text appended using the “<literal>+=</literal>”
1807 operator, which is quite a convenient feature.)</para>
1809 <para>If you want to remove the <literal>-O</literal> as well (a
1810 good idea when developing, because the turn-around cycle gets a
1811 lot quicker), you can just override
1812 <literal>GhcLibHcOpts</literal> altogether:</para>
1814 <programlisting>GhcHcOpts=-DDEBUG -Rghc-timing</programlisting>
1816 <para>When reading <filename>config.mk.in</filename>, remember
1817 that anything between “@...@” signs is going to be substituted
1818 by <command>configure</command> later. You
1819 <emphasis>can</emphasis> override the resulting definition if
1820 you want, but you need to be a bit surer what you are doing.
1821 For example, there's a line that says:</para>
1823 <programlisting>TAR = @TarCmd@</programlisting>
1825 <para>This defines the Make variables <constant>TAR</constant>
1826 to the pathname for a <command>tar</command> that
1827 <command>configure</command> finds somewhere. If you have your
1828 own pet <command>tar</command> you want to use instead, that's
1829 fine. Just add this line to <filename>mk/build.mk</filename>:</para>
1831 <programlisting>TAR = mytar</programlisting>
1833 <para>You do not <emphasis>have</emphasis> to have a
1834 <filename>mk/build.mk</filename> file at all; if you don't,
1835 you'll get all the default settings from
1836 <filename>mk/config.mk.in</filename>.</para>
1838 <para>You can also use <filename>build.mk</filename> to override
1839 anything that <command>configure</command> got wrong. One place
1840 where this happens often is with the definition of
1841 <constant>FPTOOLS_TOP_ABS</constant>: this
1842 variable is supposed to be the canonical path to the top of your
1843 source tree, but if your system uses an automounter then the
1844 correct directory is hard to find automatically. If you find
1845 that <command>configure</command> has got it wrong, just put the
1846 correct definition in <filename>build.mk</filename>.</para>
1850 <sect2 id="sec-storysofar">
1851 <title>The story so far</title>
1853 <para>Let's summarise the steps you need to carry to get
1854 yourself a fully-configured build tree from scratch.</para>
1858 <para> Get your source tree from somewhere (CVS repository
1859 or source distribution). Say you call the root directory
1860 <filename>myfptools</filename> (it does not have to be
1861 called <filename>fptools</filename>). Make sure that you
1862 have the essential files (see <xref
1863 linkend="sec-source-tree"/>).</para>
1868 <para>(Optional) Use <command>lndir</command> or
1869 <command>mkshadowdir</command> to create a build tree.</para>
1871 <screen>$ cd myfptools
1872 $ mkshadowdir . /scratch/joe-bloggs/myfptools-sun4</screen>
1874 <para>(N.B. <command>mkshadowdir</command>'s first argument
1875 is taken relative to its second.) You probably want to give
1876 the build tree a name that suggests its main defining
1877 characteristic (in your mind at least), in case you later
1882 <para>Change directory to the build tree. Everything is
1883 going to happen there now.</para>
1885 <screen>$ cd /scratch/joe-bloggs/myfptools-sun4</screen>
1890 <para>Prepare for system configuration:</para>
1892 <screen>$ autoreconf</screen>
1894 <para>(You can skip this step if you are starting from a
1895 source distribution, and you already have
1896 <filename>configure</filename> and
1897 <filename>mk/config.h.in</filename>.)</para>
1901 <para>Do system configuration:</para>
1903 <screen>$ ./configure</screen>
1905 <para>Don't forget to check whether you need to add any
1906 arguments to <literal>configure</literal>; for example, a
1907 common requirement is to specify which GHC to use with
1908 <option>--with-ghc=<replaceable>ghc</replaceable></option>.</para>
1912 <para>Create the file <filename>mk/build.mk</filename>,
1913 adding definitions for your desired configuration
1916 <screen>$ emacs mk/build.mk</screen>
1920 <para>You can make subsequent changes to
1921 <filename>mk/build.mk</filename> as often as you like. You do
1922 not have to run any further configuration programs to make these
1923 changes take effect. In theory you should, however, say
1924 <command>gmake clean</command>, <command>gmake all</command>,
1925 because configuration option changes could affect
1926 anything—but in practice you are likely to know what's
1931 <title>Making things</title>
1933 <para>At this point you have made yourself a fully-configured
1934 build tree, so you are ready to start building real
1937 <para>The first thing you need to know is that <emphasis>you
1938 must use GNU <command>make</command>, usually called
1939 <command>gmake</command>, not standard Unix
1940 <command>make</command></emphasis>. If you use standard Unix
1941 <command>make</command> you will get all sorts of error messages
1942 (but no damage) because the <literal>fptools</literal>
1943 <command>Makefiles</command> use GNU <command>make</command>'s
1944 facilities extensively.</para>
1946 <para>To just build the whole thing, <command>cd</command> to
1947 the top of your <literal>fptools</literal> tree and type
1948 <command>gmake</command>. This will prepare the tree and build
1949 the various projects in the correct order.</para>
1952 <sect2 id="sec-bootstrapping">
1953 <title>Bootstrapping GHC</title>
1955 <para>GHC requires a 2-stage bootstrap in order to provide
1956 full functionality, including GHCi. By a 2-stage bootstrap, we
1957 mean that the compiler is built once using the installed GHC,
1958 and then again using the compiler built in the first stage. You
1959 can also build a stage 3 compiler, but this normally isn't
1960 necessary except to verify that the stage 2 compiler is working
1963 <para>Note that when doing a bootstrap, the stage 1 compiler
1964 must be built, followed by the runtime system and libraries, and
1965 then the stage 2 compiler. The correct ordering is implemented
1966 by the top-level fptools <filename>Makefile</filename>, so if
1967 you want everything to work automatically it's best to start
1968 <command>make</command> from the top of the tree. When building
1969 GHC, the top-level fptools <filename>Makefile</filename> is set
1970 up to do a 2-stage bootstrap by default (when you say
1971 <command>make</command>). Some other targets it supports
1978 <para>Build everything as normal, including the stage 1
1986 <para>Build the stage 2 compiler only.</para>
1993 <para>Build the stage 3 compiler only.</para>
1998 <term>bootstrap</term> <term>bootstrap2</term>
2000 <para>Build stage 1 followed by stage 2.</para>
2005 <term>bootstrap3</term>
2007 <para>Build stages 1, 2 and 3.</para>
2012 <term>install</term>
2014 <para>Install everything, including the compiler built in
2015 stage 2. To override the stage, say <literal>make install
2016 stage=<replaceable>n</replaceable></literal> where
2017 <replaceable>n</replaceable> is the stage to install.</para>
2022 <para>The top-level <filename>Makefile</filename> also arranges
2023 to do the appropriate <literal>make boot</literal> steps (see
2024 below) before actually building anything.</para>
2026 <para>The <literal>stage1</literal>, <literal>stage2</literal>
2027 and <literal>stage3</literal> targets also work in the
2028 <literal>ghc/compiler</literal> directory, but don't forget that
2029 each stage requires its own <literal>make boot</literal> step:
2030 for example, you must do</para>
2032 <screen>$ make boot stage=2</screen>
2034 <para>before <literal>make stage2</literal> in
2035 <literal>ghc/compiler</literal>.</para>
2038 <sect2 id="sec-standard-targets">
2039 <title>Standard Targets</title>
2040 <indexterm><primary>targets, standard makefile</primary></indexterm>
2041 <indexterm><primary>makefile targets</primary></indexterm>
2043 <para>In any directory you should be able to make the following:</para>
2047 <term><literal>boot</literal></term>
2049 <para>does the one-off preparation required to get ready
2050 for the real work. Notably, it does <command>gmake
2051 depend</command> in all directories that contain programs.
2052 It also builds the necessary tools for compilation to
2055 <para>Invoking the <literal>boot</literal> target
2056 explicitly is not normally necessary. From the top-level
2057 <literal>fptools</literal> directory, invoking
2058 <literal>gmake</literal> causes <literal>gmake boot
2059 all</literal> to be invoked in each of the project
2060 subdirectories, in the order specified by
2061 <literal>$(AllTargets)</literal> in
2062 <literal>config.mk</literal>.</para>
2064 <para>If you're working in a subdirectory somewhere and
2065 need to update the dependencies, <literal>gmake
2066 boot</literal> is a good way to do it.</para>
2071 <term><literal>all</literal></term>
2073 <para>makes all the final target(s) for this Makefile.
2074 Depending on which directory you are in a “final
2075 target” may be an executable program, a library
2076 archive, a shell script, or a Postscript file. Typing
2077 <command>gmake</command> alone is generally the same as
2078 typing <command>gmake all</command>.</para>
2083 <term><literal>install</literal></term>
2085 <para>installs the things built by <literal>all</literal>
2086 (except for the documentation). Where does it install
2087 them? That is specified by
2088 <filename>mk/config.mk.in</filename>; you can override it
2089 in <filename>mk/build.mk</filename>, or by running
2090 <command>configure</command> with command-line arguments
2091 like <literal>--bindir=/home/simonpj/bin</literal>; see
2092 <literal>./configure --help</literal> for the full
2098 <term><literal>install-docs</literal></term>
2100 <para>installs the documentation. Otherwise behaves just
2101 like <literal>install</literal>.</para>
2106 <term><literal>uninstall</literal></term>
2108 <para>reverses the effect of
2109 <literal>install</literal>.</para>
2114 <term><literal>clean</literal></term>
2116 <para>Delete all files from the current directory that are
2117 normally created by building the program. Don't delete
2118 the files that record the configuration, or files
2119 generated by <command>gmake boot</command>. Also preserve
2120 files that could be made by building, but normally aren't
2121 because the distribution comes with them.</para>
2126 <term><literal>distclean</literal></term>
2128 <para>Delete all files from the current directory that are
2129 created by configuring or building the program. If you
2130 have unpacked the source and built the program without
2131 creating any other files, <literal>make
2132 distclean</literal> should leave only the files that were
2133 in the distribution.</para>
2138 <term><literal>mostlyclean</literal></term>
2140 <para>Like <literal>clean</literal>, but may refrain from
2141 deleting a few files that people normally don't want to
2147 <term><literal>maintainer-clean</literal></term>
2149 <para>Delete everything from the current directory that
2150 can be reconstructed with this Makefile. This typically
2151 includes everything deleted by
2152 <literal>distclean</literal>, plus more: C source files
2153 produced by Bison, tags tables, Info files, and so
2156 <para>One exception, however: <literal>make
2157 maintainer-clean</literal> should not delete
2158 <filename>configure</filename> even if
2159 <filename>configure</filename> can be remade using a rule
2160 in the <filename>Makefile</filename>. More generally,
2161 <literal>make maintainer-clean</literal> should not delete
2162 anything that needs to exist in order to run
2163 <filename>configure</filename> and then begin to build the
2169 <term><literal>check</literal></term>
2171 <para>run the test suite.</para>
2176 <para>All of these standard targets automatically recurse into
2177 sub-directories. Certain other standard targets do not:</para>
2181 <term><literal>configure</literal></term>
2183 <para>is only available in the root directory
2184 <constant>$(FPTOOLS_TOP)</constant>; it has
2185 been discussed in <xref
2186 linkend="sec-build-config"/>.</para>
2191 <term><literal>depend</literal></term>
2193 <para>make a <filename>.depend</filename> file in each
2194 directory that needs it. This <filename>.depend</filename>
2195 file contains mechanically-generated dependency
2196 information; for example, suppose a directory contains a
2197 Haskell source module <filename>Foo.lhs</filename> which
2198 imports another module <literal>Baz</literal>. Then the
2199 generated <filename>.depend</filename> file will contain
2200 the dependency:</para>
2202 <programlisting>Foo.o : Baz.hi</programlisting>
2204 <para>which says that the object file
2205 <filename>Foo.o</filename> depends on the interface file
2206 <filename>Baz.hi</filename> generated by compiling module
2207 <literal>Baz</literal>. The <filename>.depend</filename>
2208 file is automatically included by every Makefile.</para>
2213 <term><literal>binary-dist</literal></term>
2215 <para>make a binary distribution. This is the target we
2216 use to build the binary distributions of GHC and
2222 <term><literal>dist</literal></term>
2224 <para>make a source distribution. Note that this target
2225 does “make distclean” as part of its work;
2226 don't use it if you want to keep what you've built.</para>
2231 <para>Most <filename>Makefile</filename>s have targets other
2232 than these. You can discover them by looking in the
2233 <filename>Makefile</filename> itself.</para>
2237 <title>Using a project from the build tree</title>
2239 <para>If you want to build GHC (say) and just use it direct from
2240 the build tree without doing <literal>make install</literal>
2241 first, you can run the in-place driver script:
2242 <filename>ghc/compiler/ghc-inplace</filename>.</para>
2244 <para> Do <emphasis>NOT</emphasis> use
2245 <filename>ghc/compiler/ghc</filename>, or
2246 <filename>ghc/compiler/ghc-6.xx</filename>, as these are the
2247 scripts intended for installation, and contain hard-wired paths
2248 to the installed libraries, rather than the libraries in the
2251 <para>Happy can similarly be run from the build tree, using
2252 <filename>happy/src/happy-inplace</filename>, and similarly for
2253 Alex and Haddock.</para>
2257 <title>Fast Making</title>
2259 <indexterm><primary>fastmake</primary></indexterm>
2260 <indexterm><primary>dependencies, omitting</primary></indexterm>
2261 <indexterm><primary>FAST, makefile variable</primary></indexterm>
2263 <para>Sometimes the dependencies get in the way: if you've made
2264 a small change to one file, and you're absolutely sure that it
2265 won't affect anything else, but you know that
2266 <command>make</command> is going to rebuild everything anyway,
2267 the following hack may be useful:</para>
2269 <screen>$ gmake FAST=YES</screen>
2271 <para>This tells the make system to ignore dependencies and just
2272 build what you tell it to. In other words, it's equivalent to
2273 temporarily removing the <filename>.depend</filename> file in
2274 the current directory (where <command>mkdependHS</command> and
2275 friends store their dependency information).</para>
2277 <para>A bit of history: GHC used to come with a
2278 <command>fastmake</command> script that did the above job, but
2279 GNU make provides the features we need to do it without
2280 resorting to a script. Also, we've found that fastmaking is
2281 less useful since the advent of GHC's recompilation checker (see
2282 the User's Guide section on "Separate Compilation").</para>
2286 <sect1 id="sec-makefile-arch">
2287 <title>The <filename>Makefile</filename> architecture</title>
2288 <indexterm><primary>makefile architecture</primary></indexterm>
2290 <para><command>make</command> is great if everything
2291 works—you type <command>gmake install</command> and lo! the
2292 right things get compiled and installed in the right places. Our
2293 goal is to make this happen often, but somehow it often doesn't;
2294 instead some weird error message eventually emerges from the
2295 bowels of a directory you didn't know existed.</para>
2297 <para>The purpose of this section is to give you a road-map to
2298 help you figure out what is going right and what is going
2302 <title>Debugging</title>
2304 <para>Debugging <filename>Makefile</filename>s is something of a
2305 black art, but here's a couple of tricks that we find
2306 particularly useful. The following command allows you to see
2307 the contents of any make variable in the context of the current
2308 <filename>Makefile</filename>:</para>
2310 <screen>$ make show VALUE=HS_SRCS</screen>
2312 <para>where you can replace <literal>HS_SRCS</literal> with the
2313 name of any variable you wish to see the value of.</para>
2315 <para>GNU make has a <option>-d</option> option which generates
2316 a dump of the decision procedure used to arrive at a conclusion
2317 about which files should be recompiled. Sometimes useful for
2318 tracking down problems with superfluous or missing
2319 recompilations.</para>
2323 <title>A small project</title>
2325 <para>To get started, let us look at the
2326 <filename>Makefile</filename> for an imaginary small
2327 <literal>fptools</literal> project, <literal>small</literal>.
2328 Each project in <literal>fptools</literal> has its own directory
2329 in <constant>FPTOOLS_TOP</constant>, so the
2330 <literal>small</literal> project will have its own directory
2331 <constant>FPOOLS_TOP/small/</constant>. Inside the
2332 <filename>small/</filename> directory there will be a
2333 <filename>Makefile</filename>, looking something like
2336 <indexterm><primary>Makefile, minimal</primary></indexterm>
2338 <programlisting># Makefile for fptools project "small"
2341 include $(TOP)/mk/boilerplate.mk
2343 SRCS = $(wildcard *.lhs) $(wildcard *.c)
2346 include $(TOP)/target.mk</programlisting>
2348 <para>this <filename>Makefile</filename> has three
2353 <para>The first section includes
2356 One of the most important
2357 features of GNU <command>make</command> that we use is the ability for a <filename>Makefile</filename> to
2358 include another named file, very like <command>cpp</command>'s <literal>#include</literal>
2363 a file of “boilerplate” code from the level
2364 above (which in this case will be
2365 <filename>FPTOOLS_TOP/mk/boilerplate.mk</filename><indexterm><primary>boilerplate.mk</primary></indexterm>).
2366 As its name suggests, <filename>boilerplate.mk</filename>
2367 consists of a large quantity of standard
2368 <filename>Makefile</filename> code. We discuss this
2369 boilerplate in more detail in <xref linkend="sec-boiler"/>.
2370 <indexterm><primary>include, directive in
2371 Makefiles</primary></indexterm> <indexterm><primary>Makefile
2372 inclusion</primary></indexterm></para>
2374 <para>Before the <literal>include</literal> statement, you
2375 must define the <command>make</command> variable
2376 <constant>TOP</constant><indexterm><primary>TOP</primary></indexterm>
2377 to be the directory containing the <filename>mk</filename>
2378 directory in which the <filename>boilerplate.mk</filename>
2379 file is. It is <emphasis>not</emphasis> OK to simply say</para>
2381 <programlisting>include ../mk/boilerplate.mk # NO NO NO</programlisting>
2384 <para>Why? Because the <filename>boilerplate.mk</filename>
2385 file needs to know where it is, so that it can, in turn,
2386 <literal>include</literal> other files. (Unfortunately,
2387 when an <literal>include</literal>d file does an
2388 <literal>include</literal>, the filename is treated relative
2389 to the directory in which <command>gmake</command> is being
2390 run, not the directory in which the
2391 <literal>include</literal>d sits.) In general,
2392 <emphasis>every file <filename>foo.mk</filename> assumes
2394 <filename>$(TOP)/mk/foo.mk</filename>
2395 refers to itself.</emphasis> It is up to the
2396 <filename>Makefile</filename> doing the
2397 <literal>include</literal> to ensure this is the case.</para>
2399 <para>Files intended for inclusion in other
2400 <filename>Makefile</filename>s are written to have the
2401 following property: <emphasis>after
2402 <filename>foo.mk</filename> is <literal>include</literal>d,
2403 it leaves <constant>TOP</constant> containing the same value
2404 as it had just before the <literal>include</literal>
2405 statement</emphasis>. In our example, this invariant
2406 guarantees that the <literal>include</literal> for
2407 <filename>target.mk</filename> will look in the same
2408 directory as that for <filename>boilerplate.mk</filename>.</para>
2412 <para> The second section defines the following standard
2413 <command>make</command> variables:
2414 <constant>SRCS</constant><indexterm><primary>SRCS</primary></indexterm>
2415 (the source files from which is to be built), and
2416 <constant>HS_PROG</constant><indexterm><primary>HS_PROG</primary></indexterm>
2417 (the executable binary to be built). We will discuss in
2418 more detail what the “standard variables” are,
2419 and how they affect what happens, in <xref
2420 linkend="sec-targets"/>.</para>
2422 <para>The definition for <constant>SRCS</constant> uses the
2423 useful GNU <command>make</command> construct
2424 <literal>$(wildcard $pat$)</literal><indexterm><primary>wildcard</primary></indexterm>,
2425 which expands to a list of all the files matching the
2426 pattern <literal>pat</literal> in the current directory. In
2427 this example, <constant>SRCS</constant> is set to the list
2428 of all the <filename>.lhs</filename> and
2429 <filename>.c</filename> files in the directory. (Let's
2430 suppose there is one of each, <filename>Foo.lhs</filename>
2431 and <filename>Baz.c</filename>.)</para>
2435 <para>The last section includes a second file of standard
2437 <filename>target.mk</filename><indexterm><primary>target.mk</primary></indexterm>.
2438 It contains the rules that tell <command>gmake</command> how
2439 to make the standard targets (<xref
2440 linkend="sec-standard-targets"/>). Why, you ask, can't this
2441 standard code be part of
2442 <filename>boilerplate.mk</filename>? Good question. We
2443 discuss the reason later, in <xref
2444 linkend="sec-boiler-arch"/>.</para>
2446 <para>You do not <emphasis>have</emphasis> to
2447 <literal>include</literal> the
2448 <filename>target.mk</filename> file. Instead, you can write
2449 rules of your own for all the standard targets. Usually,
2450 though, you will find quite a big payoff from using the
2451 canned rules in <filename>target.mk</filename>; the price
2452 tag is that you have to understand what canned rules get
2453 enabled, and what they do (<xref
2454 linkend="sec-targets"/>).</para>
2458 <para>In our example <filename>Makefile</filename>, most of the
2459 work is done by the two <literal>include</literal>d files. When
2460 you say <command>gmake all</command>, the following things
2465 <para><command>gmake</command> figures out that the object
2466 files are <filename>Foo.o</filename> and
2467 <filename>Baz.o</filename>.</para>
2471 <para>It uses a boilerplate pattern rule to compile
2472 <filename>Foo.lhs</filename> to <filename>Foo.o</filename>
2473 using a Haskell compiler. (Which one? That is set in the
2474 build configuration.)</para>
2478 <para>It uses another standard pattern rule to compile
2479 <filename>Baz.c</filename> to <filename>Baz.o</filename>,
2480 using a C compiler. (Ditto.)</para>
2484 <para>It links the resulting <filename>.o</filename> files
2485 together to make <literal>small</literal>, using the Haskell
2486 compiler to do the link step. (Why not use
2487 <command>ld</command>? Because the Haskell compiler knows
2488 what standard libraries to link in. How did
2489 <command>gmake</command> know to use the Haskell compiler to
2490 do the link, rather than the C compiler? Because we set the
2491 variable <constant>HS_PROG</constant> rather than
2492 <constant>C_PROG</constant>.)</para>
2496 <para>All <filename>Makefile</filename>s should follow the above
2497 three-section format.</para>
2501 <title>A larger project</title>
2503 <para>Larger projects are usually structured into a number of
2504 sub-directories, each of which has its own
2505 <filename>Makefile</filename>. (In very large projects, this
2506 sub-structure might be iterated recursively, though that is
2507 rare.) To give you the idea, here's part of the directory
2508 structure for the (rather large) GHC project:</para>
2510 <programlisting>$(FPTOOLS_TOP)/ghc/
2517 ...source files for documentation...
2520 ...source files for driver...
2523 parser/...source files for parser...
2524 renamer/...source files for renamer...
2525 ...etc...</programlisting>
2527 <para>The sub-directories <filename>docs</filename>,
2528 <filename>driver</filename>, <filename>compiler</filename>, and
2529 so on, each contains a sub-component of GHC, and each has its
2530 own <filename>Makefile</filename>. There must also be a
2531 <filename>Makefile</filename> in
2532 <filename>$(FPTOOLS_TOP)/ghc</filename>.
2533 It does most of its work by recursively invoking
2534 <command>gmake</command> on the <filename>Makefile</filename>s
2535 in the sub-directories. We say that
2536 <filename>ghc/Makefile</filename> is a <emphasis>non-leaf
2537 <filename>Makefile</filename></emphasis>, because it does little
2538 except organise its children, while the
2539 <filename>Makefile</filename>s in the sub-directories are all
2540 <emphasis>leaf <filename>Makefile</filename>s</emphasis>. (In
2541 principle the sub-directories might themselves contain a
2542 non-leaf <filename>Makefile</filename> and several
2543 sub-sub-directories, but that does not happen in GHC.)</para>
2545 <para>The <filename>Makefile</filename> in
2546 <filename>ghc/compiler</filename> is considered a leaf
2547 <filename>Makefile</filename> even though the
2548 <filename>ghc/compiler</filename> has sub-directories, because
2549 these sub-directories do not themselves have
2550 <filename>Makefile</filename>s in them. They are just used to
2551 structure the collection of modules that make up GHC, but all
2552 are managed by the single <filename>Makefile</filename> in
2553 <filename>ghc/compiler</filename>.</para>
2555 <para>You will notice that <filename>ghc/</filename> also
2556 contains a directory <filename>ghc/mk/</filename>. It contains
2557 GHC-specific <filename>Makefile</filename> boilerplate code.
2558 More precisely:</para>
2562 <para><filename>ghc/mk/boilerplate.mk</filename> is included
2563 at the top of <filename>ghc/Makefile</filename>, and of all
2564 the leaf <filename>Makefile</filename>s in the
2565 sub-directories. It in turn <literal>include</literal>s the
2566 main boilerplate file
2567 <filename>mk/boilerplate.mk</filename>.</para>
2571 <para><filename>ghc/mk/target.mk</filename> is
2572 <literal>include</literal>d at the bottom of
2573 <filename>ghc/Makefile</filename>, and of all the leaf
2574 <filename>Makefile</filename>s in the sub-directories. It
2575 in turn <literal>include</literal>s the file
2576 <filename>mk/target.mk</filename>.</para>
2580 <para>So these two files are the place to look for GHC-wide
2581 customisation of the standard boilerplate.</para>
2584 <sect2 id="sec-boiler-arch">
2585 <title>Boilerplate architecture</title>
2586 <indexterm><primary>boilerplate architecture</primary></indexterm>
2588 <para>Every <filename>Makefile</filename> includes a
2589 <filename>boilerplate.mk</filename><indexterm><primary>boilerplate.mk</primary></indexterm>
2590 file at the top, and
2591 <filename>target.mk</filename><indexterm><primary>target.mk</primary></indexterm>
2592 file at the bottom. In this section we discuss what is in these
2593 files, and why there have to be two of them. In general:</para>
2597 <para><filename>boilerplate.mk</filename> consists of:</para>
2601 <para><emphasis>Definitions of millions of
2602 <command>make</command> variables</emphasis> that
2603 collectively specify the build configuration. Examples:
2604 <constant>HC_OPTS</constant><indexterm><primary>HC_OPTS</primary></indexterm>,
2605 the options to feed to the Haskell compiler;
2606 <constant>NoFibSubDirs</constant><indexterm><primary>NoFibSubDirs</primary></indexterm>,
2607 the sub-directories to enable within the
2608 <literal>nofib</literal> project;
2609 <constant>GhcWithHc</constant><indexterm><primary>GhcWithHc</primary></indexterm>,
2610 the name of the Haskell compiler to use when compiling
2611 GHC in the <literal>ghc</literal> project.</para>
2615 <para><emphasis>Standard pattern rules</emphasis> that
2616 tell <command>gmake</command> how to construct one file
2617 from another.</para>
2621 <para><filename>boilerplate.mk</filename> needs to be
2622 <literal>include</literal>d at the <emphasis>top</emphasis>
2623 of each <filename>Makefile</filename>, so that the user can
2624 replace the boilerplate definitions or pattern rules by
2625 simply giving a new definition or pattern rule in the
2626 <filename>Makefile</filename>. <command>gmake</command>
2627 simply takes the last definition as the definitive one.</para>
2629 <para>Instead of <emphasis>replacing</emphasis> boilerplate
2630 definitions, it is also quite common to
2631 <emphasis>augment</emphasis> them. For example, a
2632 <filename>Makefile</filename> might say:</para>
2634 <programlisting>SRC_HC_OPTS += -O</programlisting>
2636 <para>thereby adding “<option>-O</option>” to
2638 <constant>SRC_HC_OPTS</constant><indexterm><primary>SRC_HC_OPTS</primary></indexterm>.</para>
2642 <para><filename>target.mk</filename> contains
2643 <command>make</command> rules for the standard targets
2644 described in <xref linkend="sec-standard-targets"/>. These
2645 rules are selectively included, depending on the setting of
2646 certain <command>make</command> variables. These variables
2647 are usually set in the middle section of the
2648 <filename>Makefile</filename> between the two
2649 <literal>include</literal>s.</para>
2651 <para><filename>target.mk</filename> must be included at the
2652 end (rather than being part of
2653 <filename>boilerplate.mk</filename>) for several tiresome
2659 <para><command>gmake</command> commits target and
2660 dependency lists earlier than it should. For example,
2661 <filename>target.mk</filename> has a rule that looks
2664 <programlisting>$(HS_PROG) : $(OBJS)
2665 $(HC) $(LD_OPTS) $< -o $@</programlisting>
2667 <para>If this rule was in
2668 <filename>boilerplate.mk</filename> then
2669 <constant>$(HS_PROG)</constant><indexterm><primary>HS_PROG</primary></indexterm>
2671 <constant>$(OBJS)</constant><indexterm><primary>OBJS</primary></indexterm>
2672 would not have their final values at the moment
2673 <command>gmake</command> encountered the rule. Alas,
2674 <command>gmake</command> takes a snapshot of their
2675 current values, and wires that snapshot into the rule.
2676 (In contrast, the commands executed when the rule
2677 “fires” are only substituted at the moment
2678 of firing.) So, the rule must follow the definitions
2679 given in the <filename>Makefile</filename> itself.</para>
2683 <para>Unlike pattern rules, ordinary rules cannot be
2684 overriden or replaced by subsequent rules for the same
2685 target (at least, not without an error message).
2686 Including ordinary rules in
2687 <filename>boilerplate.mk</filename> would prevent the
2688 user from writing rules for specific targets in specific
2693 <para>There are a couple of other reasons I've
2694 forgotten, but it doesn't matter too much.</para>
2701 <sect2 id="sec-boiler">
2702 <title>The main <filename>mk/boilerplate.mk</filename> file</title>
2703 <indexterm><primary>boilerplate.mk</primary></indexterm>
2705 <para>If you look at
2706 <filename>$(FPTOOLS_TOP)/mk/boilerplate.mk</filename>
2707 you will find that it consists of the following sections, each
2708 held in a separate file:</para>
2712 <term><filename>config.mk</filename>
2713 <indexterm><primary>config.mk</primary></indexterm>
2716 <para>is the build configuration file we discussed at
2717 length in <xref linkend="sec-build-config"/>.</para>
2722 <term><filename>paths.mk</filename>
2723 <indexterm><primary>paths.mk</primary></indexterm>
2726 <para>defines <command>make</command> variables for
2727 pathnames and file lists. This file contains code for
2728 automatically compiling lists of source files and deriving
2729 lists of object files from those. The results can be
2730 overriden in the <filename>Makefile</filename>, but in
2731 most cases the automatic setup should do the right
2734 <para>The following variables may be set in the
2735 <filename>Makefile</filename> to affect how the automatic
2736 source file search is done:</para>
2740 <term><literal>ALL_DIRS</literal>
2741 <indexterm><primary><literal>ALL_DIRS</literal></primary></indexterm>
2744 <para>Set to a list of directories to search in
2745 addition to the current directory for source
2751 <term><literal>EXCLUDED_SRCS</literal>
2752 <indexterm><primary><literal>EXCLUDED_SRCS</literal></primary></indexterm>
2755 <para>Set to a list of source files (relative to the
2756 current directory) to omit from the automatic
2757 search. The source searching machinery is clever
2758 enough to know that if you exclude a source file
2759 from which other sources are derived, then the
2760 derived sources should also be excluded. For
2761 example, if you set <literal>EXCLUDED_SRCS</literal>
2762 to include <filename>Foo.y</filename>, then
2763 <filename>Foo.hs</filename> will also be
2769 <term><literal>EXTRA_SRCS</literal>
2770 <indexterm><primary><literal>EXTRA_SRCS</literal></primary></indexterm>
2773 <para>Set to a list of extra source files (perhaps
2774 in directories not listed in
2775 <literal>ALL_DIRS</literal>) that should be
2781 <para>The results of the automatic source file search are
2782 placed in the following make variables:</para>
2786 <term><literal>SRCS</literal>
2787 <indexterm><primary><literal>SRCS</literal></primary></indexterm>
2790 <para>All source files found, sorted and without
2791 duplicates, including those which might not exist
2792 yet but will be derived from other existing sources.
2793 <literal>SRCS</literal> <emphasis>can</emphasis> be
2794 overriden if necessary, in which case the variables
2795 below will follow suit.</para>
2800 <term><literal>HS_SRCS</literal>
2801 <indexterm><primary><literal>HS_SRCS</literal></primary></indexterm>
2804 <para>all Haskell source files in the current
2805 directory, including those derived from other source
2806 files (eg. Happy sources also give rise to Haskell
2812 <term><literal>HS_OBJS</literal>
2813 <indexterm><primary><literal>HS_OBJS</literal></primary></indexterm>
2816 <para>Object files derived from
2817 <literal>HS_SRCS</literal>.</para>
2822 <term><literal>HS_IFACES</literal>
2823 <indexterm><primary><literal>HS_IFACES</literal></primary></indexterm>
2826 <para>Interface files (<literal>.hi</literal> files)
2827 derived from <literal>HS_SRCS</literal>.</para>
2832 <term><literal>C_SRCS</literal>
2833 <indexterm><primary><literal>C_SRCS</literal></primary></indexterm>
2836 <para>All C source files found.</para>
2841 <term><literal>C_OBJS</literal>
2842 <indexterm><primary><literal>C_OBJS</literal></primary></indexterm>
2845 <para>Object files derived from
2846 <literal>C_SRCS</literal>.</para>
2851 <term><literal>SCRIPT_SRCS</literal>
2852 <indexterm><primary><literal>SCRIPT_SRCS</literal></primary></indexterm>
2855 <para>All script source files found
2856 (<literal>.lprl</literal> files).</para>
2861 <term><literal>SCRIPT_OBJS</literal>
2862 <indexterm><primary><literal>SCRIPT_OBJS</literal></primary></indexterm>
2865 <para><quote>object</quote> files derived from
2866 <literal>SCRIPT_SRCS</literal>
2867 (<literal>.prl</literal> files).</para>
2872 <term><literal>HSC_SRCS</literal>
2873 <indexterm><primary><literal>HSC_SRCS</literal></primary></indexterm>
2876 <para>All <literal>hsc2hs</literal> source files
2877 (<literal>.hsc</literal> files).</para>
2882 <term><literal>HAPPY_SRCS</literal>
2883 <indexterm><primary><literal>HAPPY_SRCS</literal></primary></indexterm>
2886 <para>All <literal>happy</literal> source files
2887 (<literal>.y</literal> or <literal>.hy</literal> files).</para>
2892 <term><literal>OBJS</literal>
2893 <indexterm><primary>OBJS</primary></indexterm>
2896 <para>the concatenation of
2897 <literal>$(HS_OBJS)</literal>,
2898 <literal>$(C_OBJS)</literal>, and
2899 <literal>$(SCRIPT_OBJS)</literal>.</para>
2904 <para>Any or all of these definitions can easily be
2905 overriden by giving new definitions in your
2906 <filename>Makefile</filename>.</para>
2908 <para>What, exactly, does <filename>paths.mk</filename>
2909 consider a <quote>source file</quote> to be? It's based
2910 on the file's suffix (e.g. <filename>.hs</filename>,
2911 <filename>.lhs</filename>, <filename>.c</filename>,
2912 <filename>.hy</filename>, etc), but this is the kind of
2913 detail that changes, so rather than enumerate the source
2914 suffices here the best thing to do is to look in
2915 <filename>paths.mk</filename>.</para>
2920 <term><filename>opts.mk</filename>
2921 <indexterm><primary>opts.mk</primary></indexterm>
2924 <para>defines <command>make</command> variables for option
2925 strings to pass to each program. For example, it defines
2926 <constant>HC_OPTS</constant><indexterm><primary>HC_OPTS</primary></indexterm>,
2927 the option strings to pass to the Haskell compiler. See
2928 <xref linkend="sec-suffix"/>.</para>
2933 <term><filename>suffix.mk</filename>
2934 <indexterm><primary>suffix.mk</primary></indexterm>
2937 <para>defines standard pattern rules—see <xref
2938 linkend="sec-suffix"/>.</para>
2943 <para>Any of the variables and pattern rules defined by the
2944 boilerplate file can easily be overridden in any particular
2945 <filename>Makefile</filename>, because the boilerplate
2946 <literal>include</literal> comes first. Definitions after this
2947 <literal>include</literal> directive simply override the default
2948 ones in <filename>boilerplate.mk</filename>.</para>
2951 <sect2 id="sec-platforms">
2952 <title>Platform settings</title>
2953 <indexterm><primary>Platform settings</primary>
2956 <para>There are three platforms of interest when building GHC:</para>
2960 <term>The <emphasis>build</emphasis> platform</term>
2962 <para>The platform on which we are doing this build.</para>
2967 <term>The <emphasis>host</emphasis> platform</term>
2969 <para>The platform on which these binaries will run.</para>
2974 <term>The <emphasis>target</emphasis> platform</term>
2976 <para>The platform for which this compiler will generate code.</para>
2981 <para>These platforms are set when running the
2982 <literal>configure</literal> script, using the
2983 <option>--build</option>, <option>--host</option>, and
2984 <option>--target</option> options. The <filename>mk/config.mk</filename>
2985 file defines several symbols related to the platform settings (see
2986 <filename>mk/config.mk</filename> for details).</para>
2988 <para>We don't currently support build & host being different, because
2989 the build process creates binaries that are both run during the build,
2990 and also installed.</para>
2992 <para>If host and target are different, then we are building a
2993 cross-compiler. For GHC, this means a compiler
2994 which will generate intermediate .hc files to port to the target
2995 architecture for bootstrapping. The libraries and stage 2 compiler
2996 will be built as HC files for the target system (see <xref
2997 linkend="sec-porting-ghc" /> for details.</para>
2999 <para>More details on when to use BUILD, HOST or TARGET can be found in
3000 the comments in <filename>config.mk</filename>.</para>
3003 <sect2 id="sec-suffix">
3004 <title>Pattern rules and options</title>
3005 <indexterm><primary>Pattern rules</primary></indexterm>
3008 <filename>suffix.mk</filename><indexterm><primary>suffix.mk</primary></indexterm>
3009 defines standard <emphasis>pattern rules</emphasis> that say how
3010 to build one kind of file from another, for example, how to
3011 build a <filename>.o</filename> file from a
3012 <filename>.c</filename> file. (GNU <command>make</command>'s
3013 <emphasis>pattern rules</emphasis> are more powerful and easier
3014 to use than Unix <command>make</command>'s <emphasis>suffix
3015 rules</emphasis>.)</para>
3017 <para>Almost all the rules look something like this:</para>
3019 <programlisting>%.o : %.c
3021 $(CC) $(CC_OPTS) -c $< -o $@</programlisting>
3023 <para>Here's how to understand the rule. It says that
3024 <emphasis>something</emphasis><filename>.o</filename> (say
3025 <filename>Foo.o</filename>) can be built from
3026 <emphasis>something</emphasis><filename>.c</filename>
3027 (<filename>Foo.c</filename>), by invoking the C compiler (path
3028 name held in <constant>$(CC)</constant>), passing to it
3029 the options <constant>$(CC_OPTS)</constant> and
3030 the rule's dependent file of the rule
3031 <literal>$<</literal> (<filename>Foo.c</filename> in
3032 this case), and putting the result in the rule's target
3033 <literal>$@</literal> (<filename>Foo.o</filename> in this
3036 <para>Every program is held in a <command>make</command>
3037 variable defined in <filename>mk/config.mk</filename>—look
3038 in <filename>mk/config.mk</filename> for the complete list. One
3039 important one is the Haskell compiler, which is called
3040 <constant>$(HC)</constant>.</para>
3042 <para>Every program's options are are held in a
3043 <command>make</command> variables called
3044 <constant><prog>_OPTS</constant>. the
3045 <constant><prog>_OPTS</constant> variables are
3046 defined in <filename>mk/opts.mk</filename>. Almost all of them
3047 are defined like this:</para>
3049 <programlisting>CC_OPTS = \
3050 $(SRC_CC_OPTS) $(WAY$(_way)_CC_OPTS) $($*_CC_OPTS) $(EXTRA_CC_OPTS)</programlisting>
3052 <para>The four variables from which
3053 <constant>CC_OPTS</constant> is built have the following
3058 <term><constant>SRC_CC_OPTS</constant><indexterm><primary>SRC_CC_OPTS</primary></indexterm>:</term>
3060 <para>options passed to all C compilations.</para>
3065 <term><constant>WAY_<way>_CC_OPTS</constant>:</term>
3067 <para>options passed to C compilations for way
3068 <literal><way></literal>. For example,
3069 <constant>WAY_mp_CC_OPTS</constant>
3070 gives options to pass to the C compiler when compiling way
3071 <literal>mp</literal>. The variable
3072 <constant>WAY_CC_OPTS</constant> holds
3073 options to pass to the C compiler when compiling the
3074 standard way. (<xref linkend="sec-ways"/> dicusses
3075 multi-way compilation.)</para>
3080 <term><constant><module>_CC_OPTS</constant>:</term>
3082 <para>options to pass to the C compiler that are specific
3083 to module <literal><module></literal>. For example,
3084 <constant>SMap_CC_OPTS</constant> gives the
3085 specific options to pass to the C compiler when compiling
3086 <filename>SMap.c</filename>.</para>
3091 <term><constant>EXTRA_CC_OPTS</constant><indexterm><primary>EXTRA_CC_OPTS</primary></indexterm>:</term>
3093 <para>extra options to pass to all C compilations. This
3094 is intended for command line use, thus:</para>
3096 <screen>$ gmake libHS.a EXTRA_CC_OPTS="-v"</screen>
3102 <sect2 id="sec-targets">
3103 <title>The main <filename>mk/target.mk</filename> file</title>
3104 <indexterm><primary>target.mk</primary></indexterm>
3106 <para><filename>target.mk</filename> contains canned rules for
3107 all the standard targets described in <xref
3108 linkend="sec-standard-targets"/>. It is complicated by the fact
3109 that you don't want all of these rules to be active in every
3110 <filename>Makefile</filename>. Rather than have a plethora of
3111 tiny files which you can include selectively, there is a single
3112 file, <filename>target.mk</filename>, which selectively includes
3113 rules based on whether you have defined certain variables in
3114 your <filename>Makefile</filename>. This section explains what
3115 rules you get, what variables control them, and what the rules
3116 do. Hopefully, you will also get enough of an idea of what is
3117 supposed to happen that you can read and understand any weird
3118 special cases yourself.</para>
3122 <term><constant>HS_PROG</constant><indexterm><primary>HS_PROG</primary></indexterm>.</term>
3124 <para>If <constant>HS_PROG</constant> is defined,
3125 you get rules with the following targets:</para>
3129 <term><filename>HS_PROG</filename><indexterm><primary>HS_PROG</primary></indexterm></term>
3131 <para>itself. This rule links
3132 <constant>$(OBJS)</constant> with the Haskell
3133 runtime system to get an executable called
3134 <constant>$(HS_PROG)</constant>.</para>
3139 <term><literal>install</literal><indexterm><primary>install</primary></indexterm></term>
3142 <constant>$(HS_PROG)</constant> in
3143 <constant>$(bindir)</constant>.</para>
3152 <term><constant>C_PROG</constant><indexterm><primary>C_PROG</primary></indexterm></term>
3154 <para>is similar to <constant>HS_PROG</constant>,
3155 except that the link step links
3156 <constant>$(C_OBJS)</constant> with the C
3157 runtime system.</para>
3162 <term><constant>LIBRARY</constant><indexterm><primary>LIBRARY</primary></indexterm></term>
3164 <para>is similar to <constant>HS_PROG</constant>,
3165 except that it links
3166 <constant>$(LIB_OBJS)</constant> to make the
3167 library archive <constant>$(LIBRARY)</constant>,
3168 and <literal>install</literal> installs it in
3169 <constant>$(libdir)</constant>.</para>
3174 <term><constant>LIB_DATA</constant><indexterm><primary>LIB_DATA</primary></indexterm></term>
3176 <para>…</para>
3181 <term><constant>LIB_EXEC</constant><indexterm><primary>LIB_EXEC</primary></indexterm></term>
3183 <para>…</para>
3188 <term><constant>HS_SRCS</constant><indexterm><primary>HS_SRCS</primary></indexterm>, <constant>C_SRCS</constant><indexterm><primary>C_SRCS</primary></indexterm>.</term>
3190 <para>If <constant>HS_SRCS</constant> is defined
3191 and non-empty, a rule for the target
3192 <literal>depend</literal> is included, which generates
3193 dependency information for Haskell programs. Similarly
3194 for <constant>C_SRCS</constant>.</para>
3199 <para>All of these rules are “double-colon” rules,
3202 <programlisting>install :: $(HS_PROG)
3203 ...how to install it...</programlisting>
3205 <para>GNU <command>make</command> treats double-colon rules as
3206 separate entities. If there are several double-colon rules for
3207 the same target it takes each in turn and fires it if its
3208 dependencies say to do so. This means that you can, for
3209 example, define both <constant>HS_PROG</constant> and
3210 <constant>LIBRARY</constant>, which will generate two rules for
3211 <literal>install</literal>. When you type <command>gmake
3212 install</command> both rules will be fired, and both the program
3213 and the library will be installed, just as you wanted.</para>
3216 <sect2 id="sec-subdirs">
3217 <title>Recursion</title>
3218 <indexterm><primary>recursion, in makefiles</primary></indexterm>
3219 <indexterm><primary>Makefile, recursing into subdirectories</primary></indexterm>
3221 <para>In leaf <filename>Makefile</filename>s the variable
3222 <constant>SUBDIRS</constant><indexterm><primary>SUBDIRS</primary></indexterm>
3223 is undefined. In non-leaf <filename>Makefile</filename>s,
3224 <constant>SUBDIRS</constant> is set to the list of
3225 sub-directories that contain subordinate
3226 <filename>Makefile</filename>s. <emphasis>It is up to you to
3227 set <constant>SUBDIRS</constant> in the
3228 <filename>Makefile</filename>.</emphasis> There is no automation
3229 here—<constant>SUBDIRS</constant> is too important to
3232 <para>When <constant>SUBDIRS</constant> is defined,
3233 <filename>target.mk</filename> includes a rather neat rule for
3234 the standard targets (<xref linkend="sec-standard-targets"/> that
3235 simply invokes <command>make</command> recursively in each of
3236 the sub-directories.</para>
3238 <para><emphasis>These recursive invocations are guaranteed to
3239 occur in the order in which the list of directories is specified
3240 in <constant>SUBDIRS</constant>. </emphasis>This guarantee can
3241 be important. For example, when you say <command>gmake
3242 boot</command> it can be important that the recursive invocation
3243 of <command>make boot</command> is done in one sub-directory
3244 (the include files, say) before another (the source files).
3245 Generally, put the most independent sub-directory first, and the
3246 most dependent last.</para>
3249 <sect2 id="sec-ways">
3250 <title>Way management</title>
3251 <indexterm><primary>way management</primary></indexterm>
3253 <para>We sometimes want to build essentially the same system in
3254 several different “ways”. For example, we want to build GHC's
3255 <literal>Prelude</literal> libraries with and without profiling,
3256 so that there is an appropriately-built library archive to link
3257 with when the user compiles his program. It would be possible
3258 to have a completely separate build tree for each such “way”,
3259 but it would be horribly bureaucratic, especially since often
3260 only parts of the build tree need to be constructed in multiple
3264 <filename>target.mk</filename><indexterm><primary>target.mk</primary></indexterm>
3265 contains some clever magic to allow you to build several
3266 versions of a system; and to control locally how many versions
3267 are built and how they differ. This section explains the
3270 <para>The files for a particular way are distinguished by
3271 munging the suffix. The <quote>normal way</quote> is always
3272 built, and its files have the standard suffices
3273 <filename>.o</filename>, <filename>.hi</filename>, and so on.
3274 In addition, you can build one or more extra ways, each
3275 distinguished by a <emphasis>way tag</emphasis>. The object
3276 files and interface files for one of these extra ways are
3277 distinguished by their suffix. For example, way
3278 <literal>mp</literal> has files
3279 <filename>.mp_o</filename> and
3280 <filename>.mp_hi</filename>. Library archives have their
3281 way tag the other side of the dot, for boring reasons; thus,
3282 <filename>libHS_mp.a</filename>.</para>
3284 <para>A <command>make</command> variable called
3285 <constant>way</constant> holds the current way tag.
3286 <emphasis><constant>way</constant> is only ever set on the
3287 command line of <command>gmake</command></emphasis> (usually in
3288 a recursive invocation of <command>gmake</command> by the
3289 system). It is never set inside a
3290 <filename>Makefile</filename>. So it is a global constant for
3291 any one invocation of <command>gmake</command>. Two other
3292 <command>make</command> variables,
3293 <constant>way_</constant> and
3294 <constant>_way</constant> are immediately derived from
3295 <constant>$(way)</constant> and never altered. If
3296 <constant>way</constant> is not set, then neither are
3297 <constant>way_</constant> and
3298 <constant>_way</constant>, and the invocation of
3299 <command>make</command> will build the <quote>normal
3300 way</quote>. If <constant>way</constant> is set, then the other
3301 two variables are set in sympathy. For example, if
3302 <constant>$(way)</constant> is “<literal>mp</literal>”,
3303 then <constant>way_</constant> is set to
3304 “<literal>mp_</literal>” and
3305 <constant>_way</constant> is set to
3306 “<literal>_mp</literal>”. These three variables are
3307 then used when constructing file names.</para>
3309 <para>So how does <command>make</command> ever get recursively
3310 invoked with <constant>way</constant> set? There are two ways
3311 in which this happens:</para>
3315 <para>For some (but not all) of the standard targets, when
3316 in a leaf sub-directory, <command>make</command> is
3317 recursively invoked for each way tag in
3318 <constant>$(WAYS)</constant>. You set
3319 <constant>WAYS</constant> in the
3320 <filename>Makefile</filename> to the list of way tags you
3321 want these targets built for. The mechanism here is very
3322 much like the recursive invocation of
3323 <command>make</command> in sub-directories (<xref
3324 linkend="sec-subdirs"/>). It is up to you to set
3325 <constant>WAYS</constant> in your
3326 <filename>Makefile</filename>; this is how you control what
3327 ways will get built.</para>
3331 <para>For a useful collection of targets (such as
3332 <filename>libHS_mp.a</filename>,
3333 <filename>Foo.mp_o</filename>) there is a rule which
3334 recursively invokes <command>make</command> to make the
3335 specified target, setting the <constant>way</constant>
3336 variable. So if you say <command>gmake
3337 Foo.mp_o</command> you should see a recursive
3338 invocation <command>gmake Foo.mp_o way=mp</command>,
3339 and <emphasis>in this recursive invocation the pattern rule
3340 for compiling a Haskell file into a <filename>.o</filename>
3341 file will match</emphasis>. The key pattern rules (in
3342 <filename>suffix.mk</filename>) look like this:
3344 <programlisting>%.$(way_)o : %.lhs
3345 $(HC) $(HC_OPTS) $< -o $@</programlisting>
3351 <para>You can invoke <command>make</command> with a
3352 particular <literal>way</literal> setting yourself, in order
3353 to build files related to a particular
3354 <literal>way</literal> in the current directory. eg.
3356 <screen>$ make way=p</screen>
3358 will build files for the profiling way only in the current
3365 <title>When the canned rule isn't right</title>
3367 <para>Sometimes the canned rule just doesn't do the right thing.
3368 For example, in the <literal>nofib</literal> suite we want the
3369 link step to print out timing information. The thing to do here
3370 is <emphasis>not</emphasis> to define
3371 <constant>HS_PROG</constant> or
3372 <constant>C_PROG</constant>, and instead define a special
3373 purpose rule in your own <filename>Makefile</filename>. By
3374 using different variable names you will avoid the canned rules
3375 being included, and conflicting with yours.</para>
3379 <sect1 id="building-docs">
3380 <title>Building the documentation</title>
3382 <sect2 id="pre-supposed-doc-tools">
3383 <title>Tools for building the Documentation</title>
3385 <para>The following additional tools are required if you want to
3386 format the documentation that comes with the
3387 <literal>fptools</literal> projects:</para>
3392 <indexterm><primary>pre-supposed: DocBook</primary></indexterm>
3393 <indexterm><primary>DocBook, pre-supposed</primary></indexterm>
3396 <para>Much of our documentation is written in DocBook XML, instructions
3397 on installing and configuring the DocBook tools are below.</para>
3403 <indexterm><primary>pre-supposed: TeX</primary></indexterm>
3404 <indexterm><primary>TeX, pre-supposed</primary></indexterm>
3407 <para>A decent TeX distribution is required if you want to
3408 produce printable documentation. We recomment teTeX,
3409 which includes just about everything you need.</para>
3415 <indexterm><primary>Haddock</primary></indexterm>
3418 <para>Haddock is a Haskell documentation tool that we use
3419 for automatically generating documentation from the
3420 library source code. It is an <literal>fptools</literal>
3421 project in itself. To build documentation for the
3422 libraries (<literal>fptools/libraries</literal>) you
3423 should check out and build Haddock in
3424 <literal>fptools/haddock</literal>. Haddock requires GHC
3432 <title>Installing the DocBook tools</title>
3435 <title>Installing the DocBook tools on Linux</title>
3437 <para>If you're on a recent RedHat (7.0+) or SuSE (8.1+) system,
3438 you probably have working DocBook tools already installed. The
3439 configure script should detect your setup and you're away.</para>
3441 <para>If you don't have DocBook tools installed, and you are
3442 using a system that can handle RPM packages, you can use <ulink
3443 url="http://rpmfind.net/">Rpmfind.net</ulink> to find suitable
3444 packages for your system. Search for the packages
3445 <literal>docbook-dtd</literal>,
3446 <literal>docbook-xsl-stylesheets</literal>,
3447 <literal>libxslt</literal>,
3448 <literal>libxml2</literal>,
3449 <literal>fop</literal>,
3450 <literal>xmltex</literal>, and
3451 <literal>dvips</literal>.</para>
3455 <title>Installing DocBook on FreeBSD</title>
3457 <para>On FreeBSD systems, the easiest way to get DocBook up
3458 and running is to install it from the ports tree or a
3459 pre-compiled package (packages are available from your local
3460 FreeBSD mirror site).</para>
3462 <para>To use the ports tree, do this:
3463 <screen>$ cd /usr/ports/textproc/docproj
3464 $ make install</screen>
3465 This installs the FreeBSD documentation project tools, which
3466 includes everything needed to format the GHC
3467 documentation.</para>
3471 <title>Installing from binaries on Windows</title>
3473 <para>Probably the fastest route to a working DocBook environment on
3474 Windows is to install <ulink url="http://www.cygwin.com/">Cygwin</ulink>
3475 with the complete <literal>Doc</literal> category. If you are using
3476 <ulink url="http://www.mingw.org/">MinGW</ulink> for compilation, you
3477 have to help <command>configure</command> a little bit: Set the
3478 environment variables <envar>XmllintCmd</envar> and
3479 <envar>XsltprocCmd</envar> to the paths of the Cygwin executables
3480 <command>xmllint</command> and <command>xsltproc</command>,
3481 respectively, and set <envar>fp_cv_dir_docbook_xsl</envar> to the path
3482 of the directory where the XSL stylesheets are installed,
3483 e.g. <filename>c:/cygwin/usr/share/docbook-xsl</filename>.
3486 <para>If you want to build HTML Help, you have to install the
3487 <ulink url="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/htmlhelp/html/hworiHTMLHelpStartPage.asp">HTML Help SDK</ulink>,
3488 too, and make sure that <command>hhc</command> is in your <envar>PATH</envar>.</para>
3494 <title>Configuring the DocBook tools</title>
3496 <para>Once the DocBook tools are installed, the configure script
3497 will detect them and set up the build system accordingly. If you
3498 have a system that isn't supported, let us know, and we'll try
3503 <title>Building the documentation</title>
3505 <para>To build documentation in a certain format, you can
3506 say, for example,</para>
3508 <screen>$ make html</screen>
3510 <para>to build HTML documentation below the current directory.
3511 The available formats are: <literal>dvi</literal>,
3512 <literal>ps</literal>, <literal>pdf</literal>,
3513 <literal>html</literal>, and <literal>rtf</literal>. Note that
3514 not all documentation can be built in all of these formats: HTML
3515 documentation is generally supported everywhere, and DocBook
3516 documentation might support the other formats (depending on what
3517 other tools you have installed).</para>
3519 <para>All of these targets are recursive; that is, saying
3520 <literal>make html</literal> will make HTML docs for all the
3521 documents recursively below the current directory.</para>
3523 <para>Because there are many different formats that the DocBook
3524 documentation can be generated in, you have to select which ones
3525 you want by setting the <literal>XMLDocWays</literal> variable
3526 to a list of them. For example, in
3527 <filename>build.mk</filename> you might have a line:</para>
3529 <screen>XMLDocWays = html ps</screen>
3531 <para>This will cause the documentation to be built in the requested
3532 formats as part of the main build (the default is not to build
3533 any documentation at all).</para>
3537 <title>Installing the documentation</title>
3539 <para>To install the documentation, use:</para>
3541 <screen>$ make install-docs</screen>
3543 <para>This will install the documentation into
3544 <literal>$(datadir)</literal> (which defaults to
3545 <literal>$(prefix)/share</literal>). The exception is HTML
3546 documentation, which goes into
3547 <literal>$(datadir)/html</literal>, to keep things tidy.</para>
3549 <para>Note that unless you set <literal>$(XMLDocWays)</literal>
3550 to a list of formats, the <literal>install-docs</literal> target
3551 won't do anything for DocBook XML documentation.</para>
3557 <sect1 id="sec-porting-ghc">
3558 <title>Porting GHC</title>
3560 <para>This section describes how to port GHC to a currenly
3561 unsupported platform. There are two distinct
3562 possibilities:</para>
3566 <para>The hardware architecture for your system is already
3567 supported by GHC, but you're running an OS that isn't
3568 supported (or perhaps has been supported in the past, but
3569 currently isn't). This is the easiest type of porting job,
3570 but it still requires some careful bootstrapping. Proceed to
3571 <xref linkend="sec-booting-from-hc"/>.</para>
3575 <para>Your system's hardware architecture isn't supported by
3576 GHC. This will be a more difficult port (though by comparison
3577 perhaps not as difficult as porting gcc). Proceed to <xref
3578 linkend="unregisterised-porting"/>.</para>
3582 <sect2 id="sec-booting-from-hc">
3583 <title>Booting/porting from C (<filename>.hc</filename>) files</title>
3585 <indexterm><primary>building GHC from .hc files</primary></indexterm>
3586 <indexterm><primary>booting GHC from .hc files</primary></indexterm>
3587 <indexterm><primary>porting GHC</primary></indexterm>
3589 <para>Bootstrapping GHC on a system without GHC already
3590 installed is achieved by taking the intermediate C files (known
3591 as HC files) from another GHC compilation, compiling them using gcc to
3592 get a working GHC.</para>
3594 <para><emphasis>NOTE: GHC versions 5.xx were hard to bootstrap
3595 from C. We recommend using GHC 6.0.1 or
3596 later.</emphasis></para>
3598 <para>HC files are platform-dependent, so you have to get a set
3599 that were generated on <emphasis>the same platform</emphasis>. There
3600 may be some supplied on the GHC download page, otherwise you'll have to
3601 compile some up yourself, or start from
3602 <emphasis>unregisterised</emphasis> HC files - see <xref
3603 linkend="unregisterised-porting"/>.</para>
3605 <para>The following steps should result in a working GHC build
3606 with full libraries:</para>
3610 <para>Unpack the HC files on top of a fresh source tree
3611 (make sure the source tree version matches the version of
3612 the HC files <emphasis>exactly</emphasis>!). This will
3613 place matching <filename>.hc</filename> files next to the
3614 corresponding Haskell source (<filename>.hs</filename> or
3615 <filename>.lhs</filename>) in the compiler subdirectory
3616 <filename>ghc/compiler</filename> and in the libraries
3618 <literal>libraries</literal>).</para>
3622 <para>The actual build process is fully automated by the
3623 <filename>hc-build</filename> script located in the
3624 <filename>distrib</filename> directory. If you eventually
3625 want to install GHC into the directory
3626 <replaceable>dir</replaceable>, the following
3627 command will execute the whole build process (it won't
3628 install yet):</para>
3630 <screen>$ distrib/hc-build --prefix=<replaceable>dir</replaceable></screen>
3631 <indexterm><primary>--hc-build</primary></indexterm>
3633 <para>By default, the installation directory is
3634 <filename>/usr/local</filename>. If that is what you want,
3635 you may omit the argument to <filename>hc-build</filename>.
3636 Generally, any option given to <filename>hc-build</filename>
3637 is passed through to the configuration script
3638 <filename>configure</filename>. If
3639 <filename>hc-build</filename> successfully completes the
3640 build process, you can install the resulting system, as
3643 <screen>$ make install</screen>
3648 <sect2 id="unregisterised-porting">
3649 <title>Porting GHC to a new architecture</title>
3651 <para>The first step in porting to a new architecture is to get
3652 an <firstterm>unregisterised</firstterm> build working. An
3653 unregisterised build is one that compiles via vanilla C only.
3654 By contrast, a registerised build uses the following
3655 architecture-specific hacks for speed:</para>
3659 <para>Global register variables: certain abstract machine
3660 <quote>registers</quote> are mapped to real machine
3661 registers, depending on how many machine registers are
3663 <filename>ghc/includes/MachRegs.h</filename>).</para>
3667 <para>Assembly-mangling: when compiling via C, we feed the
3668 assembly generated by gcc though a Perl script known as the
3669 <firstterm>mangler</firstterm> (see
3670 <filename>ghc/driver/mangler/ghc-asm.lprl</filename>). The
3671 mangler rearranges the assembly to support tail-calls and
3672 various other optimisations.</para>
3676 <para>In an unregisterised build, neither of these hacks are
3677 used — the idea is that the C code generated by the
3678 compiler should compile using gcc only. The lack of these
3679 optimisations costs about a factor of two in performance, but
3680 since unregisterised compilation is usually just a step on the
3681 way to a full registerised port, we don't mind too much.</para>
3683 <para>Notes on GHC portability in general: we've tried to stick
3684 to writing portable code in most parts of the system, so it
3685 should compile on any POSIXish system with gcc, but in our
3686 experience most systems differ from the standards in one way or
3687 another. Deal with any problems as they arise - if you get
3688 stuck, ask the experts on
3689 <email>glasgow-haskell-users@haskell.org</email>.</para>
3691 <para>Lots of useful information about the innards of GHC is
3692 available in the <ulink
3693 url="http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/">GHC
3694 Commentary</ulink>, which might be helpful if you run into some
3695 code which needs tweaking for your system.</para>
3698 <title>Cross-compiling to produce an unregisterised GHC</title>
3700 <para>NOTE! These instructions apply to GHC 6.4 and (hopefully)
3701 later. If you need instructions for an earlier version of GHC, try
3702 to get hold of the version of this document that was current at the
3703 time. It should be available from the appropriate download page on
3705 url="http://www.haskell.org/ghc/">GHC homepage</ulink>.</para>
3707 <para>In this section, we explain how to bootstrap GHC on a
3708 new platform, using unregisterised intermediate C files. We
3709 haven't put a great deal of effort into automating this
3710 process, for two reasons: it is done very rarely, and the
3711 process usually requires human intervention to cope with minor
3712 porting issues anyway.</para>
3714 <para>The following step-by-step instructions should result in
3715 a fully working, albeit unregisterised, GHC. Firstly, you
3716 need a machine that already has a working GHC (we'll call this
3717 the <firstterm>host</firstterm> machine), in order to
3718 cross-compile the intermediate C files that we will use to
3719 bootstrap the compiler on the <firstterm>target</firstterm>
3724 <para>On the target machine:</para>
3728 <para>Unpack a source tree (preferably a released
3729 version). We will call the path to the root of this
3730 tree <replaceable>T</replaceable>.</para>
3734 <screen>$ cd <replaceable>T</replaceable>
3735 $ ./configure --enable-hc-boot --enable-hc-boot-unregisterised</screen>
3737 <para>You might need to update
3738 <filename>configure.in</filename> to recognise the new
3739 architecture, and re-generate
3740 <filename>configure</filename> with
3741 <literal>autoreconf</literal>.</para>
3745 <screen>$ cd <replaceable>T</replaceable>/ghc/includes
3752 <para>On the host machine:</para>
3756 <para>Unpack a source tree (same released version). Call
3757 this directory <replaceable>H</replaceable>.</para>
3761 <screen>$ cd <replaceable>H</replaceable>
3762 $ ./configure</screen>
3767 <filename><replaceable>H</replaceable>/mk/build.mk</filename>,
3768 with the following contents:</para>
3770 <programlisting>GhcUnregisterised = YES
3771 GhcLibHcOpts = -O -fvia-C -keep-hc-files
3772 GhcRtsHcOpts = -keep-hc-files
3775 GhcWithNativeCodeGen = NO
3776 GhcWithInterpreter = NO
3777 GhcStage1HcOpts = -O
3778 GhcStage2HcOpts = -O -fvia-C -keep-hc-files
3779 SRC_HC_OPTS += -H32m
3780 GhcBootLibs = YES</programlisting>
3785 <filename><replaceable>H</replaceable>/mk/config.mk</filename>:</para>
3788 <para>change <literal>TARGETPLATFORM</literal>
3789 appropriately, and set the variables involving
3790 <literal>TARGET</literal> to the correct values for
3791 the target platform. This step is necessary because
3792 currently <literal>configure</literal> doesn't cope
3793 with specifying different values for the
3794 <literal>--host</literal> and
3795 <literal>--target</literal> flags.</para>
3798 <para>copy <literal>LeadingUnderscore</literal>
3799 setting from target.</para>
3806 <filename><replaceable>T</replaceable>/ghc/includes/ghcautoconf.h</filename>, <filename><replaceable>T</replaceable>/ghc/includes/DerivedConstants.h</filename>, and <filename><replaceable>T</replaceable>/ghc/includes/GHCConstants.h</filename>
3808 <filename><replaceable>H</replaceable>/ghc/includes</filename>.
3809 Note that we are building on the host machine, using the
3810 target machine's configuration files. This
3811 is so that the intermediate C files generated here will
3812 be suitable for compiling on the target system.</para>
3816 <para>Touch the generated configuration files, just to make
3817 sure they don't get replaced during the build:</para>
3818 <screen>$ cd <filename><replaceable>H</replaceable></filename>/ghc/includes
3819 $ touch ghcautoconf.h DerivedConstants.h GHCConstants.h mkDerivedConstants.c
3820 $ touch mkDerivedConstantsHdr mkDerivedConstants.o mkGHCConstants mkGHCConstants.o</screen>
3822 <para>Note: it has been reported that these files still get
3823 overwritten during the next stage. We have installed a fix
3824 for this in GHC 6.4.2, but if you are building a version
3825 before that you need to watch out for these files getting
3826 overwritte by the <literal>Makefile</literal> in
3827 <literal>ghc/includes</literal>. If your system supports
3828 it, you might be able to prevent it by making them
3830 <screen>$ chflags uchg ghc/includes/{ghcautoconf.h,DerivedConstants.h,GHCConstants.h}</screen>
3834 <para>Now build the compiler:</para>
3835 <screen>$ cd <replaceable>H</replaceable>/glafp-utils && make boot && make
3836 $ cd <replaceable>H</replaceable>/ghc && make boot && make</screen>
3837 <para>Don't worry if the build falls over in the RTS, we
3838 don't need the RTS yet.</para>
3842 <screen>$ cd <replaceable>H</replaceable>/libraries
3843 $ make boot && make</screen>
3847 <screen>$ cd <replaceable>H</replaceable>/ghc/compiler
3848 $ make boot stage=2 && make stage=2</screen>
3852 <screen>$ cd <replaceable>H</replaceable>/ghc/lib/compat
3855 $ make boot UseStage1=YES
3856 $ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'
3857 $ cd <replaceable>H</replaceable>/ghc/utils
3859 $ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'</screen>
3863 <screen>$ cd <replaceable>H</replaceable>
3864 $ make hc-file-bundle Project=Ghc</screen>
3869 <filename><replaceable>H</replaceable>/*-hc.tar.gz</filename>
3870 to <filename><replaceable>T</replaceable>/..</filename>.</para>
3876 <para>On the target machine:</para>
3878 <para>At this stage we simply need to bootstrap a compiler
3879 from the intermediate C files we generated above. The
3880 process of bootstrapping from C files is automated by the
3881 script in <literal>distrib/hc-build</literal>, and is
3882 described in <xref linkend="sec-booting-from-hc"/>.</para>
3884 <screen>$ ./distrib/hc-build --enable-hc-boot-unregisterised</screen>
3886 <para>However, since this is a bootstrap on a new machine,
3887 the automated process might not run to completion the
3888 first time. For that reason, you might want to treat the
3889 <literal>hc-build</literal> script as a list of
3890 instructions to follow, rather than as a fully automated
3891 script. This way you'll be able to restart the process
3892 part-way through if you need to fix anything on the
3895 <para>Don't bother with running
3896 <literal>make install</literal> in the newly
3897 bootstrapped tree; just use the compiler in that tree to
3898 build a fresh compiler from scratch, this time without
3899 booting from C files. Before doing this, you might want
3900 to check that the bootstrapped compiler is generating
3901 working binaries:</para>
3903 <screen>$ cat >hello.hs
3904 main = putStrLn "Hello World!\n"
3906 $ <replaceable>T</replaceable>/ghc/compiler/ghc-inplace hello.hs -o hello
3908 Hello World!</screen>
3910 <para>Once you have the unregisterised compiler up and
3911 running, you can use it to start a registerised port. The
3912 following sections describe the various parts of the
3913 system that will need architecture-specific tweaks in
3914 order to get a registerised build going.</para>
3921 <title>Porting the RTS</title>
3923 <para>The following files need architecture-specific code for a
3924 registerised build:</para>
3928 <term><filename>ghc/includes/MachRegs.h</filename>
3929 <indexterm><primary><filename>MachRegs.h</filename></primary></indexterm>
3932 <para>Defines the STG-register to machine-register
3933 mapping. You need to know your platform's C calling
3934 convention, and which registers are generally available
3935 for mapping to global register variables. There are
3936 plenty of useful comments in this file.</para>
3940 <term><filename>ghc/includes/TailCalls.h</filename>
3941 <indexterm><primary><filename>TailCalls.h</filename></primary></indexterm>
3944 <para>Macros that cooperate with the mangler (see <xref
3945 linkend="sec-mangler"/>) to make proper tail-calls
3950 <term><filename>ghc/rts/Adjustor.c</filename>
3951 <indexterm><primary><filename>Adjustor.c</filename></primary></indexterm>
3955 <literal>foreign import "wrapper"</literal>
3957 <literal>foreign export dynamic</literal>).
3958 Not essential for getting GHC bootstrapped, so this file
3959 can be deferred until later if necessary.</para>
3963 <term><filename>ghc/rts/StgCRun.c</filename>
3964 <indexterm><primary><filename>StgCRun.c</filename></primary></indexterm>
3967 <para>The little assembly layer between the C world and
3968 the Haskell world. See the comments and code for the
3969 other architectures in this file for pointers.</para>
3973 <term><filename>ghc/rts/MBlock.h</filename>
3974 <indexterm><primary><filename>MBlock.h</filename></primary></indexterm>
3976 <term><filename>ghc/rts/MBlock.c</filename>
3977 <indexterm><primary><filename>MBlock.c</filename></primary></indexterm>
3980 <para>These files are really OS-specific rather than
3981 architecture-specific. In <filename>MBlock.h</filename>
3982 is specified the absolute location at which the RTS
3983 should try to allocate memory on your platform (try to
3984 find an area which doesn't conflict with code or dynamic
3985 libraries). In <filename>Mblock.c</filename> you might
3986 need to tweak the call to <literal>mmap()</literal> for
3993 <sect3 id="sec-mangler">
3994 <title>The mangler</title>
3996 <para>The mangler is an evil Perl-script
3997 (<filename>ghc/driver/mangler/ghc-asm.lprl</filename>) that
3998 rearranges the assembly code output from gcc to do two main
4003 <para>Remove function prologues and epilogues, and all
4004 movement of the C stack pointer. This is to support
4005 tail-calls: every code block in Haskell code ends in an
4006 explicit jump, so we don't want the C-stack overflowing
4007 while we're jumping around between code blocks.</para>
4010 <para>Move the <firstterm>info table</firstterm> for a
4011 closure next to the entry code for that closure. In
4012 unregisterised code, info tables contain a pointer to the
4013 entry code, but in registerised compilation we arrange
4014 that the info table is shoved right up against the entry
4015 code, and addressed backwards from the entry code pointer
4016 (this saves a word in the info table and an extra
4017 indirection when jumping to the closure entry
4022 <para>The mangler is abstracted to a certain extent over some
4023 architecture-specific things such as the particular assembler
4024 directives used to herald symbols. Take a look at the
4025 definitions for other architectures and use these as a
4026 starting point.</para>
4030 <title>The splitter</title>
4032 <para>The splitter is another evil Perl script
4033 (<filename>ghc/driver/split/ghc-split.lprl</filename>). It
4034 cooperates with the mangler to support object splitting.
4035 Object splitting is what happens when the
4036 <option>-split-objs</option> option is passed to GHC: the
4037 object file is split into many smaller objects. This feature
4038 is used when building libraries, so that a program statically
4039 linked against the library will pull in less of the
4042 <para>The splitter has some platform-specific stuff; take a
4043 look and tweak it for your system.</para>
4047 <title>The native code generator</title>
4049 <para>The native code generator isn't essential to getting a
4050 registerised build going, but it's a desirable thing to have
4051 because it can cut compilation times in half. The native code
4052 generator is described in some detail in the <ulink
4053 url="http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/">GHC
4054 commentary</ulink>.</para>
4060 <para>To support GHCi, you need to port the dynamic linker
4061 (<filename>fptools/ghc/rts/Linker.c</filename>). The linker
4062 currently supports the ELF and PEi386 object file formats - if
4063 your platform uses one of these then things will be
4064 significantly easier. The majority of Unix platforms use the
4065 ELF format these days. Even so, there are some
4066 machine-specific parts of the ELF linker: for example, the
4067 code for resolving particular relocation types is
4068 machine-specific, so some porting of this code to your
4069 architecture will probaly be necessary.</para>
4071 <para>If your system uses a different object file format, then
4072 you have to write a linker — good luck!</para>
4078 <sect1 id="sec-build-pitfalls">
4079 <title>Known pitfalls in building Glasgow Haskell
4081 <indexterm><primary>problems, building</primary></indexterm>
4082 <indexterm><primary>pitfalls, in building</primary></indexterm>
4083 <indexterm><primary>building pitfalls</primary></indexterm></title>
4086 WARNINGS about pitfalls and known “problems”:
4095 One difficulty that comes up from time to time is running out of space
4096 in <literal>TMPDIR</literal>. (It is impossible for the configuration stuff to
4097 compensate for the vagaries of different sysadmin approaches to temp
4099 <indexterm><primary>tmp, running out of space in</primary></indexterm>
4101 The quickest way around it is <command>setenv TMPDIR /usr/tmp</command><indexterm><primary>TMPDIR</primary></indexterm> or
4102 even <command>setenv TMPDIR .</command> (or the equivalent incantation with your shell
4105 The best way around it is to say
4107 <programlisting>export TMPDIR=<dir></programlisting>
4109 in your <filename>build.mk</filename> file.
4110 Then GHC and the other <literal>fptools</literal> programs will use the appropriate directory
4119 In compiling some support-code bits, e.g., in <filename>ghc/rts/gmp</filename> and even
4120 in <filename>ghc/lib</filename>, you may get a few C-compiler warnings. We think these
4128 When compiling via C, you'll sometimes get “warning: assignment from
4129 incompatible pointer type” out of GCC. Harmless.
4136 Similarly, <command>ar</command>chiving warning messages like the following are not
4139 <screen>ar: filename GlaIOMonad__1_2s.o truncated to GlaIOMonad_
4140 ar: filename GlaIOMonad__2_2s.o truncated to GlaIOMonad_
4149 In compiling the compiler proper (in <filename>compiler/</filename>), you <emphasis>may</emphasis>
4150 get an “Out of heap space” error message. These can vary with the
4151 vagaries of different systems, it seems. The solution is simple:
4158 If you're compiling with GHC 4.00 or later, then the
4159 <emphasis>maximum</emphasis> heap size must have been reached. This
4160 is somewhat unlikely, since the maximum is set to 64M by default.
4161 Anyway, you can raise it with the
4162 <option>-optCrts-M<size></option> flag (add this flag to
4163 <constant><module>_HC_OPTS</constant>
4164 <command>make</command> variable in the appropriate
4165 <filename>Makefile</filename>).
4172 For GHC < 4.00, add a suitable <option>-H</option> flag to the <filename>Makefile</filename>, as
4181 and try again: <command>gmake</command>. (see <xref linkend="sec-suffix"/> for information about
4182 <constant><module>_HC_OPTS</constant>.)
4184 Alternatively, just cut to the chase:
4186 <screen>$ cd ghc/compiler
4187 $ make EXTRA_HC_OPTS=-optCrts-M128M</screen>
4195 If you try to compile some Haskell, and you get errors from GCC about
4196 lots of things from <filename>/usr/include/math.h</filename>, then your GCC was
4197 mis-installed. <command>fixincludes</command> wasn't run when it should've been.
4199 As <command>fixincludes</command> is now automagically run as part of GCC installation,
4200 this bug also suggests that you have an old GCC.
4208 You <emphasis>may</emphasis> need to re-<command>ranlib</command><indexterm><primary>ranlib</primary></indexterm> your libraries (on Sun4s).
4211 <screen>$ cd $(libdir)/ghc-x.xx/sparc-sun-sunos4
4212 $ foreach i ( `find . -name '*.a' -print` ) # or other-shell equiv...
4214 ? # or, on some machines: ar s $i
4218 We'd be interested to know if this is still necessary.
4226 GHC's sources go through <command>cpp</command> before being compiled, and <command>cpp</command> varies
4227 a bit from one Unix to another. One particular gotcha is macro calls
4231 <programlisting>SLIT("Hello, world")</programlisting>
4234 Some <command>cpp</command>s treat the comma inside the string as separating two macro
4235 arguments, so you get
4238 <screen>:731: macro `SLIT' used with too many (2) args</screen>
4241 Alas, <command>cpp</command> doesn't tell you the offending file!
4243 Workaround: don't put weird things in string args to <command>cpp</command> macros.
4254 <sect1 id="platforms"><title>Platforms, scripts, and file names</title>
4256 GHC is designed both to be built, and to run, on both Unix and Windows. This flexibility
4257 gives rise to a good deal of brain-bending detail, which we have tried to collect in this chapter.
4260 <sect2 id="cygwin-and-mingw"><title>Windows platforms: Cygwin, MSYS, and MinGW</title>
4262 <para> The build system is built around Unix-y makefiles. Because it's not native,
4263 the Windows situation for building GHC is particularly confusing. This section
4264 tries to clarify, and to establish terminology.</para>
4266 <sect3 id="ghc-mingw"><title>MinGW</title>
4268 <para> <ulink url="http://www.mingw.org">MinGW (Minimalist GNU for Windows)</ulink>
4269 is a collection of header
4270 files and import libraries that allow one to use <command>gcc</command> and produce
4271 native Win32 programs that do not rely on any third-party DLLs. The
4272 current set of tools include GNU Compiler Collection (<command>gcc</command>), GNU Binary
4273 Utilities (Binutils), GNU debugger (Gdb), GNU make, and a assorted
4277 <para> The down-side of MinGW is that the MinGW libraries do not support anything like the full
4282 <sect3 id="ghc-cygwin"><title>Cygwin and MSYS</title>
4284 <para>You can't use the MinGW to <emphasis>build</emphasis> GHC, because MinGW doesn't have a shell,
4285 or the standard Unix commands such as <command>mv</command>, <command>rm</command>,
4286 <command>ls</command>, nor build-system stuff such as <command>make</command> and <command>cvs</command>.
4287 For that, there are two choices: <ulink url="http://www.cygwin.com">Cygwin</ulink>
4288 and <ulink url="http://www.mingw.org/msys.shtml">MSYS</ulink>:
4292 Cygwin comes with compilation tools (<command>gcc</command>, <command>ld</command> and so on), which
4293 compile code that has access to all of Posix. The price is that the executables must be
4294 dynamically linked with the Cygwin DLL, so that <emphasis>you cannot run a Cywin-compiled program on a machine
4295 that doesn't have Cygwin</emphasis>. Worse, Cygwin is a moving target. The name of the main DLL, <literal>cygwin1.dll</literal>
4296 does not change, but the implementation certainly does. Even the interfaces to functions
4297 it exports seem to change occasionally. </para>
4301 MSYS is a fork of the Cygwin tree, so they
4302 are fundamentally similar. However, MSYS is by design much smaller and simpler. Access to the file system goes
4303 through fewer layers, so MSYS is quite a bit faster too.
4306 <para>Furthermore, MSYS provides no compilation tools; it relies instead on the MinGW tools. These
4307 compile binaries that run with no DLL support, on any Win32 system.
4308 However, MSYS does come with all the make-system tools, such as <command>make</command>, <command>autoconf</command>,
4309 <command>cvs</command>, <command>ssh</command> etc. To get these, you have to download the
4310 MsysDTK (Developer Tool Kit) package, as well as the base MSYS package.
4312 <para>MSYS does have a DLL, but it's only used by MSYS commands (<command>sh</command>, <command>rm</command>,
4313 <command>ssh</command> and so on),
4314 not by programs compiled under MSYS.
4322 <sect3><title>Targeting MinGW</title>
4324 <para>We want GHC to compile programs that work on any Win32 system. Hence:
4327 GHC does invoke a C compiler, assembler, linker and so on, but we ensure that it only
4328 invokes the MinGW tools, not the Cygwin ones. That means that the programs GHC compiles
4329 will work on any system, but it also means that the programs GHC compiles do not have access
4330 to all of Posix. In particular, they cannot import the (Haskell) Posix
4331 library; they have to do
4332 their input output using standard Haskell I/O libraries, or native Win32 bindings.</para>
4333 <para> We will call a GHC that targets MinGW in this way <emphasis>GHC-mingw</emphasis>.</para>
4337 To make the GHC distribution self-contained, the GHC distribution includes the MinGW <command>gcc</command>,
4338 <command>as</command>, <command>ld</command>, and a bunch of input/output libraries.
4341 So <emphasis>GHC targets MinGW</emphasis>, not Cygwin.
4342 It is in principle possible to build a version of GHC, <emphasis>GHC-cygwin</emphasis>,
4343 that targets Cygwin instead. The up-side of GHC-cygwin is
4344 that Haskell programs compiled by GHC-cygwin can import the (Haskell) Posix library.
4345 <emphasis>We do not support GHC-cygwin, however; it is beyond our resources.</emphasis>
4348 <para>While GHC <emphasis>targets</emphasis> MinGW, that says nothing about
4349 how GHC is <emphasis>built</emphasis>. We use both MSYS and Cygwin as build environments for
4350 GHC; both work fine, though MSYS is rather lighter weight.</para>
4352 <para>In your build tree, you build a compiler called <command>ghc-inplace</command>. It
4353 uses the <command>gcc</command> that you specify using the
4354 <option>--with-gcc</option> flag when you run
4355 <command>configure</command> (see below).
4356 The makefiles are careful to use <command>ghc-inplace</command> (not <command>gcc</command>)
4357 to compile any C files, so that it will in turn invoke the correct <command>gcc</command> rather that
4358 whatever one happens to be in your path. However, the makefiles do use whatever <command>ld</command>
4359 and <command>ar</command> happen to be in your path. This is a bit naughty, but (a) they are only
4360 used to glom together .o files into a bigger .o file, or a .a file,
4361 so they don't ever get libraries (which would be bogus; they might be the wrong libraries), and (b)
4362 Cygwin and MinGW use the same .o file format. So its ok.
4366 <sect3><title> File names </title>
4368 <para>Cygwin, MSYS, and the underlying Windows file system all understand file paths of form <literal>c:/tmp/foo</literal>.
4372 MSYS programs understand <filename>/bin</filename>, <filename>/usr/bin</filename>, and map Windows's lettered drives as
4373 <filename>/c/tmp/foo</filename> etc. The exact mount table is given in the doc subdirectory of the MSYS distribution.
4375 <para> When it invokes a command, the MSYS shell sees whether the invoked binary lives in the MSYS <filename>/bin</filename>
4376 directory. If so, it just invokes it. If not, it assumes the program is no an MSYS program, and walks over the command-line
4377 arguments changing MSYS paths into native-compatible paths. It does this inside sub-arguments and inside quotes. For example,
4379 <programlisting>foogle -B/c/tmp/baz</programlisting>
4380 the MSYS shell will actually call <literal>foogle</literal> with argument <literal>-Bc:/tmp/baz</literal>.
4384 Cygwin programs have a more complicated mount table, and map the lettered drives as <filename>/cygdrive/c/tmp/foo</filename>.
4386 <para>The Cygwin shell does no argument processing when invoking non-Cygwin programs.
4392 <sect3><title>Crippled <command>ld</command></title>
4395 It turns out that on both Cygwin and MSYS, the <command>ld</command> has a
4396 limit of 32kbytes on its command line. Especially when using split object
4397 files, the make system can emit calls to <command>ld</command> with thousands
4398 of files on it. Then you may see something like this:
4400 (cd Graphics/Rendering/OpenGL/GL/QueryUtils_split && /mingw/bin/ld -r -x -o ../QueryUtils.o *.o)
4401 /bin/sh: /mingw/bin/ld: Invalid argument
4403 The solution is either to switch off object file splitting (set
4404 <option>SplitObjs</option> to <literal>NO</literal> in your
4405 <filename>build.mk</filename>),
4406 or to make the module smaller.
4410 <sect3><title>Host System vs Target System</title>
4413 In the source code you'll find various ifdefs looking like:
4414 <programlisting>#ifdef mingw32_HOST_OS
4416 #endif</programlisting>
4418 <programlisting>#ifdef mingw32_TARGET_OS
4420 #endif</programlisting>
4421 These macros are set by the configure script (via the file config.h).
4422 Which is which? The criterion is this. In the ifdefs in GHC's source code:
4425 <para>The "host" system is the one on which GHC itself will be run.</para>
4428 <para>The "target" system is the one for which the program compiled by GHC will be run.</para>
4431 For a stage-2 compiler, in which GHCi is available, the "host" and "target" systems must be the same.
4432 So then it doesn't really matter whether you use the HOST_OS or TARGET_OS cpp macros.
4439 <sect2><title>Wrapper scripts</title>
4442 Many programs, including GHC itself and hsc2hs, need to find associated binaries and libraries.
4443 For <emphasis>installed</emphasis> programs, the strategy depends on the platform. We'll use
4444 GHC itself as an example:
4447 On Unix, the command <command>ghc</command> is a shell script, generated by adding installation
4448 paths to the front of the source file <filename>ghc.sh</filename>,
4449 that invokes the real binary, passing "-B<emphasis>path</emphasis>" as an argument to tell <command>ghc</command>
4450 where to find its supporting files.
4454 On vanilla Windows, it turns out to be much harder to make reliable script to be run by the
4455 native Windows shell <command>cmd</command> (e.g. limits on the length
4456 of the command line). So instead we invoke the GHC binary directly, with no -B flag.
4457 GHC uses the Windows <literal>getExecDir</literal> function to find where the executable is,
4458 and from that figures out where the supporting files are.
4461 (You can find the layout of GHC's supporting files in the
4462 section "Layout of installed files" of Section 2 of the GHC user guide.)
4465 Things work differently for <emphasis>in-place</emphasis> execution, where you want to
4466 execute a program that has just been built in a build tree. The difference is that the
4467 layout of the supporting files is different.
4468 In this case, whether on Windows or Unix, we always use a shell script. This works OK
4469 on Windows because the script is executed by MSYS or Cygwin, which don't have the
4470 shortcomings of the native Windows <command>cmd</command> shell.
4477 <sect1 id="winbuild"><title>Instructions for building under Windows</title>
4480 This section gives detailed instructions for how to build
4481 GHC from source on your Windows machine. Similar instructions for
4482 installing and running GHC may be found in the user guide. In general,
4483 Win95/Win98 behave the same, and WinNT/Win2k behave the same.
4486 Make sure you read the preceding section on platforms (<xref linkend="platforms"/>)
4487 before reading section.
4488 You don't need Cygwin or MSYS to <emphasis>use</emphasis> GHC,
4489 but you do need one or the other to <emphasis>build</emphasis> GHC.</para>
4492 <sect2 id="msys-install"><title>Installing and configuring MSYS</title>
4495 MSYS is a lightweight alternative to Cygwin.
4496 You don't need MSYS to <emphasis>use</emphasis> GHC,
4497 but you do need it or Cygwin to <emphasis>build</emphasis> GHC.
4498 Here's how to install MSYS.
4501 Go to <ulink url="http://www.mingw.org/download.shtml">http://www.mingw.org/download.shtml</ulink> and
4502 download the following (of course, the version numbers will differ):
4504 <listitem><para>The main MSYS package (binary is sufficient): <literal>MSYS-1.0.9.exe</literal>
4506 <listitem><para>The MSYS developer's toolkit (binary is sufficient): <literal>msysDTK-1.0.1.exe</literal>.
4507 This provides <command>make</command>, <command>autoconf</command>,
4508 <command>ssh</command>, <command>cvs</command> and probably more besides.
4511 Run both executables (in the order given above) to install them. I put them in <literal>c:/msys</literal>
4515 Set the following environment variables
4517 <listitem><para><literal>PATH</literal>: add <literal>c:/msys/1.0/bin</literal> and
4518 <literal>c:/msys/1.0/local/bin</literal>
4519 to your path. (Of course, the version number may differ.)
4520 MSYS mounts the former as both <literal>/bin</literal> and
4521 <literal>/usr/bin</literal> and the latter as <literal>/usr/local/bin</literal>.
4524 <listitem><para><literal>HOME</literal>: set to your home directory (e.g. <literal>c:/userid</literal>).
4525 This is where, among other things, <command>ssh</command> will look for your <literal>.ssh</literal> directory.
4528 <listitem><para><literal>SHELL</literal>: set to <literal>c:/msys/1.0/bin/sh.exe</literal>
4531 <listitem><para><literal>CVS_RSH</literal>: set to <literal>c:/msys/1.0/bin/ssh.exe</literal>. Only necessary if
4535 <listitem><para><literal>MAKE_MODE</literal>: set to <literal>UNIX</literal>. (I'm not certain this is necessary for MSYS.)
4542 Check that the <literal>CYGWIN</literal> environment variable is <emphasis>not</emphasis> set. It's a bad bug
4543 that MSYS is affected by this, but if you have CYGWIN set to "ntsec ntea", which is right for Cygwin, it
4544 causes the MSYS <command>ssh</command> to bogusly fail complaining that your <filename>.ssh/identity</filename>
4545 file has too-liberal permissinos.
4550 <para>Here are some points to bear in mind when using MSYS:
4552 <listitem> <para> MSYS does some kind of special magic to binaries stored in
4553 <filename>/bin</filename> and <filename>/usr/bin</filename>, which are by default both mapped
4554 to <filename>c:/msys/1.0/bin</filename> (assuming you installed MSYS in <filename>c:/msys</filename>).
4555 Do not put any other binaries (such as GHC or Alex) in this directory or its sub-directories:
4556 they fail in mysterious ways. However, it's fine to put other binaries in <filename>/usr/local/bin</filename>,
4557 which maps to <filename>c:/msys/1.0/local/bin</filename>.</para></listitem>
4559 <listitem> <para> MSYS seems to implement symbolic links by copying, so sharing is lost.
4563 Win32 has a <command>find</command> command which is not the same as MSYS's find.
4564 You will probably discover that the Win32 <command>find</command> appears in your <constant>PATH</constant>
4565 before the MSYS one, because it's in the <emphasis>system</emphasis> <constant>PATH</constant>
4566 environment variable, whereas you have probably modified the <emphasis>user</emphasis> <constant>PATH</constant>
4567 variable. You can always invoke <command>find</command> with an absolute path, or rename it.
4571 MSYS comes with <command>bzip</command>, and MSYS's <command>tar</command>'s <literal>-j</literal>
4572 will bunzip an archive (e.g. <literal>tar xvjf foo.tar.bz2</literal>). Useful when you get a
4573 bzip'd dump.</para></listitem>
4579 <sect2 id="install-cygwin"><title>Installing and configuring Cygwin</title>
4581 <para> Install Cygwin from <ulink url="http://www.cygwin.com/">http://www.cygwin.com/</ulink>.
4582 The installation process is straightforward; we install it in
4583 <filename>c:/cygwin</filename>.</para>
4585 You must install enough Cygwin <emphasis>packages</emphasis> to support
4586 building GHC. If you miss out any of these, strange things will happen to you. There are two ways to do this:
4588 <listitem><para>The direct, but laborious way is to
4589 select all of the following packages in the installation dialogue:
4590 <command>cvs</command>,
4591 <command>openssh</command>,
4592 <command>autoconf</command>,
4593 <command>binutils</command> (includes ld and (I think) ar),
4594 <command>gcc</command>,
4595 <command>flex</command>,
4596 <command>make</command>.
4597 To see thse packages,
4598 click on the "View" button in the "Select Packages"
4599 stage of Cygwin's installation dialogue, until the view says "Full". The default view, which is
4600 "Category" isn't very helpful, and the "View" button is rather unobtrousive.
4604 <listitem><para>The clever way is to point the Cygwin installer at the
4605 <command>ghc-depends</command> package, which is kept at <ulink
4606 url="http://haskell.org/ghc/cygwin">http://haskell.org/ghc/cygwin</ulink>.
4607 When the Cygwin installer asks you to "Choose a Download Site", choose one of
4609 offered mirror sites; and then type "http://haskell.org/ghc/cygwin" into the
4610 "User URL" box and click "Add"; now two sites are selected. (The Cygwin
4611 installer remembers this for next time.)
4612 Click "Next".</para>
4613 <para>In the "Select Packages" dialogue box that follows, click the "+" sign by
4614 "Devel", scroll down to the end of the "Devel" packages, and choose
4615 <command>ghc-depends</command>.
4616 The package <command>ghc-depends</command> will not actually install anything itself,
4617 but forces additional packages to be added by the Cygwin installer.
4623 <para> Now set the following user environment variables:
4626 <listitem><para> Add <filename>c:/cygwin/bin</filename> and <filename>c:/cygwin/usr/bin</filename> to your
4627 <constant>PATH</constant></para></listitem>
4631 Set <constant>MAKE_MODE</constant> to <literal>UNIX</literal>. If you
4632 don't do this you get very weird messages when you type
4633 <command>make</command>, such as:
4634 <screen>/c: /c: No such file or directory</screen>
4638 <listitem><para> Set <constant>SHELL</constant> to
4639 <filename>c:/cygwin/bin/bash</filename>. When you invoke a shell in Emacs, this
4640 <constant>SHELL</constant> is what you get.
4643 <listitem><para> Set <constant>HOME</constant> to point to your
4644 home directory. This is where, for example,
4645 <command>bash</command> will look for your <filename>.bashrc</filename>
4646 file. Ditto <command>emacs</command> looking for <filename>.emacsrc</filename>
4651 <para>Here are some things to be aware of when using Cygwin:
4653 <listitem> <para>Cygwin doesn't deal well with filenames that include
4654 spaces. "<filename>Program Files</filename>" and "<filename>Local files</filename>" are
4658 <listitem> <para> Cygwin implements a symbolic link as a text file with some
4659 magical text in it. So other programs that don't use Cygwin's
4660 I/O libraries won't recognise such files as symlinks.
4661 In particular, programs compiled by GHC are meant to be runnable
4662 without having Cygwin, so they don't use the Cygwin library, so
4663 they don't recognise symlinks.
4667 See the notes in <xref linkend="msys-install"/> about <command>find</command> and <command>bzip</command>,
4668 which apply to Cygwin too.
4673 Some script files used in the make system start with "<command>#!/bin/perl</command>",
4674 (and similarly for <command>sh</command>). Notice the hardwired path!
4675 So you need to ensure that your <filename>/bin</filename> directory has at least
4676 <command>sh</command>, <command>perl</command>, and <command>cat</command> in it.
4677 All these come in Cygwin's <filename>bin</filename> directory, which you probably have
4678 installed as <filename>c:/cygwin/bin</filename>. By default Cygwin mounts "<filename>/</filename>" as
4679 <filename>c:/cygwin</filename>, so if you just take the defaults it'll all work ok.
4680 (You can discover where your Cygwin
4681 root directory <filename>/</filename> is by typing <command>mount</command>.)
4682 Provided <filename>/bin</filename> points to the Cygwin <filename>bin</filename>
4683 directory, there's no need to copy anything. If not, copy these binaries from the <filename>cygwin/bin</filename>
4684 directory (after fixing the <filename>sh.exe</filename> stuff mentioned in the previous bullet).
4690 By default, cygwin provides the command shell <filename>ash</filename>
4691 as <filename>sh.exe</filename>. It seems to be fine now, but in the past we
4692 saw build-system problems that turned out to be due to bugs in <filename>ash</filename>
4693 (to do with quoting and length of command lines). On the other hand <filename>bash</filename> seems
4695 If this happens to you (which it shouldn't), in <filename>cygwin/bin</filename>
4696 remove the supplied <filename>sh.exe</filename> (or rename it as <filename>ash.exe</filename>),
4697 and copy <filename>bash.exe</filename> to <filename>sh.exe</filename>.
4698 You'll need to do this in Windows Explorer or the Windows <command>cmd</command> shell, because
4699 you can't rename a running program!
4708 <sect2 id="configure-ssh"><title>Configuring SSH</title>
4710 <para><command>ssh</command> comes with both Cygwin and MSYS.
4711 (Cygwin note: you need to ask for package <command>openssh</command> (not ssh)
4712 in the Cygwin list of packages; or use the <command>ghc-depends</command>
4713 package -- see <xref linkend="install-cygwin"/>.)</para>
4715 <para>There are several strange things about <command>ssh</command> on Windows that you need to know.
4719 The programs <command>ssh-keygen1</command>, <command>ssh1</command>, and <command>cvs</command>,
4720 seem to lock up <command>bash</command> entirely if they try to get user input (e.g. if
4721 they ask for a password). To solve this, start up <filename>cmd.exe</filename>
4722 and run it as follows:
4723 <screen>c:\tmp> set CYGWIN32=tty
4724 c:\tmp> c:/user/local/bin/ssh-keygen1</screen> </para>
4727 <listitem><para> (Cygwin-only problem, I think.)
4728 <command>ssh</command> needs to access your directory <filename>.ssh</filename>, in your home directory.
4729 To determine your home directory <command>ssh</command> first looks in
4730 <filename>c:/cygwin/etc/passwd</filename> (or wherever you have Cygwin installed). If there's an entry
4731 there with your userid, it'll use that entry to determine your home directory, <emphasis>ignoring
4732 the setting of the environment variable $HOME</emphasis>. If the home directory is
4733 bogus, <command>ssh</command> fails horribly. The best way to see what is going on is to say
4734 <screen>ssh -v cvs.haskell.org</screen>
4735 which makes <command>ssh</command> print out information about its activity.
4737 <para> You can fix this problem, either by correcting the home-directory field in
4738 <filename>c:/cygwin/etc/passwd</filename>, or by simply deleting the entire entry for your userid. If
4739 you do that, <command>ssh</command> uses the $HOME environment variable instead.
4745 <para>To protect your
4746 <literal>.ssh</literal> from access by anyone else,
4747 right-click your <literal>.ssh</literal> directory, and
4748 select <literal>Properties</literal>. If you are not on
4749 the access control list, add yourself, and give yourself
4750 full permissions (the second panel). Remove everyone else
4751 from the access control list. Don't leave them there but
4752 deny them access, because 'they' may be a list that
4753 includes you!</para>
4757 <para>In fact <command>ssh</command> 3.6.1 now seems to <emphasis>require</emphasis>
4758 you to have Unix permissions 600 (read/write for owner only)
4759 on the <literal>.ssh/identity</literal> file, else it
4760 bombs out. For your local C drive, it seems that <literal>chmod 600 identity</literal> works,
4761 but on Windows NT/XP, it doesn't work on a network drive (exact dteails obscure).
4762 The solution seems to be to set the $CYGWIN environment
4763 variable to "<literal>ntsec neta</literal>". The $CYGWIN environment variable is discussed
4764 in <ulink url="http://cygwin.com/cygwin-ug-net/using-cygwinenv.html">the Cygwin User's Guide</ulink>,
4765 and there are more details in <ulink url="http://cygwin.com/faq/faq_4.html#SEC44">the Cygwin FAQ</ulink>.
4772 <sect2><title>Other things you need to install</title>
4774 <para>You have to install the following other things to build GHC, listed below.</para>
4776 <para>On Windows you often install executables in directories with spaces, such as
4777 "<filename>Program Files</filename>". However, the <literal>make</literal> system for fptools doesn't
4778 deal with this situation (it'd have to do more quoting of binaries), so you are strongly advised
4779 to put binaries for all tools in places with no spaces in their path.
4780 On both MSYS and Cygwin, it's perfectly OK to install such programs in the standard Unixy places,
4781 <filename>/usr/local/bin</filename> and <filename>/usr/local/lib</filename>. But it doesn't matter,
4782 provided they are in your path.
4786 Install an executable GHC, from <ulink url="http://www.haskell.org/ghc">http://www.haskell.org/ghc</ulink>.
4787 This is what you will use to compile GHC. Add it in your
4788 <constant>PATH</constant>: the installer tells you the path element
4789 you need to add upon completion.
4795 Install an executable Happy, from <ulink url="http://www.haskell.org/happy">http://www.haskell.org/happy</ulink>.
4796 Happy is a parser generator used to compile the Haskell grammar. Under MSYS or Cygwin you can easily
4797 build it from the source distribution using
4798 <screen>$ ./configure
4800 $ make install</screen>
4801 This should install it in <filename>/usr/local/bin</filename> (which maps to <filename>c:/msys/1.0/local/bin</filename>
4803 Make sure the installation directory is in your
4804 <constant>PATH</constant>.
4809 <para>Install an executable Alex. This can be done by building from the
4810 source distribution in the same way as Happy. Sources are
4811 available from <ulink
4812 url="http://www.haskell.org/alex">http://www.haskell.org/alex</ulink>.</para>
4816 <para>GHC uses the <emphasis>mingw</emphasis> C compiler to
4817 generate code, so you have to install that (see <xref linkend="cygwin-and-mingw"/>).
4818 Just pick up a mingw bundle at
4819 <ulink url="http://www.mingw.org/">http://www.mingw.org/</ulink>.
4820 We install it in <filename>c:/mingw</filename>.
4823 <para><emphasis>On MSYS</emphasis>, add <literal>c:/mingw/bin</literal> to your PATH. MSYS does not provide <command>gcc</command>,
4824 <command>ld</command>, <command>ar</command>, and so on, because it just uses the MinGW ones. So you need them
4828 <para><emphasis>On Cygwin, do not</emphasis> add any of the <emphasis>mingw</emphasis> binaries to your path.
4829 They are only going to get used by explicit access (via the --with-gcc flag you
4830 give to <command>configure</command> later). If you do add them to your path
4831 you are likely to get into a mess because their names overlap with Cygwin
4833 On the other hand, you <emphasis>do</emphasis> need <command>ld</command>, <command>ar</command>
4834 (and perhaps one or two other things) in your path. The Cygwin ones are fine,
4835 but you must have them; hence needing the Cygwin binutils package.
4841 <para>We use <command>emacs</command> a lot, so we install that too.
4842 When you are in <filename>fptools/ghc/compiler</filename>, you can use
4843 "<literal>make tags</literal>" to make a TAGS file for emacs. That uses the utility
4844 <filename>fptools/ghc/utils/hasktags/hasktags</filename>, so you need to make that first.
4845 The most convenient way to do this is by going <literal>make boot</literal> in <filename>fptools/ghc</filename>.
4846 The <literal>make tags</literal> command also uses <command>etags</command>, which comes with <command>emacs</command>,
4847 so you will need to add <filename>emacs/bin</filename> to your <literal>PATH</literal>.
4852 <para>You might want to install GLUT in your MSYS/Cygwin
4853 installation, otherwise the GLUT package will not be built with
4858 <para> Finally, check out a copy of GHC sources from
4859 the CVS repository, following the instructions above (<xref linkend="cvs-access"/>).
4866 <sect2><title>Building GHC</title>
4869 Now go read the documentation above on building from source (<xref linkend="sec-building-from-source"/>);
4870 the bullets below only tell
4871 you about Windows-specific wrinkles.</para>
4875 If you used <command>autoconf</command> instead of <command>autoreconf</command>,
4876 you'll get an error when you run <filename>./configure</filename>:
4879 creating mk/config.h
4880 mk/config.h is unchanged
4882 running /bin/sh ./configure --cache-file=.././config.cache --srcdir=.
4883 ./configure: ./configure: No such file or directory
4884 configure: error: ./configure failed for ghc</screen>
4888 <listitem> <para><command>autoreconf</command> seems to create the file <filename>configure</filename>
4889 read-only. So if you need to run autoreconf again (which I sometimes do for safety's sake),
4891 <screen>/usr/bin/autoconf: cannot create configure: permission denied</screen>
4892 Solution: delete <filename>configure</filename> first.
4897 After <command>autoreconf</command> run <command>./configure</command> in
4898 <filename>fptools/</filename> thus:
4900 <screen>$ ./configure --host=i386-unknown-mingw32 --with-gcc=c:/mingw/bin/gcc</screen>
4901 This is the point at which you specify that you are building GHC-mingw
4902 (see <xref linkend="ghc-mingw"/>). </para>
4904 <para> Both these options are important! It's possible to get into
4905 trouble using the wrong C compiler!</para>
4907 Furthermore, it's <emphasis>very important</emphasis> that you specify a
4908 full MinGW path for <command>gcc</command>, not a Cygwin path, because GHC (which
4909 uses this path to invoke <command>gcc</command>) is a MinGW program and won't
4910 understand a Cygwin path. For example, if you
4911 say <literal>--with-gcc=/mingw/bin/gcc</literal>, it'll be interpreted as
4912 <filename>/cygdrive/c/mingw/bin/gcc</filename>, and GHC will fail the first
4913 time it tries to invoke it. Worse, the failure comes with
4914 no error message whatsoever. GHC simply fails silently when first invoked,
4915 typically leaving you with this:
4916 <screen>make[4]: Leaving directory `/cygdrive/e/fptools-stage1/ghc/rts/gmp'
4917 ../../ghc/compiler/ghc-inplace -optc-mno-cygwin -optc-O
4918 -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes
4919 -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
4920 -optc-Wbad-function-cast -optc-Wcast-align -optc-I../includes
4921 -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS
4922 -optc-fomit-frame-pointer -O2 -static
4923 -package-name rts -O -dcore-lint -c Adjustor.c -o Adjustor.o
4924 make[2]: *** [Adjustor.o] Error 1
4925 make[1]: *** [all] Error 1
4926 make[1]: Leaving directory `/cygdrive/e/fptools-stage1/ghc'
4927 make: *** [all] Error 1</screen>
4932 If you want to build GHC-cygwin (<xref linkend="ghc-cygwin"/>)
4933 you'll have to do something more like:
4934 <screen>$ ./configure --with-gcc=...the Cygwin gcc...</screen>
4939 If you are paranoid, delete <filename>config.cache</filename> if it exists.
4940 This file occasionally remembers out-of-date configuration information, which
4941 can be really confusing.
4945 <listitem><para> You almost certainly want to set
4946 <programlisting>SplitObjs = NO</programlisting>
4947 in your <filename>build.mk</filename> configuration file (see <xref linkend="sec-build-config"/>).
4948 This tells the build system not to split each library into a myriad of little object files, one
4949 for each function. Doing so reduces binary sizes for statically-linked binaries, but on Windows
4950 it dramatically increases the time taken to build the libraries in the first place.
4954 <listitem><para> Do not attempt to build the documentation.
4955 It needs all kinds of wierd Jade stuff that we haven't worked out for
4956 Win32.</para></listitem>
4961 <sect2><title>A Windows build log using Cygwin</title>
4963 <para>Here is a complete, from-scratch, log of all you need to build GHC using
4964 Cygwin, kindly provided by Claus Reinke. It does not discuss alternative
4965 choices, but it gives a single path that works.</para>
4966 <programlisting>- Install some editor (vim, emacs, whatever)
4968 - Install cygwin (http://www.cygwin.com)
4969 ; i used 1.5.16-1, installed in c:\cygwin
4971 Choose a Download Source:
4972 select 'download from internet';
4973 Select Root Install Directory:
4974 root dir: c:\cygwin;
4975 install for: all users;
4976 default file type: unix
4977 Select Local Package Directory
4978 choose a spare temporary home
4979 Select Your Internet Connection
4981 Choose a Download Site
4982 Choose your preferred main mirror and
4983 Add 'http://www.haskell.org/ghc/cygwin'
4985 In addition to 'Base' (default install),
4986 select 'Devel->ghc-depends'
4988 - Install mingw (http://www.mingw.org/)
4989 ; i used MinGW-3.1.0-1.exe
4990 ; installed in c:\mingw
4991 - you probably want to add GLUT
4992 ; (http://www.xmission.com/~nate/glut.html)
4993 ; i used glut-3.7.3-mingw32.tar
4995 - Get recent binary snapshot of ghc-6.4.1 for mingw
4996 ; (http://www.haskell.org/ghc/dist/stable/dist/)
4998 - add C:\ghc\ghc-6.4.1\bin to %PATH%
4999 (Start->Control Panel->System->Advanced->Environment Variables)
5001 - Get cvs version of ghc
5002 ; also, subscribe to cvs-all@haskell.org, or follow the mailing list
5003 ; archive, in case you checkout a version with problems
5004 ; http://www.haskell.org//pipermail/cvs-all/
5005 - mkdir c:/fptools; cd c:/fptools
5006 ; (or whereever you want your cvs tree to be)
5007 - export CVSROOT=:pserver:anoncvs@cvs.haskell.org:/cvs
5010 - cvs checkout fpconfig
5012 - cvs checkout ghc hslibs libraries
5014 - Build ghc, using cygwin and mingw, targetting mingw
5015 - export PATH=/cygdrive/c/ghc/ghc-6.4.1:$PATH
5016 ; for haddock, alex, happy (*)
5017 - export PATH=/cygdrive/c/mingw/bin:$PATH
5018 ; without, we pick up some cygwin tools at best!
5019 - cd c:/fptools/fptools
5020 ; (if you aren't there already)
5022 - ./configure --host=i386-unknown-mingw32 --with-gcc=C:/Mingw/bin/gcc.exe
5023 ; we use cygwin, but build for windows
5024 - cp mk/build.mk.sample mk/build.mk
5026 add line: SplitObjs = NO
5027 (MSYS seems slow when there are zillions of object files)
5028 uncomment line: BuildFlavour = perf
5029 (or BuildFlavour = devel, if you are doing development)
5030 add line: BIN_DIST=1
5031 - make 2>&1 | tee make.log
5032 ; always useful to have a log around
5034 - Package up binary distribution
5035 - make binary-dist Project=Ghc 2>&1 | tee make-bin-dist.log
5036 ; always useful to have a log around
5038 - chmod +x ../distrib/prep-bin-dist-mingw
5039 ; if you're happy with the script's contents (*)
5040 - ../distrib/prep-bin-dist-mingw
5041 ; then tar up, unpack where wanted, and enjoy</programlisting>
projects / ghc-hetmet.git / blob