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 "../../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 darcs repository.<indexterm><primary>darcs 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 darcs repository.</para>
68 <para>Information on accessing the darcs repository is on
70 url="http://hackage.haskell.org/trac/ghc/wiki/GhcDarcs"
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 darcs you will need to install every utility
76 so that you can build all the derived files from
83 <sect1 id="sec-build-checks">
84 <title>Things to check before you start</title>
86 <para>Here's a list of things to check before you get
91 <listitem><para><indexterm><primary>Disk space needed</primary></indexterm>Disk
92 space needed: from about 100Mb for a basic GHC
93 build, up to probably 500Mb for a GHC build with everything
94 included (libraries built several different ways,
99 <para>Use an appropriate machine / operating system. <xref
100 linkend="sec-port-info"/> lists the supported platforms; if
101 yours isn't amongst these then you can try porting GHC (see
102 <xref linkend="sec-porting-ghc"/>).</para>
106 <para>Be sure that the “pre-supposed” utilities are
107 installed. <xref linkend="sec-pre-supposed"/>
112 <para>If you have any problem when building or installing the
113 Glasgow tools, please check the “known pitfalls” (<xref
114 linkend="sec-build-pitfalls"/>). Also check the FAQ for the
115 version you're building, which is part of the User's Guide and
116 available on the <ulink url="http://www.haskell.org/ghc/" >GHC web
119 <indexterm><primary>bugs</primary><secondary>known</secondary></indexterm>
121 <para>If you feel there is still some shortcoming in our
122 procedure or instructions, please report it.</para>
124 <para>For GHC, please see the <ulink
125 url="http://www.haskell.org/ghc/docs/latest/set/bug-reporting.html">bug-reporting
126 section of the GHC Users' Guide</ulink>, to maximise the
127 usefulness of your report.</para>
129 <indexterm><primary>bugs</primary><secondary>seporting</secondary></indexterm>
130 <para>If in doubt, please send a message to
131 <email>glasgow-haskell-bugs@haskell.org</email>.
132 <indexterm><primary>bugs</primary><secondary>mailing
133 list</secondary></indexterm></para>
138 <sect1 id="sec-port-info">
139 <title>What machines GHC runs on</title>
141 <indexterm><primary>ports</primary><secondary>GHC</secondary></indexterm>
142 <indexterm><primary>GHC</primary><secondary>ports</secondary></indexterm>
143 <indexterm><primary>platforms</primary><secondary>supported</secondary></indexterm>
145 <para>A “platform” is a
146 architecture/manufacturer/operating-system combination, such as
147 <literal>sparc-sun-solaris2</literal>. Other common ones are
148 <literal>alpha-dec-osf2</literal>,
149 <literal>hppa1.1-hp-hpux9</literal>,
150 <literal>i386-unknown-linux</literal>,
151 <literal>i386-unknown-solaris2</literal>,
152 <literal>i386-unknown-freebsd</literal>,
153 <literal>i386-unknown-cygwin32</literal>,
154 <literal>m68k-sun-sunos4</literal>,
155 <literal>mips-sgi-irix5</literal>,
156 <literal>sparc-sun-sunos4</literal>,
157 <literal>sparc-sun-solaris2</literal>,
158 <literal>powerpc-ibm-aix</literal>.</para>
160 <para>Some libraries may only work on a limited number of
161 platforms; for example, a sockets library is of no use unless the
162 operating system supports the underlying BSDisms.</para>
164 <indexterm><primary>fully-supported platforms</primary></indexterm>
165 <indexterm><primary>native-code generator</primary></indexterm>
166 <indexterm><primary>registerised ports</primary></indexterm>
167 <indexterm><primary>unregisterised ports</primary></indexterm>
169 <para>The GHC hierarchy of Porting Goodness: (a) Best is a
170 native-code generator; (b) next best is a
171 “registerised” port; (c) the bare minimum is an
172 “unregisterised” port.
173 (“Unregisterised” is so terrible that we won't say
174 more about it).</para>
176 <para>Here's everything that's known about GHC ports. We
177 identify platforms by their “canonical”
178 CPU/Manufacturer/OS triple.</para>
182 <term>alpha-dec-{osf,linux,freebsd,openbsd,netbsd}:
183 <indexterm><primary>alpha-dec-osf</primary></indexterm>
184 <indexterm><primary>alpha-dec-linux</primary></indexterm>
185 <indexterm><primary>alpha-dec-freebsd</primary></indexterm>
186 <indexterm><primary>alpha-dec-openbsd</primary></indexterm>
187 <indexterm><primary>alpha-dec-netbsd</primary></indexterm>
190 <para>The OSF port is currently working (as of GHC version
191 5.02.1) and well supported. The native code generator is
192 currently non-working. Other operating systems will
193 require some minor porting.</para>
198 <term>sparc-sun-sunos4
199 <indexterm><primary>sparc-sun-sunos4</primary></indexterm>
202 <para>Probably works with minor tweaks, hasn't been tested
208 <term>sparc-sun-solaris2
209 <indexterm><primary>sparc-sun-solaris2</primary></indexterm>
212 <para>Fully supported (at least for Solaris 2.7 and 2.6),
213 including native-code generator.</para>
218 <term>sparc-unknown-openbsd
219 <indexterm><primary>sparc-unknown-openbsd</primary></indexterm>
222 <para>Supported, including native-code generator. The
223 same should also be true of NetBSD</para>
228 <term>hppa1.1-hp-hpux (HP-PA boxes running HPUX 9.x)
229 <indexterm><primary>hppa1.1-hp-hpux</primary></indexterm>
232 <para>A registerised port is available for version 4.08,
233 but GHC hasn't been built on that platform since (as far
234 as we know). No native-code generator.</para>
239 <term>i386-unknown-linux (PCs running Linux, ELF binary format)
240 <indexterm><primary>i386-*-linux</primary></indexterm>
243 <para>GHC works registerised and has a native code
244 generator. You <emphasis>must</emphasis> have GCC 2.7.x
245 or later. NOTE about <literal>glibc</literal> versions:
246 GHC binaries built on a system running <literal>glibc
247 2.0</literal> won't work on a system running
248 <literal>glibc 2.1</literal>, and vice versa. In general,
249 don't expect compatibility between
250 <literal>glibc</literal> versions, even if the shared
251 library version hasn't changed.</para>
256 <term>i386-unknown-freebsd (PCs running FreeBSD 2.2 or higher)
257 <indexterm><primary>i386-unknown-freebsd</primary></indexterm>
260 <para>GHC works registerised. Pre-built packages are
261 available in the native package format, so if you just
262 need binaries you're better off just installing the
263 package (it might even be on your installation
269 <term>i386-unknown-openbsd (PCs running OpenBSD)
270 <indexterm><primary>i386-unknown-openbsd</primary></indexterm>
273 <para>Supported, with native code generator. Packages are
274 available through the ports system in the native package
280 <term>i386-unknown-netbsd (PCs running NetBSD)
281 <indexterm><primary>i386-unknown-netbsd</primary></indexterm>
284 <para>Will require some minor porting effort, but should
285 work registerised.</para>
290 <term>i386-unknown-mingw32 (PCs running Windows)
291 <indexterm><primary>i386-unknown-mingw32</primary></indexterm>
294 <para>Fully supported under Win9x, WinNT, Win2k, and
295 WinXP. Includes a native code generator. Building from
296 source requires a recent <ulink
297 url="http://www.cygwin.com/">Cygwin</ulink> distribution
298 to be installed.</para>
303 <term>ia64-unknown-linux
304 <indexterm><primary>ia64-unknown-linux</primary></indexterm>
307 <para>Supported, except there is no native code
313 <term>x86_64-unknown-linux
314 <indexterm><primary>x86_64-unknown-linux</primary></indexterm>
316 <term>amd64-unknown-openbsd
317 <indexterm><primary>amd64-unknown-linux</primary></indexterm>
320 <para>Fully supported, with a native code generator and GHCi.</para>
326 <indexterm><primary>mips-sgi-irix[5-6]</primary></indexterm>
329 <para>Port has worked in the past, but hasn't been tested
330 for some time (and will certainly have rotted in various
331 ways). As usual, we don't have access to machines and
332 there hasn't been an overwhelming demand for this port,
333 but feel free to get in touch.</para>
338 <term>mips64-sgi-irix6
339 <indexterm><primary>mips-sgi-irix6</primary></indexterm>
342 <para>GHC currently works unregisterised.</para>
347 <term>powerpc-ibm-aix
348 <indexterm><primary>powerpc-ibm-aix</primary></indexterm>
351 <para>Port currently doesn't work, needs some minimal
352 porting effort. As usual, we don't have access to
353 machines and there hasn't been an overwhelming demand for
354 this port, but feel free to get in touch.</para>
359 <term>powerpc-apple-darwin
360 <indexterm><primary>powerpc-apple-darwin</primary></indexterm>
363 <para>Supported registerised. Native code generator is
364 almost working.</para>
369 <term>powerpc-apple-linux
370 <indexterm><primary>powerpc-apple-linux</primary></indexterm>
373 <para>Not supported (yet).</para>
378 <para>Various other systems have had GHC ported to them in the
379 distant past, including various Motorola 68k boxes. The 68k
380 support still remains, but porting to one of these systems will
381 certainly be a non-trivial task.</para>
384 <sect1 id="sec-pre-supposed">
385 <title>Installing pre-supposed utilities</title>
387 <indexterm><primary>pre-supposed utilities</primary></indexterm>
388 <indexterm><primary>utilities, pre-supposed</primary></indexterm>
390 <para>Here are the gory details about some utility programs you
391 may need; <command>perl</command>, <command>gcc</command> and
392 <command>happy</command> are the only important
393 ones. (PVM<indexterm><primary>PVM</primary></indexterm> is
394 important if you're going for Parallel Haskell.) The
395 <command>configure</command><indexterm><primary>configure</primary></indexterm>
396 script will tell you if you are missing something.</para>
402 <indexterm><primary>pre-supposed: GHC</primary></indexterm>
403 <indexterm><primary>GHC, pre-supposed</primary></indexterm>
406 <para>GHC is required to build many of the tools, including
407 GHC itself. If you need to port GHC to your platform
408 because there isn't a binary distribution of GHC available,
409 then see <xref linkend="sec-porting-ghc"/>.</para>
411 <para>Which version of GHC you need will depend on the
412 packages you intend to build. GHC itself will normally
413 build using one of several older versions of itself - check
414 the announcement or release notes for details.</para>
420 <indexterm><primary>pre-supposed: Perl</primary></indexterm>
421 <indexterm><primary>Perl, pre-supposed</primary></indexterm>
424 <para><emphasis>You have to have Perl to proceed!</emphasis>
425 Perl version 5 at least is required. GHC has been known to
426 tickle bugs in Perl, so if you find that Perl crashes when
427 running GHC try updating (or downgrading) your Perl
428 installation. Versions of Perl before 5.6 have been known to have
429 various bugs tickled by GHC, so the configure script
430 will look for version 5.6 or later.</para>
432 <para>For Win32 platforms, you should use the binary
433 supplied in the InstallShield (copy it to
434 <filename>/bin</filename>). The Cygwin-supplied Perl seems
437 <para>Perl should be put somewhere so that it can be invoked
438 by the <literal>#!</literal> script-invoking
439 mechanism. The full pathname may need to be less than 32
440 characters long on some systems.</para>
445 <term>GNU C (<command>gcc</command>)
446 <indexterm><primary>pre-supposed: GCC (GNU C compiler)</primary></indexterm>
447 <indexterm><primary>GCC (GNU C compiler), pre-supposed</primary></indexterm>
450 <para>Most GCC versions should work with the most recent GHC
451 sources. Expect trouble if you use a recent GCC with
452 an older GHC, though (trouble in the form of mis-compiled code,
453 link errors, and errors from the <literal>ghc-asm</literal>
456 <para>If your GCC dies with “internal error” on
457 some GHC source file, please let us know, so we can report
458 it and get things improved. (Exception: on x86
459 boxes—you may need to fiddle with GHC's
460 <option>-monly-N-regs</option> option; see the User's
467 <indexterm><primary>make</primary><secondary>GNU</secondary></indexterm>
470 <para>The fptools build system makes heavy use of features
471 specific to GNU <command>make</command>, so you must have
472 this installed in order to build any of the fptools
475 <para>NB. it has been reported that version 3.79 no longer
476 works to build GHC, and 3.80 is required.</para>
481 <term><ulink url="http://www.haskell.org/happy">Happy</ulink>
482 <indexterm><primary>Happy</primary></indexterm>
485 <para>Happy is a parser generator tool for Haskell, and is
486 used to generate GHC's parsers.</para>
488 <para>If you start from a source tarball of GHC (i.e. not a darcs
489 checkout), then you don't need Happy, because we supply the
490 pre-processed versions of the Happy parsers. If you intend to
491 modify the compiler and/or you're using a darcs checkout, then you
494 <para>Happy version 1.15 is currently required to build GHC.</para>
496 <para>Happy is written in
497 Haskell, and is a project in the CVS repository
498 (<literal>fptools/happy</literal>). It can be built from
499 source, but bear in mind that you'll need GHC installed in
500 order to build it. To avoid the chicken/egg problem,
501 install a binary distribution of either Happy or GHC to get
502 started. Happy distributions are available from <ulink url="http://www.haskell.org/happy/">Happy's Web
509 <indexterm><primary>Alex</primary></indexterm>
512 <para>Alex is a lexical-analyser generator for Haskell,
513 which GHC uses to generate its lexer.</para>
515 <para>Like Happy, you don't need Alex if you're building GHC from a
516 source tarball, but you do need it if you're modifying GHC and/or
517 building a darcs checkout.</para>
520 written in Haskell and is a project in the darcs repository.
521 Alex distributions are available from <ulink url="http://www.haskell.org/alex/">Alex's Web
528 <indexterm><primary>pre-supposed: autoconf</primary></indexterm>
529 <indexterm><primary>autoconf, pre-supposed</primary></indexterm>
532 <para>GNU autoconf is needed if you intend to build from the
533 darcs sources, it is <emphasis>not</emphasis> needed if you
534 just intend to build a standard source distribution.</para>
536 <para>Version 2.52 or later of the autoconf package is required.
537 NB. version 2.13 will no longer work, as of GHC version
540 <para><command>autoreconf</command> (from the autoconf package)
541 recursively builds <command>configure</command> scripts from
542 the corresponding <filename>configure.ac</filename> and
543 <filename>aclocal.m4</filename> files. If you modify one of
544 the latter files, you'll need <command>autoreconf</command> to
545 rebuild the corresponding <filename>configure</filename>.</para>
550 <term><command>sed</command>
551 <indexterm><primary>pre-supposed: sed</primary></indexterm>
552 <indexterm><primary>sed, pre-supposed</primary></indexterm>
555 <para>You need a working <command>sed</command> if you are
556 going to build from sources. The build-configuration stuff
557 needs it. GNU sed version 2.0.4 is no good! It has a bug
558 in it that is tickled by the build-configuration. 2.0.5 is
559 OK. Others are probably OK too (assuming we don't create too
560 elaborate configure scripts.)</para>
565 <para>One <literal>fptools</literal> project is worth a quick note
566 at this point, because it is useful for all the others:
567 <literal>glafp-utils</literal> contains several utilities which
568 aren't particularly Glasgow-ish, but Occasionally Indispensable.
569 Like <command>lndir</command> for creating symbolic link
572 <sect2 id="pre-supposed-gph-tools">
573 <title>Tools for building parallel GHC (GPH)</title>
578 <indexterm><primary>pre-supposed: PVM3 (Parallel Virtual Machine)</primary></indexterm>
579 <indexterm><primary>PVM3 (Parallel Virtual Machine), pre-supposed</primary></indexterm>
582 <para>PVM is the Parallel Virtual Machine on which
583 Parallel Haskell programs run. (You only need this if you
584 plan to run Parallel Haskell. Concurrent Haskell, which
585 runs concurrent threads on a uniprocessor doesn't need
586 it.) Underneath PVM, you can have (for example) a network
587 of workstations (slow) or a multiprocessor box
590 <para>The current version of PVM is 3.3.11; we use 3.3.7.
591 It is readily available on the net; I think I got it from
592 <literal>research.att.com</literal>, in
593 <filename>netlib</filename>.</para>
595 <para>A PVM installation is slightly quirky, but easy to
596 do. Just follow the <filename>Readme</filename>
602 <term><command>bash</command>:
603 <indexterm><primary>bash, presupposed (Parallel Haskell only)</primary></indexterm>
606 <para>Sadly, the <command>gr2ps</command> script, used to
607 convert “parallelism profiles” to PostScript,
608 is written in Bash (GNU's Bourne Again shell). This bug
609 will be fixed (someday).</para>
615 <sect2 id="pre-supposed-other-tools">
616 <title>Other useful tools</title>
621 <indexterm><primary>pre-supposed: flex</primary></indexterm>
622 <indexterm><primary>flex, pre-supposed</primary></indexterm>
625 <para>This is a quite-a-bit-better-than-Lex lexer. Used
626 to build a couple of utilities in
627 <literal>glafp-utils</literal>. Depending on your
628 operating system, the supplied <command>lex</command> may
629 or may not work; you should get the GNU version.</para>
634 <para>More tools are required if you want to format the documentation
635 that comes with GHC and other fptools projects. See <xref
636 linkend="building-docs"/>.</para>
640 <sect1 id="sec-building-from-source">
641 <title>Building from source</title>
643 <indexterm><primary>Building from source</primary></indexterm>
644 <indexterm><primary>Source, building from</primary></indexterm>
646 <para>“I just want to build it!”</para>
648 <para>No problem. This recipe should build and install a working GHC with
649 all the default settings. (unless you're
650 on Windows, in which case go to <xref linkend="winbuild" />).</para>
652 <screen>$ autoreconf<footnote><para>not necessary if you started from a source tarball</para>
656 $ make install</screen>
658 <para>For GHC, this will do a 2-stage bootstrap build of the
659 compiler, with profiling libraries, and install the
660 results in the default location (under <filename>/usr/local</filename> on
661 Unix, for example).</para>
663 <para>The <literal>configure</literal> script is a standard GNU
664 <literal>autoconf</literal> script, and accepts the usual options for
665 changing install locations and the like. Run
666 <literal>./configure --help</literal> for a list of options.</para>
668 <para>If you want to do anything at all non-standard, or you
669 want to do some development, read on...</para>
672 <sect1 id="quick-start">
673 <title>Quick start for GHC developers</title>
675 <para>This section is a copy of the file
676 <literal>ghc/HACKING</literal> from the GHC source tree. It describes
677 how to get started with setting up your build tree for developing GHC
678 or its libraries, and how to start building.</para>
685 <sect1 id="sec-working-with-the-build-system">
686 <title>Working with the build system</title>
688 <para>This rest of this guide is intended for duffers like me, who
689 aren't really interested in Makefiles and systems configurations,
690 but who need a mental model of the interlocking pieces so that
691 they can make them work, extend them consistently when adding new
692 software, and lay hands on them gently when they don't
695 <sect2 id="sec-source-tree">
696 <title>Your source tree</title>
698 <para>The source code is held in your <emphasis>source
699 tree</emphasis>. The root directory of your source tree
700 <emphasis>must</emphasis> contain the following directories and
705 <para><filename>Makefile</filename>: the root
710 <para><filename>mk/</filename>: the directory that contains
711 the main Makefile code, shared by all the
712 <literal>fptools</literal> software.</para>
716 <para><filename>configure.ac</filename>,
717 <filename>config.sub</filename>,
718 <filename>config.guess</filename>: these files support the
719 configuration process.</para>
723 <para><filename>install-sh</filename>.</para>
727 <para>All the other directories are individual
728 <emphasis>projects</emphasis> of the <literal>fptools</literal>
729 system—for example, the Glasgow Haskell Compiler
730 (<literal>ghc</literal>), the Happy parser generator
731 (<literal>happy</literal>), the <literal>nofib</literal>
732 benchmark suite, and so on. You can have zero or more of these.
733 Needless to say, some of them are needed to build others.</para>
735 <para>The important thing to remember is that even if you want
736 only one project (<literal>happy</literal>, say), you must have
737 a source tree whose root directory contains
738 <filename>Makefile</filename>, <filename>mk/</filename>,
739 <filename>configure.ac</filename>, and the project(s) you want
740 (<filename>happy/</filename> in this case). You cannot get by
741 with just the <filename>happy/</filename> directory.</para>
745 <title>Build trees</title>
746 <indexterm><primary>build trees</primary></indexterm>
747 <indexterm><primary>link trees, for building</primary></indexterm>
749 <para>If you just want to build the software once on a single
750 platform, then your source tree can also be your build tree, and
751 you can skip the rest of this section.</para>
753 <para>We often want to build multiple versions of our software
754 for different architectures, or with different options
755 (e.g. profiling). It's very desirable to share a single copy of
756 the source code among all these builds.</para>
758 <para>So for every source tree we have zero or more
759 <emphasis>build trees</emphasis>. Each build tree is initially
760 an exact copy of the source tree, except that each file is a
761 symbolic link to the source file, rather than being a copy of
762 the source file. There are “standard” Unix
763 utilities that make such copies, so standard that they go by
765 <command>lndir</command><indexterm><primary>lndir</primary></indexterm>,
766 <command>mkshadowdir</command><indexterm><primary>mkshadowdir</primary></indexterm>
767 are two (If you don't have either, the source distribution
768 includes sources for the X11
769 <command>lndir</command>—check out
770 <filename>fptools/glafp-utils/lndir</filename>). See <xref
771 linkend="sec-storysofar"/> for a typical invocation.</para>
773 <para>The build tree does not need to be anywhere near the
774 source tree in the file system. Indeed, one advantage of
775 separating the build tree from the source is that the build tree
776 can be placed in a non-backed-up partition, saving your systems
777 support people from backing up untold megabytes of
778 easily-regenerated, and rapidly-changing, gubbins. The golden
779 rule is that (with a single exception—<xref
780 linkend="sec-build-config"/>) <emphasis>absolutely everything in
781 the build tree is either a symbolic link to the source tree, or
782 else is mechanically generated</emphasis>. It should be
783 perfectly OK for your build tree to vanish overnight; an hour or
784 two compiling and you're on the road again.</para>
786 <para>You need to be a bit careful, though, that any new files
787 you create (if you do any development work) are in the source
788 tree, not a build tree!</para>
790 <para>Remember, that the source files in the build tree are
791 <emphasis>symbolic links</emphasis> to the files in the source
792 tree. (The build tree soon accumulates lots of built files like
793 <filename>Foo.o</filename>, as well.) You can
794 <emphasis>delete</emphasis> a source file from the build tree
795 without affecting the source tree (though it's an odd thing to
796 do). On the other hand, if you <emphasis>edit</emphasis> a
797 source file from the build tree, you'll edit the source-tree
798 file directly. (You can set up Emacs so that if you edit a
799 source file from the build tree, Emacs will silently create an
800 edited copy of the source file in the build tree, leaving the
801 source file unchanged; but the danger is that you think you've
802 edited the source file whereas actually all you've done is edit
803 the build-tree copy. More commonly you do want to edit the
806 <para>Like the source tree, the top level of your build tree
807 must be (a linked copy of) the root directory of the
808 <literal>fptools</literal> suite. Inside Makefiles, the root of
809 your build tree is called
810 <constant>$(FPTOOLS_TOP)</constant><indexterm><primary>FPTOOLS_TOP</primary></indexterm>.
811 In the rest of this document path names are relative to
812 <constant>$(FPTOOLS_TOP)</constant> unless
813 otherwise stated. For example, the file
814 <filename>ghc/mk/target.mk</filename> is actually
815 <filename>$(FPTOOLS_TOP)/ghc/mk/target.mk</filename>.</para>
818 <sect2 id="sec-build-config">
819 <title>Getting the build you want</title>
821 <para>When you build <literal>fptools</literal> you will be
822 compiling code on a particular <emphasis>host
823 platform</emphasis>, to run on a particular <emphasis>target
824 platform</emphasis> (usually the same as the host
825 platform)<indexterm><primary>platform</primary></indexterm>.
826 The difficulty is that there are minor differences between
827 different platforms; minor, but enough that the code needs to be
828 a bit different for each. There are some big differences too:
829 for a different architecture we need to build GHC with a
830 different native-code generator.</para>
832 <para>There are also knobs you can turn to control how the
833 <literal>fptools</literal> software is built. For example, you
834 might want to build GHC optimised (so that it runs fast) or
835 unoptimised (so that you can compile it fast after you've
836 modified it. Or, you might want to compile it with debugging on
837 (so that extra consistency-checking code gets included) or off.
840 <para>All of this stuff is called the
841 <emphasis>configuration</emphasis> of your build. You set the
842 configuration using a three-step process.</para>
846 <term>Step 1: get ready for configuration.</term>
848 <para>NOTE: if you're starting from a source distribution,
849 rather than darcs sources, you can skip this step.</para>
851 <para>Change directory to
852 <constant>$(FPTOOLS_TOP)</constant> and
853 issue the command</para>
854 <screen>$ autoreconf</screen>
855 <indexterm><primary>autoreconf</primary></indexterm>
856 <para>(with no arguments). This GNU program (recursively) converts
857 <filename>$(FPTOOLS_TOP)/configure.ac</filename> and
858 <filename>$(FPTOOLS_TOP)/aclocal.m4</filename>
859 to a shell script called
860 <filename>$(FPTOOLS_TOP)/configure</filename>.
861 If <command>autoreconf</command> bleats that it can't write the file <filename>configure</filename>,
862 then delete the latter and try again. Note that you must use <command>autoreconf</command>,
863 and not the old <command>autoconf</command>! If you erroneously use the latter, you'll get
864 a message like "No rule to make target 'mk/config.h.in'".
867 <para>Some projects, including GHC, have their own configure script.
868 <command>autoreconf</command> takes care of that, too, so all you have
869 to do is calling <command>autoreconf</command> in the top-level directory
870 <filename>$(FPTOOLS_TOP)</filename>.</para>
872 <para>These steps are completely platform-independent; they just mean
873 that the human-written files (<filename>configure.ac</filename> and
874 <filename>aclocal.m4</filename>) can be short, although the resulting
875 files (the <command>configure</command> shell scripts and the C header
876 template <filename>mk/config.h.in</filename>) are long.</para>
881 <term>Step 2: system configuration.</term>
883 <para>Runs the newly-created <command>configure</command>
886 <screen>$ ./configure <optional><parameter>args</parameter></optional></screen>
888 <para><command>configure</command>'s mission is to scurry
889 round your computer working out what architecture it has,
890 what operating system, whether it has the
891 <function>vfork</function> system call, where
892 <command>tar</command> is kept, whether
893 <command>gcc</command> is available, where various obscure
894 <literal>#include</literal> files are, whether it's a
895 leap year, and what the systems manager had for lunch. It
896 communicates these snippets of information in two
903 <filename>mk/config.mk.in</filename><indexterm><primary>config.mk.in</primary></indexterm>
905 <filename>mk/config.mk</filename><indexterm><primary>config.mk</primary></indexterm>,
906 substituting for things between
907 “<literal>@</literal>” brackets. So,
908 “<literal>@HaveGcc@</literal>” will be
909 replaced by “<literal>YES</literal>” or
910 “<literal>NO</literal>” depending on what
911 <command>configure</command> finds.
912 <filename>mk/config.mk</filename> is included by every
913 Makefile (directly or indirectly), so the
914 configuration information is thereby communicated to
915 all Makefiles.</para>
920 <filename>mk/config.h.in</filename><indexterm><primary>config.h.in</primary></indexterm>
922 <filename>mk/config.h</filename><indexterm><primary>config.h</primary></indexterm>.
923 The latter is <literal>#include</literal>d by
924 various C programs, which can thereby make use of
925 configuration information.</para>
929 <para><command>configure</command> takes some optional
930 arguments. Use <literal>./configure --help</literal> to
931 get a list of the available arguments. Here are some of
932 the ones you might need:</para>
936 <term><literal>--with-ghc=<parameter>path</parameter></literal>
937 <indexterm><primary><literal>--with-ghc</literal></primary></indexterm>
940 <para>Specifies the path to an installed GHC which
941 you would like to use. This compiler will be used
942 for compiling GHC-specific code (eg. GHC itself).
943 This option <emphasis>cannot</emphasis> be specified
944 using <filename>build.mk</filename> (see later),
945 because <command>configure</command> needs to
946 auto-detect the version of GHC you're using. The
947 default is to look for a compiler named
948 <literal>ghc</literal> in your path.</para>
953 <term><literal>--with-hc=<parameter>path</parameter></literal>
954 <indexterm><primary><literal>--with-hc</literal></primary></indexterm>
957 <para>Specifies the path to any installed Haskell
958 compiler. This compiler will be used for compiling
959 generic Haskell code. The default is to use
960 <literal>ghc</literal>.</para>
965 <term><literal>--with-gcc=<parameter>path</parameter></literal>
966 <indexterm><primary><literal>--with-gcc</literal></primary></indexterm>
969 <para>Specifies the path to the installed GCC. This
970 compiler will be used to compile all C files,
971 <emphasis>except</emphasis> any generated by the
972 installed Haskell compiler, which will have its own
973 idea of which C compiler (if any) to use. The
974 default is to use <literal>gcc</literal>.</para>
982 <term>Step 3: build configuration.</term>
984 <para>Next, you say how this build of
985 <literal>fptools</literal> is to differ from the standard
986 defaults by creating a new file
987 <filename>mk/build.mk</filename><indexterm><primary>build.mk</primary></indexterm>
988 <emphasis>in the build tree</emphasis>. This file is the
989 one and only file you edit in the build tree, precisely
990 because it says how this build differs from the source.
991 (Just in case your build tree does die, you might want to
992 keep a private directory of <filename>build.mk</filename>
993 files, and use a symbolic link in each build tree to point
994 to the appropriate one.) So
995 <filename>mk/build.mk</filename> never exists in the
996 source tree—you create one in each build tree from
997 the template. We'll discuss what to put in it
1003 <para>And that's it for configuration. Simple, eh?</para>
1005 <para>What do you put in your build-specific configuration file
1006 <filename>mk/build.mk</filename>? <emphasis>For almost all
1007 purposes all you will do is put make variable definitions that
1008 override those in</emphasis>
1009 <filename>mk/config.mk.in</filename>. The whole point of
1010 <filename>mk/config.mk.in</filename>—and its derived
1011 counterpart <filename>mk/config.mk</filename>—is to define
1012 the build configuration. It is heavily commented, as you will
1013 see if you look at it. So generally, what you do is look at
1014 <filename>mk/config.mk.in</filename>, and add definitions in
1015 <filename>mk/build.mk</filename> that override any of the
1016 <filename>config.mk</filename> definitions that you want to
1017 change. (The override occurs because the main boilerplate file,
1018 <filename>mk/boilerplate.mk</filename><indexterm><primary>boilerplate.mk</primary></indexterm>,
1019 includes <filename>build.mk</filename> after
1020 <filename>config.mk</filename>.)</para>
1022 <para>For your convenience, there's a file called <filename>build.mk.sample</filename>
1023 that can serve as a starting point for your <filename>build.mk</filename>.</para>
1025 <para>For example, <filename>config.mk.in</filename> contains
1026 the definition:</para>
1028 <programlisting>GhcHcOpts=-O -Rghc-timing</programlisting>
1030 <para>The accompanying comment explains that this is the list of
1031 flags passed to GHC when building GHC itself. For doing
1032 development, it is wise to add <literal>-DDEBUG</literal>, to
1033 enable debugging code. So you would add the following to
1034 <filename>build.mk</filename>:</para>
1036 <para>or, if you prefer,</para>
1038 <programlisting>GhcHcOpts += -DDEBUG</programlisting>
1040 <para>GNU <command>make</command> allows existing definitions to
1041 have new text appended using the “<literal>+=</literal>”
1042 operator, which is quite a convenient feature.)</para>
1044 <para>If you want to remove the <literal>-O</literal> as well (a
1045 good idea when developing, because the turn-around cycle gets a
1046 lot quicker), you can just override
1047 <literal>GhcLibHcOpts</literal> altogether:</para>
1049 <programlisting>GhcHcOpts=-DDEBUG -Rghc-timing</programlisting>
1051 <para>When reading <filename>config.mk.in</filename>, remember
1052 that anything between “@...@” signs is going to be substituted
1053 by <command>configure</command> later. You
1054 <emphasis>can</emphasis> override the resulting definition if
1055 you want, but you need to be a bit surer what you are doing.
1056 For example, there's a line that says:</para>
1058 <programlisting>TAR = @TarCmd@</programlisting>
1060 <para>This defines the Make variables <constant>TAR</constant>
1061 to the pathname for a <command>tar</command> that
1062 <command>configure</command> finds somewhere. If you have your
1063 own pet <command>tar</command> you want to use instead, that's
1064 fine. Just add this line to <filename>mk/build.mk</filename>:</para>
1066 <programlisting>TAR = mytar</programlisting>
1068 <para>You do not <emphasis>have</emphasis> to have a
1069 <filename>mk/build.mk</filename> file at all; if you don't,
1070 you'll get all the default settings from
1071 <filename>mk/config.mk.in</filename>.</para>
1073 <para>You can also use <filename>build.mk</filename> to override
1074 anything that <command>configure</command> got wrong. One place
1075 where this happens often is with the definition of
1076 <constant>FPTOOLS_TOP_ABS</constant>: this
1077 variable is supposed to be the canonical path to the top of your
1078 source tree, but if your system uses an automounter then the
1079 correct directory is hard to find automatically. If you find
1080 that <command>configure</command> has got it wrong, just put the
1081 correct definition in <filename>build.mk</filename>.</para>
1085 <sect2 id="sec-storysofar">
1086 <title>The story so far</title>
1088 <para>Let's summarise the steps you need to carry to get
1089 yourself a fully-configured build tree from scratch.</para>
1093 <para> Get your source tree from somewhere (darcs repository
1094 or source distribution). Say you call the root directory
1095 <filename>myfptools</filename> (it does not have to be
1096 called <filename>fptools</filename>). Make sure that you
1097 have the essential files (see <xref
1098 linkend="sec-source-tree"/>).</para>
1103 <para>(Optional) Use <command>lndir</command> or
1104 <command>mkshadowdir</command> to create a build tree.</para>
1106 <screen>$ cd myfptools
1107 $ mkshadowdir . /scratch/joe-bloggs/myfptools-sun4</screen>
1109 <para>(N.B. <command>mkshadowdir</command>'s first argument
1110 is taken relative to its second.) You probably want to give
1111 the build tree a name that suggests its main defining
1112 characteristic (in your mind at least), in case you later
1117 <para>Change directory to the build tree. Everything is
1118 going to happen there now.</para>
1120 <screen>$ cd /scratch/joe-bloggs/myfptools-sun4</screen>
1125 <para>Prepare for system configuration:</para>
1127 <screen>$ autoreconf</screen>
1129 <para>(You can skip this step if you are starting from a
1130 source distribution, and you already have
1131 <filename>configure</filename> and
1132 <filename>mk/config.h.in</filename>.)</para>
1136 <para>Do system configuration:</para>
1138 <screen>$ ./configure</screen>
1140 <para>Don't forget to check whether you need to add any
1141 arguments to <literal>configure</literal>; for example, a
1142 common requirement is to specify which GHC to use with
1143 <option>--with-ghc=<replaceable>ghc</replaceable></option>.</para>
1147 <para>Create the file <filename>mk/build.mk</filename>,
1148 adding definitions for your desired configuration
1151 <screen>$ emacs mk/build.mk</screen>
1155 <para>You can make subsequent changes to
1156 <filename>mk/build.mk</filename> as often as you like. You do
1157 not have to run any further configuration programs to make these
1158 changes take effect. In theory you should, however, say
1159 <command>gmake clean</command>, <command>gmake all</command>,
1160 because configuration option changes could affect
1161 anything—but in practice you are likely to know what's
1166 <title>Making things</title>
1168 <para>At this point you have made yourself a fully-configured
1169 build tree, so you are ready to start building real
1172 <para>The first thing you need to know is that <emphasis>you
1173 must use GNU <command>make</command>, usually called
1174 <command>gmake</command>, not standard Unix
1175 <command>make</command></emphasis>. If you use standard Unix
1176 <command>make</command> you will get all sorts of error messages
1177 (but no damage) because the <literal>fptools</literal>
1178 <command>Makefiles</command> use GNU <command>make</command>'s
1179 facilities extensively.</para>
1181 <para>To just build the whole thing, <command>cd</command> to
1182 the top of your <literal>fptools</literal> tree and type
1183 <command>gmake</command>. This will prepare the tree and build
1184 the various projects in the correct order.</para>
1187 <sect2 id="sec-bootstrapping">
1188 <title>Bootstrapping GHC</title>
1190 <para>GHC requires a 2-stage bootstrap in order to provide
1191 full functionality, including GHCi. By a 2-stage bootstrap, we
1192 mean that the compiler is built once using the installed GHC,
1193 and then again using the compiler built in the first stage. You
1194 can also build a stage 3 compiler, but this normally isn't
1195 necessary except to verify that the stage 2 compiler is working
1198 <para>Note that when doing a bootstrap, the stage 1 compiler
1199 must be built, followed by the runtime system and libraries, and
1200 then the stage 2 compiler. The correct ordering is implemented
1201 by the top-level fptools <filename>Makefile</filename>, so if
1202 you want everything to work automatically it's best to start
1203 <command>make</command> from the top of the tree. When building
1204 GHC, the top-level fptools <filename>Makefile</filename> is set
1205 up to do a 2-stage bootstrap by default (when you say
1206 <command>make</command>). Some other targets it supports
1213 <para>Build everything as normal, including the stage 1
1221 <para>Build the stage 2 compiler only.</para>
1228 <para>Build the stage 3 compiler only.</para>
1233 <term>bootstrap</term> <term>bootstrap2</term>
1235 <para>Build stage 1 followed by stage 2.</para>
1240 <term>bootstrap3</term>
1242 <para>Build stages 1, 2 and 3.</para>
1247 <term>install</term>
1249 <para>Install everything, including the compiler built in
1250 stage 2. To override the stage, say <literal>make install
1251 stage=<replaceable>n</replaceable></literal> where
1252 <replaceable>n</replaceable> is the stage to install.</para>
1257 <para>The top-level <filename>Makefile</filename> also arranges
1258 to do the appropriate <literal>make boot</literal> steps (see
1259 below) before actually building anything.</para>
1261 <para>The <literal>stage1</literal>, <literal>stage2</literal>
1262 and <literal>stage3</literal> targets also work in the
1263 <literal>ghc/compiler</literal> directory, but don't forget that
1264 each stage requires its own <literal>make boot</literal> step:
1265 for example, you must do</para>
1267 <screen>$ make boot stage=2</screen>
1269 <para>before <literal>make stage2</literal> in
1270 <literal>ghc/compiler</literal>.</para>
1273 <sect2 id="sec-standard-targets">
1274 <title>Standard Targets</title>
1275 <indexterm><primary>targets, standard makefile</primary></indexterm>
1276 <indexterm><primary>makefile targets</primary></indexterm>
1278 <para>In any directory you should be able to make the following:</para>
1282 <term><literal>boot</literal></term>
1284 <para>does the one-off preparation required to get ready
1285 for the real work. Notably, it does <command>gmake
1286 depend</command> in all directories that contain programs.
1287 It also builds the necessary tools for compilation to
1290 <para>Invoking the <literal>boot</literal> target
1291 explicitly is not normally necessary. From the top-level
1292 <literal>fptools</literal> directory, invoking
1293 <literal>gmake</literal> causes <literal>gmake boot
1294 all</literal> to be invoked in each of the project
1295 subdirectories, in the order specified by
1296 <literal>$(AllTargets)</literal> in
1297 <literal>config.mk</literal>.</para>
1299 <para>If you're working in a subdirectory somewhere and
1300 need to update the dependencies, <literal>gmake
1301 boot</literal> is a good way to do it.</para>
1306 <term><literal>all</literal></term>
1308 <para>makes all the final target(s) for this Makefile.
1309 Depending on which directory you are in a “final
1310 target” may be an executable program, a library
1311 archive, a shell script, or a Postscript file. Typing
1312 <command>gmake</command> alone is generally the same as
1313 typing <command>gmake all</command>.</para>
1318 <term><literal>install</literal></term>
1320 <para>installs the things built by <literal>all</literal>
1321 (except for the documentation). Where does it install
1322 them? That is specified by
1323 <filename>mk/config.mk.in</filename>; you can override it
1324 in <filename>mk/build.mk</filename>, or by running
1325 <command>configure</command> with command-line arguments
1326 like <literal>--bindir=/home/simonpj/bin</literal>; see
1327 <literal>./configure --help</literal> for the full
1333 <term><literal>install-docs</literal></term>
1335 <para>installs the documentation. Otherwise behaves just
1336 like <literal>install</literal>.</para>
1341 <term><literal>uninstall</literal></term>
1343 <para>reverses the effect of
1344 <literal>install</literal>.</para>
1349 <term><literal>clean</literal></term>
1351 <para>Delete all files from the current directory that are
1352 normally created by building the program. Don't delete
1353 the files that record the configuration, or files
1354 generated by <command>gmake boot</command>. Also preserve
1355 files that could be made by building, but normally aren't
1356 because the distribution comes with them.</para>
1361 <term><literal>distclean</literal></term>
1363 <para>Delete all files from the current directory that are
1364 created by configuring or building the program. If you
1365 have unpacked the source and built the program without
1366 creating any other files, <literal>make
1367 distclean</literal> should leave only the files that were
1368 in the distribution.</para>
1373 <term><literal>mostlyclean</literal></term>
1375 <para>Like <literal>clean</literal>, but may refrain from
1376 deleting a few files that people normally don't want to
1382 <term><literal>maintainer-clean</literal></term>
1384 <para>Delete everything from the current directory that
1385 can be reconstructed with this Makefile. This typically
1386 includes everything deleted by
1387 <literal>distclean</literal>, plus more: C source files
1388 produced by Bison, tags tables, Info files, and so
1391 <para>One exception, however: <literal>make
1392 maintainer-clean</literal> should not delete
1393 <filename>configure</filename> even if
1394 <filename>configure</filename> can be remade using a rule
1395 in the <filename>Makefile</filename>. More generally,
1396 <literal>make maintainer-clean</literal> should not delete
1397 anything that needs to exist in order to run
1398 <filename>configure</filename> and then begin to build the
1404 <term><literal>check</literal></term>
1406 <para>run the test suite.</para>
1411 <para>All of these standard targets automatically recurse into
1412 sub-directories. Certain other standard targets do not:</para>
1416 <term><literal>configure</literal></term>
1418 <para>is only available in the root directory
1419 <constant>$(FPTOOLS_TOP)</constant>; it has
1420 been discussed in <xref
1421 linkend="sec-build-config"/>.</para>
1426 <term><literal>depend</literal></term>
1428 <para>make a <filename>.depend</filename> file in each
1429 directory that needs it. This <filename>.depend</filename>
1430 file contains mechanically-generated dependency
1431 information; for example, suppose a directory contains a
1432 Haskell source module <filename>Foo.lhs</filename> which
1433 imports another module <literal>Baz</literal>. Then the
1434 generated <filename>.depend</filename> file will contain
1435 the dependency:</para>
1437 <programlisting>Foo.o : Baz.hi</programlisting>
1439 <para>which says that the object file
1440 <filename>Foo.o</filename> depends on the interface file
1441 <filename>Baz.hi</filename> generated by compiling module
1442 <literal>Baz</literal>. The <filename>.depend</filename>
1443 file is automatically included by every Makefile.</para>
1448 <term><literal>binary-dist</literal></term>
1450 <para>make a binary distribution. This is the target we
1451 use to build the binary distributions of GHC and
1457 <term><literal>dist</literal></term>
1459 <para>make a source distribution. Note that this target
1460 does “make distclean” as part of its work;
1461 don't use it if you want to keep what you've built.</para>
1466 <para>Most <filename>Makefile</filename>s have targets other
1467 than these. You can discover them by looking in the
1468 <filename>Makefile</filename> itself.</para>
1472 <title>Using a project from the build tree</title>
1474 <para>If you want to build GHC (say) and just use it direct from
1475 the build tree without doing <literal>make install</literal>
1476 first, you can run the in-place driver script:
1477 <filename>ghc/compiler/ghc-inplace</filename>.</para>
1479 <para> Do <emphasis>NOT</emphasis> use
1480 <filename>ghc/compiler/ghc</filename>, or
1481 <filename>ghc/compiler/ghc-6.xx</filename>, as these are the
1482 scripts intended for installation, and contain hard-wired paths
1483 to the installed libraries, rather than the libraries in the
1486 <para>Happy can similarly be run from the build tree, using
1487 <filename>happy/src/happy-inplace</filename>, and similarly for
1488 Alex and Haddock.</para>
1492 <title>Fast Making</title>
1494 <indexterm><primary>fastmake</primary></indexterm>
1495 <indexterm><primary>dependencies, omitting</primary></indexterm>
1496 <indexterm><primary>FAST, makefile variable</primary></indexterm>
1498 <para>Sometimes the dependencies get in the way: if you've made
1499 a small change to one file, and you're absolutely sure that it
1500 won't affect anything else, but you know that
1501 <command>make</command> is going to rebuild everything anyway,
1502 the following hack may be useful:</para>
1504 <screen>$ gmake FAST=YES</screen>
1506 <para>This tells the make system to ignore dependencies and just
1507 build what you tell it to. In other words, it's equivalent to
1508 temporarily removing the <filename>.depend</filename> file in
1509 the current directory (where <command>mkdependHS</command> and
1510 friends store their dependency information).</para>
1512 <para>A bit of history: GHC used to come with a
1513 <command>fastmake</command> script that did the above job, but
1514 GNU make provides the features we need to do it without
1515 resorting to a script. Also, we've found that fastmaking is
1516 less useful since the advent of GHC's recompilation checker (see
1517 the User's Guide section on "Separate Compilation").</para>
1521 <sect1 id="sec-makefile-arch">
1522 <title>The <filename>Makefile</filename> architecture</title>
1523 <indexterm><primary>makefile architecture</primary></indexterm>
1525 <para><command>make</command> is great if everything
1526 works—you type <command>gmake install</command> and lo! the
1527 right things get compiled and installed in the right places. Our
1528 goal is to make this happen often, but somehow it often doesn't;
1529 instead some weird error message eventually emerges from the
1530 bowels of a directory you didn't know existed.</para>
1532 <para>The purpose of this section is to give you a road-map to
1533 help you figure out what is going right and what is going
1537 <title>Debugging</title>
1539 <para>Debugging <filename>Makefile</filename>s is something of a
1540 black art, but here's a couple of tricks that we find
1541 particularly useful. The following command allows you to see
1542 the contents of any make variable in the context of the current
1543 <filename>Makefile</filename>:</para>
1545 <screen>$ make show VALUE=HS_SRCS</screen>
1547 <para>where you can replace <literal>HS_SRCS</literal> with the
1548 name of any variable you wish to see the value of.</para>
1550 <para>GNU make has a <option>-d</option> option which generates
1551 a dump of the decision procedure used to arrive at a conclusion
1552 about which files should be recompiled. Sometimes useful for
1553 tracking down problems with superfluous or missing
1554 recompilations.</para>
1558 <title>A small project</title>
1560 <para>To get started, let us look at the
1561 <filename>Makefile</filename> for an imaginary small
1562 <literal>fptools</literal> project, <literal>small</literal>.
1563 Each project in <literal>fptools</literal> has its own directory
1564 in <constant>FPTOOLS_TOP</constant>, so the
1565 <literal>small</literal> project will have its own directory
1566 <constant>FPOOLS_TOP/small/</constant>. Inside the
1567 <filename>small/</filename> directory there will be a
1568 <filename>Makefile</filename>, looking something like
1571 <indexterm><primary>Makefile, minimal</primary></indexterm>
1573 <programlisting># Makefile for fptools project "small"
1576 include $(TOP)/mk/boilerplate.mk
1578 SRCS = $(wildcard *.lhs) $(wildcard *.c)
1581 include $(TOP)/target.mk</programlisting>
1583 <para>this <filename>Makefile</filename> has three
1588 <para>The first section includes
1591 One of the most important
1592 features of GNU <command>make</command> that we use is the ability for a <filename>Makefile</filename> to
1593 include another named file, very like <command>cpp</command>'s <literal>#include</literal>
1598 a file of “boilerplate” code from the level
1599 above (which in this case will be
1600 <filename>FPTOOLS_TOP/mk/boilerplate.mk</filename><indexterm><primary>boilerplate.mk</primary></indexterm>).
1601 As its name suggests, <filename>boilerplate.mk</filename>
1602 consists of a large quantity of standard
1603 <filename>Makefile</filename> code. We discuss this
1604 boilerplate in more detail in <xref linkend="sec-boiler"/>.
1605 <indexterm><primary>include, directive in
1606 Makefiles</primary></indexterm> <indexterm><primary>Makefile
1607 inclusion</primary></indexterm></para>
1609 <para>Before the <literal>include</literal> statement, you
1610 must define the <command>make</command> variable
1611 <constant>TOP</constant><indexterm><primary>TOP</primary></indexterm>
1612 to be the directory containing the <filename>mk</filename>
1613 directory in which the <filename>boilerplate.mk</filename>
1614 file is. It is <emphasis>not</emphasis> OK to simply say</para>
1616 <programlisting>include ../mk/boilerplate.mk # NO NO NO</programlisting>
1619 <para>Why? Because the <filename>boilerplate.mk</filename>
1620 file needs to know where it is, so that it can, in turn,
1621 <literal>include</literal> other files. (Unfortunately,
1622 when an <literal>include</literal>d file does an
1623 <literal>include</literal>, the filename is treated relative
1624 to the directory in which <command>gmake</command> is being
1625 run, not the directory in which the
1626 <literal>include</literal>d sits.) In general,
1627 <emphasis>every file <filename>foo.mk</filename> assumes
1629 <filename>$(TOP)/mk/foo.mk</filename>
1630 refers to itself.</emphasis> It is up to the
1631 <filename>Makefile</filename> doing the
1632 <literal>include</literal> to ensure this is the case.</para>
1634 <para>Files intended for inclusion in other
1635 <filename>Makefile</filename>s are written to have the
1636 following property: <emphasis>after
1637 <filename>foo.mk</filename> is <literal>include</literal>d,
1638 it leaves <constant>TOP</constant> containing the same value
1639 as it had just before the <literal>include</literal>
1640 statement</emphasis>. In our example, this invariant
1641 guarantees that the <literal>include</literal> for
1642 <filename>target.mk</filename> will look in the same
1643 directory as that for <filename>boilerplate.mk</filename>.</para>
1647 <para> The second section defines the following standard
1648 <command>make</command> variables:
1649 <constant>SRCS</constant><indexterm><primary>SRCS</primary></indexterm>
1650 (the source files from which is to be built), and
1651 <constant>HS_PROG</constant><indexterm><primary>HS_PROG</primary></indexterm>
1652 (the executable binary to be built). We will discuss in
1653 more detail what the “standard variables” are,
1654 and how they affect what happens, in <xref
1655 linkend="sec-targets"/>.</para>
1657 <para>The definition for <constant>SRCS</constant> uses the
1658 useful GNU <command>make</command> construct
1659 <literal>$(wildcard $pat$)</literal><indexterm><primary>wildcard</primary></indexterm>,
1660 which expands to a list of all the files matching the
1661 pattern <literal>pat</literal> in the current directory. In
1662 this example, <constant>SRCS</constant> is set to the list
1663 of all the <filename>.lhs</filename> and
1664 <filename>.c</filename> files in the directory. (Let's
1665 suppose there is one of each, <filename>Foo.lhs</filename>
1666 and <filename>Baz.c</filename>.)</para>
1670 <para>The last section includes a second file of standard
1672 <filename>target.mk</filename><indexterm><primary>target.mk</primary></indexterm>.
1673 It contains the rules that tell <command>gmake</command> how
1674 to make the standard targets (<xref
1675 linkend="sec-standard-targets"/>). Why, you ask, can't this
1676 standard code be part of
1677 <filename>boilerplate.mk</filename>? Good question. We
1678 discuss the reason later, in <xref
1679 linkend="sec-boiler-arch"/>.</para>
1681 <para>You do not <emphasis>have</emphasis> to
1682 <literal>include</literal> the
1683 <filename>target.mk</filename> file. Instead, you can write
1684 rules of your own for all the standard targets. Usually,
1685 though, you will find quite a big payoff from using the
1686 canned rules in <filename>target.mk</filename>; the price
1687 tag is that you have to understand what canned rules get
1688 enabled, and what they do (<xref
1689 linkend="sec-targets"/>).</para>
1693 <para>In our example <filename>Makefile</filename>, most of the
1694 work is done by the two <literal>include</literal>d files. When
1695 you say <command>gmake all</command>, the following things
1700 <para><command>gmake</command> figures out that the object
1701 files are <filename>Foo.o</filename> and
1702 <filename>Baz.o</filename>.</para>
1706 <para>It uses a boilerplate pattern rule to compile
1707 <filename>Foo.lhs</filename> to <filename>Foo.o</filename>
1708 using a Haskell compiler. (Which one? That is set in the
1709 build configuration.)</para>
1713 <para>It uses another standard pattern rule to compile
1714 <filename>Baz.c</filename> to <filename>Baz.o</filename>,
1715 using a C compiler. (Ditto.)</para>
1719 <para>It links the resulting <filename>.o</filename> files
1720 together to make <literal>small</literal>, using the Haskell
1721 compiler to do the link step. (Why not use
1722 <command>ld</command>? Because the Haskell compiler knows
1723 what standard libraries to link in. How did
1724 <command>gmake</command> know to use the Haskell compiler to
1725 do the link, rather than the C compiler? Because we set the
1726 variable <constant>HS_PROG</constant> rather than
1727 <constant>C_PROG</constant>.)</para>
1731 <para>All <filename>Makefile</filename>s should follow the above
1732 three-section format.</para>
1736 <title>A larger project</title>
1738 <para>Larger projects are usually structured into a number of
1739 sub-directories, each of which has its own
1740 <filename>Makefile</filename>. (In very large projects, this
1741 sub-structure might be iterated recursively, though that is
1742 rare.) To give you the idea, here's part of the directory
1743 structure for the (rather large) GHC project:</para>
1745 <programlisting>$(FPTOOLS_TOP)/ghc/
1752 ...source files for documentation...
1755 ...source files for driver...
1758 parser/...source files for parser...
1759 renamer/...source files for renamer...
1760 ...etc...</programlisting>
1762 <para>The sub-directories <filename>docs</filename>,
1763 <filename>driver</filename>, <filename>compiler</filename>, and
1764 so on, each contains a sub-component of GHC, and each has its
1765 own <filename>Makefile</filename>. There must also be a
1766 <filename>Makefile</filename> in
1767 <filename>$(FPTOOLS_TOP)/ghc</filename>.
1768 It does most of its work by recursively invoking
1769 <command>gmake</command> on the <filename>Makefile</filename>s
1770 in the sub-directories. We say that
1771 <filename>ghc/Makefile</filename> is a <emphasis>non-leaf
1772 <filename>Makefile</filename></emphasis>, because it does little
1773 except organise its children, while the
1774 <filename>Makefile</filename>s in the sub-directories are all
1775 <emphasis>leaf <filename>Makefile</filename>s</emphasis>. (In
1776 principle the sub-directories might themselves contain a
1777 non-leaf <filename>Makefile</filename> and several
1778 sub-sub-directories, but that does not happen in GHC.)</para>
1780 <para>The <filename>Makefile</filename> in
1781 <filename>ghc/compiler</filename> is considered a leaf
1782 <filename>Makefile</filename> even though the
1783 <filename>ghc/compiler</filename> has sub-directories, because
1784 these sub-directories do not themselves have
1785 <filename>Makefile</filename>s in them. They are just used to
1786 structure the collection of modules that make up GHC, but all
1787 are managed by the single <filename>Makefile</filename> in
1788 <filename>ghc/compiler</filename>.</para>
1790 <para>You will notice that <filename>ghc/</filename> also
1791 contains a directory <filename>ghc/mk/</filename>. It contains
1792 GHC-specific <filename>Makefile</filename> boilerplate code.
1793 More precisely:</para>
1797 <para><filename>ghc/mk/boilerplate.mk</filename> is included
1798 at the top of <filename>ghc/Makefile</filename>, and of all
1799 the leaf <filename>Makefile</filename>s in the
1800 sub-directories. It in turn <literal>include</literal>s the
1801 main boilerplate file
1802 <filename>mk/boilerplate.mk</filename>.</para>
1806 <para><filename>ghc/mk/target.mk</filename> is
1807 <literal>include</literal>d at the bottom of
1808 <filename>ghc/Makefile</filename>, and of all the leaf
1809 <filename>Makefile</filename>s in the sub-directories. It
1810 in turn <literal>include</literal>s the file
1811 <filename>mk/target.mk</filename>.</para>
1815 <para>So these two files are the place to look for GHC-wide
1816 customisation of the standard boilerplate.</para>
1819 <sect2 id="sec-boiler-arch">
1820 <title>Boilerplate architecture</title>
1821 <indexterm><primary>boilerplate architecture</primary></indexterm>
1823 <para>Every <filename>Makefile</filename> includes a
1824 <filename>boilerplate.mk</filename><indexterm><primary>boilerplate.mk</primary></indexterm>
1825 file at the top, and
1826 <filename>target.mk</filename><indexterm><primary>target.mk</primary></indexterm>
1827 file at the bottom. In this section we discuss what is in these
1828 files, and why there have to be two of them. In general:</para>
1832 <para><filename>boilerplate.mk</filename> consists of:</para>
1836 <para><emphasis>Definitions of millions of
1837 <command>make</command> variables</emphasis> that
1838 collectively specify the build configuration. Examples:
1839 <constant>HC_OPTS</constant><indexterm><primary>HC_OPTS</primary></indexterm>,
1840 the options to feed to the Haskell compiler;
1841 <constant>NoFibSubDirs</constant><indexterm><primary>NoFibSubDirs</primary></indexterm>,
1842 the sub-directories to enable within the
1843 <literal>nofib</literal> project;
1844 <constant>GhcWithHc</constant><indexterm><primary>GhcWithHc</primary></indexterm>,
1845 the name of the Haskell compiler to use when compiling
1846 GHC in the <literal>ghc</literal> project.</para>
1850 <para><emphasis>Standard pattern rules</emphasis> that
1851 tell <command>gmake</command> how to construct one file
1852 from another.</para>
1856 <para><filename>boilerplate.mk</filename> needs to be
1857 <literal>include</literal>d at the <emphasis>top</emphasis>
1858 of each <filename>Makefile</filename>, so that the user can
1859 replace the boilerplate definitions or pattern rules by
1860 simply giving a new definition or pattern rule in the
1861 <filename>Makefile</filename>. <command>gmake</command>
1862 simply takes the last definition as the definitive one.</para>
1864 <para>Instead of <emphasis>replacing</emphasis> boilerplate
1865 definitions, it is also quite common to
1866 <emphasis>augment</emphasis> them. For example, a
1867 <filename>Makefile</filename> might say:</para>
1869 <programlisting>SRC_HC_OPTS += -O</programlisting>
1871 <para>thereby adding “<option>-O</option>” to
1873 <constant>SRC_HC_OPTS</constant><indexterm><primary>SRC_HC_OPTS</primary></indexterm>.</para>
1877 <para><filename>target.mk</filename> contains
1878 <command>make</command> rules for the standard targets
1879 described in <xref linkend="sec-standard-targets"/>. These
1880 rules are selectively included, depending on the setting of
1881 certain <command>make</command> variables. These variables
1882 are usually set in the middle section of the
1883 <filename>Makefile</filename> between the two
1884 <literal>include</literal>s.</para>
1886 <para><filename>target.mk</filename> must be included at the
1887 end (rather than being part of
1888 <filename>boilerplate.mk</filename>) for several tiresome
1894 <para><command>gmake</command> commits target and
1895 dependency lists earlier than it should. For example,
1896 <filename>target.mk</filename> has a rule that looks
1899 <programlisting>$(HS_PROG) : $(OBJS)
1900 $(HC) $(LD_OPTS) $< -o $@</programlisting>
1902 <para>If this rule was in
1903 <filename>boilerplate.mk</filename> then
1904 <constant>$(HS_PROG)</constant><indexterm><primary>HS_PROG</primary></indexterm>
1906 <constant>$(OBJS)</constant><indexterm><primary>OBJS</primary></indexterm>
1907 would not have their final values at the moment
1908 <command>gmake</command> encountered the rule. Alas,
1909 <command>gmake</command> takes a snapshot of their
1910 current values, and wires that snapshot into the rule.
1911 (In contrast, the commands executed when the rule
1912 “fires” are only substituted at the moment
1913 of firing.) So, the rule must follow the definitions
1914 given in the <filename>Makefile</filename> itself.</para>
1918 <para>Unlike pattern rules, ordinary rules cannot be
1919 overriden or replaced by subsequent rules for the same
1920 target (at least, not without an error message).
1921 Including ordinary rules in
1922 <filename>boilerplate.mk</filename> would prevent the
1923 user from writing rules for specific targets in specific
1928 <para>There are a couple of other reasons I've
1929 forgotten, but it doesn't matter too much.</para>
1936 <sect2 id="sec-boiler">
1937 <title>The main <filename>mk/boilerplate.mk</filename> file</title>
1938 <indexterm><primary>boilerplate.mk</primary></indexterm>
1940 <para>If you look at
1941 <filename>$(FPTOOLS_TOP)/mk/boilerplate.mk</filename>
1942 you will find that it consists of the following sections, each
1943 held in a separate file:</para>
1947 <term><filename>config.mk</filename>
1948 <indexterm><primary>config.mk</primary></indexterm>
1951 <para>is the build configuration file we discussed at
1952 length in <xref linkend="sec-build-config"/>.</para>
1957 <term><filename>paths.mk</filename>
1958 <indexterm><primary>paths.mk</primary></indexterm>
1961 <para>defines <command>make</command> variables for
1962 pathnames and file lists. This file contains code for
1963 automatically compiling lists of source files and deriving
1964 lists of object files from those. The results can be
1965 overriden in the <filename>Makefile</filename>, but in
1966 most cases the automatic setup should do the right
1969 <para>The following variables may be set in the
1970 <filename>Makefile</filename> to affect how the automatic
1971 source file search is done:</para>
1975 <term><literal>ALL_DIRS</literal>
1976 <indexterm><primary><literal>ALL_DIRS</literal></primary></indexterm>
1979 <para>Set to a list of directories to search in
1980 addition to the current directory for source
1986 <term><literal>EXCLUDED_SRCS</literal>
1987 <indexterm><primary><literal>EXCLUDED_SRCS</literal></primary></indexterm>
1990 <para>Set to a list of source files (relative to the
1991 current directory) to omit from the automatic
1992 search. The source searching machinery is clever
1993 enough to know that if you exclude a source file
1994 from which other sources are derived, then the
1995 derived sources should also be excluded. For
1996 example, if you set <literal>EXCLUDED_SRCS</literal>
1997 to include <filename>Foo.y</filename>, then
1998 <filename>Foo.hs</filename> will also be
2004 <term><literal>EXTRA_SRCS</literal>
2005 <indexterm><primary><literal>EXTRA_SRCS</literal></primary></indexterm>
2008 <para>Set to a list of extra source files (perhaps
2009 in directories not listed in
2010 <literal>ALL_DIRS</literal>) that should be
2016 <para>The results of the automatic source file search are
2017 placed in the following make variables:</para>
2021 <term><literal>SRCS</literal>
2022 <indexterm><primary><literal>SRCS</literal></primary></indexterm>
2025 <para>All source files found, sorted and without
2026 duplicates, including those which might not exist
2027 yet but will be derived from other existing sources.
2028 <literal>SRCS</literal> <emphasis>can</emphasis> be
2029 overriden if necessary, in which case the variables
2030 below will follow suit.</para>
2035 <term><literal>HS_SRCS</literal>
2036 <indexterm><primary><literal>HS_SRCS</literal></primary></indexterm>
2039 <para>all Haskell source files in the current
2040 directory, including those derived from other source
2041 files (eg. Happy sources also give rise to Haskell
2047 <term><literal>HS_OBJS</literal>
2048 <indexterm><primary><literal>HS_OBJS</literal></primary></indexterm>
2051 <para>Object files derived from
2052 <literal>HS_SRCS</literal>.</para>
2057 <term><literal>HS_IFACES</literal>
2058 <indexterm><primary><literal>HS_IFACES</literal></primary></indexterm>
2061 <para>Interface files (<literal>.hi</literal> files)
2062 derived from <literal>HS_SRCS</literal>.</para>
2067 <term><literal>C_SRCS</literal>
2068 <indexterm><primary><literal>C_SRCS</literal></primary></indexterm>
2071 <para>All C source files found.</para>
2076 <term><literal>C_OBJS</literal>
2077 <indexterm><primary><literal>C_OBJS</literal></primary></indexterm>
2080 <para>Object files derived from
2081 <literal>C_SRCS</literal>.</para>
2086 <term><literal>SCRIPT_SRCS</literal>
2087 <indexterm><primary><literal>SCRIPT_SRCS</literal></primary></indexterm>
2090 <para>All script source files found
2091 (<literal>.lprl</literal> files).</para>
2096 <term><literal>SCRIPT_OBJS</literal>
2097 <indexterm><primary><literal>SCRIPT_OBJS</literal></primary></indexterm>
2100 <para><quote>object</quote> files derived from
2101 <literal>SCRIPT_SRCS</literal>
2102 (<literal>.prl</literal> files).</para>
2107 <term><literal>HSC_SRCS</literal>
2108 <indexterm><primary><literal>HSC_SRCS</literal></primary></indexterm>
2111 <para>All <literal>hsc2hs</literal> source files
2112 (<literal>.hsc</literal> files).</para>
2117 <term><literal>HAPPY_SRCS</literal>
2118 <indexterm><primary><literal>HAPPY_SRCS</literal></primary></indexterm>
2121 <para>All <literal>happy</literal> source files
2122 (<literal>.y</literal> or <literal>.hy</literal> files).</para>
2127 <term><literal>OBJS</literal>
2128 <indexterm><primary>OBJS</primary></indexterm>
2131 <para>the concatenation of
2132 <literal>$(HS_OBJS)</literal>,
2133 <literal>$(C_OBJS)</literal>, and
2134 <literal>$(SCRIPT_OBJS)</literal>.</para>
2139 <para>Any or all of these definitions can easily be
2140 overriden by giving new definitions in your
2141 <filename>Makefile</filename>.</para>
2143 <para>What, exactly, does <filename>paths.mk</filename>
2144 consider a <quote>source file</quote> to be? It's based
2145 on the file's suffix (e.g. <filename>.hs</filename>,
2146 <filename>.lhs</filename>, <filename>.c</filename>,
2147 <filename>.hy</filename>, etc), but this is the kind of
2148 detail that changes, so rather than enumerate the source
2149 suffices here the best thing to do is to look in
2150 <filename>paths.mk</filename>.</para>
2155 <term><filename>opts.mk</filename>
2156 <indexterm><primary>opts.mk</primary></indexterm>
2159 <para>defines <command>make</command> variables for option
2160 strings to pass to each program. For example, it defines
2161 <constant>HC_OPTS</constant><indexterm><primary>HC_OPTS</primary></indexterm>,
2162 the option strings to pass to the Haskell compiler. See
2163 <xref linkend="sec-suffix"/>.</para>
2168 <term><filename>suffix.mk</filename>
2169 <indexterm><primary>suffix.mk</primary></indexterm>
2172 <para>defines standard pattern rules—see <xref
2173 linkend="sec-suffix"/>.</para>
2178 <para>Any of the variables and pattern rules defined by the
2179 boilerplate file can easily be overridden in any particular
2180 <filename>Makefile</filename>, because the boilerplate
2181 <literal>include</literal> comes first. Definitions after this
2182 <literal>include</literal> directive simply override the default
2183 ones in <filename>boilerplate.mk</filename>.</para>
2186 <sect2 id="sec-platforms">
2187 <title>Platform settings</title>
2188 <indexterm><primary>Platform settings</primary>
2191 <para>There are three platforms of interest when building GHC:</para>
2195 <term>The <emphasis>build</emphasis> platform</term>
2197 <para>The platform on which we are doing this build.</para>
2202 <term>The <emphasis>host</emphasis> platform</term>
2204 <para>The platform on which these binaries will run.</para>
2209 <term>The <emphasis>target</emphasis> platform</term>
2211 <para>The platform for which this compiler will generate code.</para>
2216 <para>These platforms are set when running the
2217 <literal>configure</literal> script, using the
2218 <option>--build</option>, <option>--host</option>, and
2219 <option>--target</option> options. The <filename>mk/config.mk</filename>
2220 file defines several symbols related to the platform settings (see
2221 <filename>mk/config.mk</filename> for details).</para>
2223 <para>We don't currently support build & host being different, because
2224 the build process creates binaries that are both run during the build,
2225 and also installed.</para>
2227 <para>If host and target are different, then we are building a
2228 cross-compiler. For GHC, this means a compiler
2229 which will generate intermediate .hc files to port to the target
2230 architecture for bootstrapping. The libraries and stage 2 compiler
2231 will be built as HC files for the target system (see <xref
2232 linkend="sec-porting-ghc" /> for details.</para>
2234 <para>More details on when to use BUILD, HOST or TARGET can be found in
2235 the comments in <filename>config.mk</filename>.</para>
2238 <sect2 id="sec-suffix">
2239 <title>Pattern rules and options</title>
2240 <indexterm><primary>Pattern rules</primary></indexterm>
2243 <filename>suffix.mk</filename><indexterm><primary>suffix.mk</primary></indexterm>
2244 defines standard <emphasis>pattern rules</emphasis> that say how
2245 to build one kind of file from another, for example, how to
2246 build a <filename>.o</filename> file from a
2247 <filename>.c</filename> file. (GNU <command>make</command>'s
2248 <emphasis>pattern rules</emphasis> are more powerful and easier
2249 to use than Unix <command>make</command>'s <emphasis>suffix
2250 rules</emphasis>.)</para>
2252 <para>Almost all the rules look something like this:</para>
2254 <programlisting>%.o : %.c
2256 $(CC) $(CC_OPTS) -c $< -o $@</programlisting>
2258 <para>Here's how to understand the rule. It says that
2259 <emphasis>something</emphasis><filename>.o</filename> (say
2260 <filename>Foo.o</filename>) can be built from
2261 <emphasis>something</emphasis><filename>.c</filename>
2262 (<filename>Foo.c</filename>), by invoking the C compiler (path
2263 name held in <constant>$(CC)</constant>), passing to it
2264 the options <constant>$(CC_OPTS)</constant> and
2265 the rule's dependent file of the rule
2266 <literal>$<</literal> (<filename>Foo.c</filename> in
2267 this case), and putting the result in the rule's target
2268 <literal>$@</literal> (<filename>Foo.o</filename> in this
2271 <para>Every program is held in a <command>make</command>
2272 variable defined in <filename>mk/config.mk</filename>—look
2273 in <filename>mk/config.mk</filename> for the complete list. One
2274 important one is the Haskell compiler, which is called
2275 <constant>$(HC)</constant>.</para>
2277 <para>Every program's options are are held in a
2278 <command>make</command> variables called
2279 <constant><prog>_OPTS</constant>. the
2280 <constant><prog>_OPTS</constant> variables are
2281 defined in <filename>mk/opts.mk</filename>. Almost all of them
2282 are defined like this:</para>
2284 <programlisting>CC_OPTS = \
2285 $(SRC_CC_OPTS) $(WAY$(_way)_CC_OPTS) $($*_CC_OPTS) $(EXTRA_CC_OPTS)</programlisting>
2287 <para>The four variables from which
2288 <constant>CC_OPTS</constant> is built have the following
2293 <term><constant>SRC_CC_OPTS</constant><indexterm><primary>SRC_CC_OPTS</primary></indexterm>:</term>
2295 <para>options passed to all C compilations.</para>
2300 <term><constant>WAY_<way>_CC_OPTS</constant>:</term>
2302 <para>options passed to C compilations for way
2303 <literal><way></literal>. For example,
2304 <constant>WAY_mp_CC_OPTS</constant>
2305 gives options to pass to the C compiler when compiling way
2306 <literal>mp</literal>. The variable
2307 <constant>WAY_CC_OPTS</constant> holds
2308 options to pass to the C compiler when compiling the
2309 standard way. (<xref linkend="sec-ways"/> dicusses
2310 multi-way compilation.)</para>
2315 <term><constant><module>_CC_OPTS</constant>:</term>
2317 <para>options to pass to the C compiler that are specific
2318 to module <literal><module></literal>. For example,
2319 <constant>SMap_CC_OPTS</constant> gives the
2320 specific options to pass to the C compiler when compiling
2321 <filename>SMap.c</filename>.</para>
2326 <term><constant>EXTRA_CC_OPTS</constant><indexterm><primary>EXTRA_CC_OPTS</primary></indexterm>:</term>
2328 <para>extra options to pass to all C compilations. This
2329 is intended for command line use, thus:</para>
2331 <screen>$ gmake libHS.a EXTRA_CC_OPTS="-v"</screen>
2337 <sect2 id="sec-targets">
2338 <title>The main <filename>mk/target.mk</filename> file</title>
2339 <indexterm><primary>target.mk</primary></indexterm>
2341 <para><filename>target.mk</filename> contains canned rules for
2342 all the standard targets described in <xref
2343 linkend="sec-standard-targets"/>. It is complicated by the fact
2344 that you don't want all of these rules to be active in every
2345 <filename>Makefile</filename>. Rather than have a plethora of
2346 tiny files which you can include selectively, there is a single
2347 file, <filename>target.mk</filename>, which selectively includes
2348 rules based on whether you have defined certain variables in
2349 your <filename>Makefile</filename>. This section explains what
2350 rules you get, what variables control them, and what the rules
2351 do. Hopefully, you will also get enough of an idea of what is
2352 supposed to happen that you can read and understand any weird
2353 special cases yourself.</para>
2357 <term><constant>HS_PROG</constant><indexterm><primary>HS_PROG</primary></indexterm>.</term>
2359 <para>If <constant>HS_PROG</constant> is defined,
2360 you get rules with the following targets:</para>
2364 <term><filename>HS_PROG</filename><indexterm><primary>HS_PROG</primary></indexterm></term>
2366 <para>itself. This rule links
2367 <constant>$(OBJS)</constant> with the Haskell
2368 runtime system to get an executable called
2369 <constant>$(HS_PROG)</constant>.</para>
2374 <term><literal>install</literal><indexterm><primary>install</primary></indexterm></term>
2377 <constant>$(HS_PROG)</constant> in
2378 <constant>$(bindir)</constant>.</para>
2387 <term><constant>C_PROG</constant><indexterm><primary>C_PROG</primary></indexterm></term>
2389 <para>is similar to <constant>HS_PROG</constant>,
2390 except that the link step links
2391 <constant>$(C_OBJS)</constant> with the C
2392 runtime system.</para>
2397 <term><constant>LIBRARY</constant><indexterm><primary>LIBRARY</primary></indexterm></term>
2399 <para>is similar to <constant>HS_PROG</constant>,
2400 except that it links
2401 <constant>$(LIB_OBJS)</constant> to make the
2402 library archive <constant>$(LIBRARY)</constant>,
2403 and <literal>install</literal> installs it in
2404 <constant>$(libdir)</constant>.</para>
2409 <term><constant>LIB_DATA</constant><indexterm><primary>LIB_DATA</primary></indexterm></term>
2411 <para>…</para>
2416 <term><constant>LIB_EXEC</constant><indexterm><primary>LIB_EXEC</primary></indexterm></term>
2418 <para>…</para>
2423 <term><constant>HS_SRCS</constant><indexterm><primary>HS_SRCS</primary></indexterm>, <constant>C_SRCS</constant><indexterm><primary>C_SRCS</primary></indexterm>.</term>
2425 <para>If <constant>HS_SRCS</constant> is defined
2426 and non-empty, a rule for the target
2427 <literal>depend</literal> is included, which generates
2428 dependency information for Haskell programs. Similarly
2429 for <constant>C_SRCS</constant>.</para>
2434 <para>All of these rules are “double-colon” rules,
2437 <programlisting>install :: $(HS_PROG)
2438 ...how to install it...</programlisting>
2440 <para>GNU <command>make</command> treats double-colon rules as
2441 separate entities. If there are several double-colon rules for
2442 the same target it takes each in turn and fires it if its
2443 dependencies say to do so. This means that you can, for
2444 example, define both <constant>HS_PROG</constant> and
2445 <constant>LIBRARY</constant>, which will generate two rules for
2446 <literal>install</literal>. When you type <command>gmake
2447 install</command> both rules will be fired, and both the program
2448 and the library will be installed, just as you wanted.</para>
2451 <sect2 id="sec-subdirs">
2452 <title>Recursion</title>
2453 <indexterm><primary>recursion, in makefiles</primary></indexterm>
2454 <indexterm><primary>Makefile, recursing into subdirectories</primary></indexterm>
2456 <para>In leaf <filename>Makefile</filename>s the variable
2457 <constant>SUBDIRS</constant><indexterm><primary>SUBDIRS</primary></indexterm>
2458 is undefined. In non-leaf <filename>Makefile</filename>s,
2459 <constant>SUBDIRS</constant> is set to the list of
2460 sub-directories that contain subordinate
2461 <filename>Makefile</filename>s. <emphasis>It is up to you to
2462 set <constant>SUBDIRS</constant> in the
2463 <filename>Makefile</filename>.</emphasis> There is no automation
2464 here—<constant>SUBDIRS</constant> is too important to
2467 <para>When <constant>SUBDIRS</constant> is defined,
2468 <filename>target.mk</filename> includes a rather neat rule for
2469 the standard targets (<xref linkend="sec-standard-targets"/> that
2470 simply invokes <command>make</command> recursively in each of
2471 the sub-directories.</para>
2473 <para><emphasis>These recursive invocations are guaranteed to
2474 occur in the order in which the list of directories is specified
2475 in <constant>SUBDIRS</constant>. </emphasis>This guarantee can
2476 be important. For example, when you say <command>gmake
2477 boot</command> it can be important that the recursive invocation
2478 of <command>make boot</command> is done in one sub-directory
2479 (the include files, say) before another (the source files).
2480 Generally, put the most independent sub-directory first, and the
2481 most dependent last.</para>
2484 <sect2 id="sec-ways">
2485 <title>Way management</title>
2486 <indexterm><primary>way management</primary></indexterm>
2488 <para>We sometimes want to build essentially the same system in
2489 several different “ways”. For example, we want to build GHC's
2490 <literal>Prelude</literal> libraries with and without profiling,
2491 so that there is an appropriately-built library archive to link
2492 with when the user compiles his program. It would be possible
2493 to have a completely separate build tree for each such “way”,
2494 but it would be horribly bureaucratic, especially since often
2495 only parts of the build tree need to be constructed in multiple
2499 <filename>target.mk</filename><indexterm><primary>target.mk</primary></indexterm>
2500 contains some clever magic to allow you to build several
2501 versions of a system; and to control locally how many versions
2502 are built and how they differ. This section explains the
2505 <para>The files for a particular way are distinguished by
2506 munging the suffix. The <quote>normal way</quote> is always
2507 built, and its files have the standard suffices
2508 <filename>.o</filename>, <filename>.hi</filename>, and so on.
2509 In addition, you can build one or more extra ways, each
2510 distinguished by a <emphasis>way tag</emphasis>. The object
2511 files and interface files for one of these extra ways are
2512 distinguished by their suffix. For example, way
2513 <literal>mp</literal> has files
2514 <filename>.mp_o</filename> and
2515 <filename>.mp_hi</filename>. Library archives have their
2516 way tag the other side of the dot, for boring reasons; thus,
2517 <filename>libHS_mp.a</filename>.</para>
2519 <para>A <command>make</command> variable called
2520 <constant>way</constant> holds the current way tag.
2521 <emphasis><constant>way</constant> is only ever set on the
2522 command line of <command>gmake</command></emphasis> (usually in
2523 a recursive invocation of <command>gmake</command> by the
2524 system). It is never set inside a
2525 <filename>Makefile</filename>. So it is a global constant for
2526 any one invocation of <command>gmake</command>. Two other
2527 <command>make</command> variables,
2528 <constant>way_</constant> and
2529 <constant>_way</constant> are immediately derived from
2530 <constant>$(way)</constant> and never altered. If
2531 <constant>way</constant> is not set, then neither are
2532 <constant>way_</constant> and
2533 <constant>_way</constant>, and the invocation of
2534 <command>make</command> will build the <quote>normal
2535 way</quote>. If <constant>way</constant> is set, then the other
2536 two variables are set in sympathy. For example, if
2537 <constant>$(way)</constant> is “<literal>mp</literal>”,
2538 then <constant>way_</constant> is set to
2539 “<literal>mp_</literal>” and
2540 <constant>_way</constant> is set to
2541 “<literal>_mp</literal>”. These three variables are
2542 then used when constructing file names.</para>
2544 <para>So how does <command>make</command> ever get recursively
2545 invoked with <constant>way</constant> set? There are two ways
2546 in which this happens:</para>
2550 <para>For some (but not all) of the standard targets, when
2551 in a leaf sub-directory, <command>make</command> is
2552 recursively invoked for each way tag in
2553 <constant>$(WAYS)</constant>. You set
2554 <constant>WAYS</constant> in the
2555 <filename>Makefile</filename> to the list of way tags you
2556 want these targets built for. The mechanism here is very
2557 much like the recursive invocation of
2558 <command>make</command> in sub-directories (<xref
2559 linkend="sec-subdirs"/>). It is up to you to set
2560 <constant>WAYS</constant> in your
2561 <filename>Makefile</filename>; this is how you control what
2562 ways will get built.</para>
2566 <para>For a useful collection of targets (such as
2567 <filename>libHS_mp.a</filename>,
2568 <filename>Foo.mp_o</filename>) there is a rule which
2569 recursively invokes <command>make</command> to make the
2570 specified target, setting the <constant>way</constant>
2571 variable. So if you say <command>gmake
2572 Foo.mp_o</command> you should see a recursive
2573 invocation <command>gmake Foo.mp_o way=mp</command>,
2574 and <emphasis>in this recursive invocation the pattern rule
2575 for compiling a Haskell file into a <filename>.o</filename>
2576 file will match</emphasis>. The key pattern rules (in
2577 <filename>suffix.mk</filename>) look like this:
2579 <programlisting>%.$(way_)o : %.lhs
2580 $(HC) $(HC_OPTS) $< -o $@</programlisting>
2586 <para>You can invoke <command>make</command> with a
2587 particular <literal>way</literal> setting yourself, in order
2588 to build files related to a particular
2589 <literal>way</literal> in the current directory. eg.
2591 <screen>$ make way=p</screen>
2593 will build files for the profiling way only in the current
2600 <title>When the canned rule isn't right</title>
2602 <para>Sometimes the canned rule just doesn't do the right thing.
2603 For example, in the <literal>nofib</literal> suite we want the
2604 link step to print out timing information. The thing to do here
2605 is <emphasis>not</emphasis> to define
2606 <constant>HS_PROG</constant> or
2607 <constant>C_PROG</constant>, and instead define a special
2608 purpose rule in your own <filename>Makefile</filename>. By
2609 using different variable names you will avoid the canned rules
2610 being included, and conflicting with yours.</para>
2614 <sect1 id="building-docs">
2615 <title>Building the documentation</title>
2617 <sect2 id="pre-supposed-doc-tools">
2618 <title>Tools for building the Documentation</title>
2620 <para>The following additional tools are required if you want to
2621 format the documentation that comes with the
2622 <literal>fptools</literal> projects:</para>
2627 <indexterm><primary>pre-supposed: DocBook</primary></indexterm>
2628 <indexterm><primary>DocBook, pre-supposed</primary></indexterm>
2631 <para>Much of our documentation is written in DocBook XML, instructions
2632 on installing and configuring the DocBook tools are below.</para>
2638 <indexterm><primary>pre-supposed: TeX</primary></indexterm>
2639 <indexterm><primary>TeX, pre-supposed</primary></indexterm>
2642 <para>A decent TeX distribution is required if you want to
2643 produce printable documentation. We recomment teTeX,
2644 which includes just about everything you need.</para>
2650 <indexterm><primary>Haddock</primary></indexterm>
2653 <para>Haddock is a Haskell documentation tool that we use
2654 for automatically generating documentation from the
2655 library source code. It is an <literal>fptools</literal>
2656 project in itself. To build documentation for the
2657 libraries (<literal>fptools/libraries</literal>) you
2658 should check out and build Haddock in
2659 <literal>fptools/haddock</literal>. Haddock requires GHC
2667 <title>Installing the DocBook tools</title>
2670 <title>Installing the DocBook tools on Linux</title>
2672 <para>If you're on a recent RedHat (7.0+) or SuSE (8.1+) system,
2673 you probably have working DocBook tools already installed. The
2674 configure script should detect your setup and you're away.</para>
2676 <para>If you don't have DocBook tools installed, and you are
2677 using a system that can handle RPM packages, you can use <ulink
2678 url="http://rpmfind.net/">Rpmfind.net</ulink> to find suitable
2679 packages for your system. Search for the packages
2680 <literal>docbook-dtd</literal>,
2681 <literal>docbook-xsl-stylesheets</literal>,
2682 <literal>libxslt</literal>,
2683 <literal>libxml2</literal>,
2684 <literal>fop</literal>,
2685 <literal>xmltex</literal>, and
2686 <literal>dvips</literal>.</para>
2690 <title>Installing DocBook on FreeBSD</title>
2692 <para>On FreeBSD systems, the easiest way to get DocBook up
2693 and running is to install it from the ports tree or a
2694 pre-compiled package (packages are available from your local
2695 FreeBSD mirror site).</para>
2697 <para>To use the ports tree, do this:
2698 <screen>$ cd /usr/ports/textproc/docproj
2699 $ make install</screen>
2700 This installs the FreeBSD documentation project tools, which
2701 includes everything needed to format the GHC
2702 documentation.</para>
2706 <title>Installing from binaries on Windows</title>
2708 <para>Probably the fastest route to a working DocBook environment on
2709 Windows is to install <ulink url="http://www.cygwin.com/">Cygwin</ulink>
2710 with the complete <literal>Doc</literal> category. If you are using
2711 <ulink url="http://www.mingw.org/">MinGW</ulink> for compilation, you
2712 have to help <command>configure</command> a little bit: Set the
2713 environment variables <envar>XmllintCmd</envar> and
2714 <envar>XsltprocCmd</envar> to the paths of the Cygwin executables
2715 <command>xmllint</command> and <command>xsltproc</command>,
2716 respectively, and set <envar>fp_cv_dir_docbook_xsl</envar> to the path
2717 of the directory where the XSL stylesheets are installed,
2718 e.g. <filename>c:/cygwin/usr/share/docbook-xsl</filename>.
2721 <para>If you want to build HTML Help, you have to install the
2722 <ulink url="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/htmlhelp/html/hworiHTMLHelpStartPage.asp">HTML Help SDK</ulink>,
2723 too, and make sure that <command>hhc</command> is in your <envar>PATH</envar>.</para>
2729 <title>Configuring the DocBook tools</title>
2731 <para>Once the DocBook tools are installed, the configure script
2732 will detect them and set up the build system accordingly. If you
2733 have a system that isn't supported, let us know, and we'll try
2738 <title>Building the documentation</title>
2740 <para>To build documentation in a certain format, you can
2741 say, for example,</para>
2743 <screen>$ make html</screen>
2745 <para>to build HTML documentation below the current directory.
2746 The available formats are: <literal>dvi</literal>,
2747 <literal>ps</literal>, <literal>pdf</literal>,
2748 <literal>html</literal>, and <literal>rtf</literal>. Note that
2749 not all documentation can be built in all of these formats: HTML
2750 documentation is generally supported everywhere, and DocBook
2751 documentation might support the other formats (depending on what
2752 other tools you have installed).</para>
2754 <para>All of these targets are recursive; that is, saying
2755 <literal>make html</literal> will make HTML docs for all the
2756 documents recursively below the current directory.</para>
2758 <para>Because there are many different formats that the DocBook
2759 documentation can be generated in, you have to select which ones
2760 you want by setting the <literal>XMLDocWays</literal> variable
2761 to a list of them. For example, in
2762 <filename>build.mk</filename> you might have a line:</para>
2764 <screen>XMLDocWays = html ps</screen>
2766 <para>This will cause the documentation to be built in the requested
2767 formats as part of the main build (the default is not to build
2768 any documentation at all).</para>
2772 <title>Installing the documentation</title>
2774 <para>To install the documentation, use:</para>
2776 <screen>$ make install-docs</screen>
2778 <para>This will install the documentation into
2779 <literal>$(datadir)</literal> (which defaults to
2780 <literal>$(prefix)/share</literal>). The exception is HTML
2781 documentation, which goes into
2782 <literal>$(datadir)/html</literal>, to keep things tidy.</para>
2784 <para>Note that unless you set <literal>$(XMLDocWays)</literal>
2785 to a list of formats, the <literal>install-docs</literal> target
2786 won't do anything for DocBook XML documentation.</para>
2792 <sect1 id="sec-porting-ghc">
2793 <title>Porting GHC</title>
2795 <para>This section describes how to port GHC to a currenly
2796 unsupported platform. There are two distinct
2797 possibilities:</para>
2801 <para>The hardware architecture for your system is already
2802 supported by GHC, but you're running an OS that isn't
2803 supported (or perhaps has been supported in the past, but
2804 currently isn't). This is the easiest type of porting job,
2805 but it still requires some careful bootstrapping. Proceed to
2806 <xref linkend="sec-booting-from-hc"/>.</para>
2810 <para>Your system's hardware architecture isn't supported by
2811 GHC. This will be a more difficult port (though by comparison
2812 perhaps not as difficult as porting gcc). Proceed to <xref
2813 linkend="unregisterised-porting"/>.</para>
2817 <sect2 id="sec-booting-from-hc">
2818 <title>Booting/porting from C (<filename>.hc</filename>) files</title>
2820 <indexterm><primary>building GHC from .hc files</primary></indexterm>
2821 <indexterm><primary>booting GHC from .hc files</primary></indexterm>
2822 <indexterm><primary>porting GHC</primary></indexterm>
2824 <para>Bootstrapping GHC on a system without GHC already
2825 installed is achieved by taking the intermediate C files (known
2826 as HC files) from another GHC compilation, compiling them using gcc to
2827 get a working GHC.</para>
2829 <para><emphasis>NOTE: GHC versions 5.xx were hard to bootstrap
2830 from C. We recommend using GHC 6.0.1 or
2831 later.</emphasis></para>
2833 <para>HC files are platform-dependent, so you have to get a set
2834 that were generated on <emphasis>the same platform</emphasis>. There
2835 may be some supplied on the GHC download page, otherwise you'll have to
2836 compile some up yourself, or start from
2837 <emphasis>unregisterised</emphasis> HC files - see <xref
2838 linkend="unregisterised-porting"/>.</para>
2840 <para>The following steps should result in a working GHC build
2841 with full libraries:</para>
2845 <para>Unpack the HC files on top of a fresh source tree
2846 (make sure the source tree version matches the version of
2847 the HC files <emphasis>exactly</emphasis>!). This will
2848 place matching <filename>.hc</filename> files next to the
2849 corresponding Haskell source (<filename>.hs</filename> or
2850 <filename>.lhs</filename>) in the compiler subdirectory
2851 <filename>ghc/compiler</filename> and in the libraries
2853 <literal>libraries</literal>).</para>
2857 <para>The actual build process is fully automated by the
2858 <filename>hc-build</filename> script located in the
2859 <filename>distrib</filename> directory. If you eventually
2860 want to install GHC into the directory
2861 <replaceable>dir</replaceable>, the following
2862 command will execute the whole build process (it won't
2863 install yet):</para>
2865 <screen>$ distrib/hc-build --prefix=<replaceable>dir</replaceable></screen>
2866 <indexterm><primary>--hc-build</primary></indexterm>
2868 <para>By default, the installation directory is
2869 <filename>/usr/local</filename>. If that is what you want,
2870 you may omit the argument to <filename>hc-build</filename>.
2871 Generally, any option given to <filename>hc-build</filename>
2872 is passed through to the configuration script
2873 <filename>configure</filename>. If
2874 <filename>hc-build</filename> successfully completes the
2875 build process, you can install the resulting system, as
2878 <screen>$ make install</screen>
2883 <sect2 id="unregisterised-porting">
2884 <title>Porting GHC to a new architecture</title>
2886 <para>The first step in porting to a new architecture is to get
2887 an <firstterm>unregisterised</firstterm> build working. An
2888 unregisterised build is one that compiles via vanilla C only.
2889 By contrast, a registerised build uses the following
2890 architecture-specific hacks for speed:</para>
2894 <para>Global register variables: certain abstract machine
2895 <quote>registers</quote> are mapped to real machine
2896 registers, depending on how many machine registers are
2898 <filename>ghc/includes/MachRegs.h</filename>).</para>
2902 <para>Assembly-mangling: when compiling via C, we feed the
2903 assembly generated by gcc though a Perl script known as the
2904 <firstterm>mangler</firstterm> (see
2905 <filename>ghc/driver/mangler/ghc-asm.lprl</filename>). The
2906 mangler rearranges the assembly to support tail-calls and
2907 various other optimisations.</para>
2911 <para>In an unregisterised build, neither of these hacks are
2912 used — the idea is that the C code generated by the
2913 compiler should compile using gcc only. The lack of these
2914 optimisations costs about a factor of two in performance, but
2915 since unregisterised compilation is usually just a step on the
2916 way to a full registerised port, we don't mind too much.</para>
2918 <para>Notes on GHC portability in general: we've tried to stick
2919 to writing portable code in most parts of the system, so it
2920 should compile on any POSIXish system with gcc, but in our
2921 experience most systems differ from the standards in one way or
2922 another. Deal with any problems as they arise - if you get
2923 stuck, ask the experts on
2924 <email>glasgow-haskell-users@haskell.org</email>.</para>
2926 <para>Lots of useful information about the innards of GHC is
2927 available in the <ulink
2928 url="http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/">GHC
2929 Commentary</ulink>, which might be helpful if you run into some
2930 code which needs tweaking for your system.</para>
2933 <title>Cross-compiling to produce an unregisterised GHC</title>
2935 <para>NOTE! These instructions apply to GHC 6.4 and (hopefully)
2936 later. If you need instructions for an earlier version of GHC, try
2937 to get hold of the version of this document that was current at the
2938 time. It should be available from the appropriate download page on
2940 url="http://www.haskell.org/ghc/">GHC homepage</ulink>.</para>
2942 <para>In this section, we explain how to bootstrap GHC on a
2943 new platform, using unregisterised intermediate C files. We
2944 haven't put a great deal of effort into automating this
2945 process, for two reasons: it is done very rarely, and the
2946 process usually requires human intervention to cope with minor
2947 porting issues anyway.</para>
2949 <para>The following step-by-step instructions should result in
2950 a fully working, albeit unregisterised, GHC. Firstly, you
2951 need a machine that already has a working GHC (we'll call this
2952 the <firstterm>host</firstterm> machine), in order to
2953 cross-compile the intermediate C files that we will use to
2954 bootstrap the compiler on the <firstterm>target</firstterm>
2959 <para>On the target machine:</para>
2963 <para>Unpack a source tree (preferably a released
2964 version). We will call the path to the root of this
2965 tree <replaceable>T</replaceable>.</para>
2969 <screen>$ cd <replaceable>T</replaceable>
2970 $ ./configure --enable-hc-boot --enable-hc-boot-unregisterised</screen>
2972 <para>You might need to update
2973 <filename>configure.in</filename> to recognise the new
2974 architecture, and re-generate
2975 <filename>configure</filename> with
2976 <literal>autoreconf</literal>.</para>
2980 <screen>$ cd <replaceable>T</replaceable>/ghc/includes
2987 <para>On the host machine:</para>
2991 <para>Unpack a source tree (same released version). Call
2992 this directory <replaceable>H</replaceable>.</para>
2996 <screen>$ cd <replaceable>H</replaceable>
2997 $ ./configure</screen>
3002 <filename><replaceable>H</replaceable>/mk/build.mk</filename>,
3003 with the following contents:</para>
3005 <programlisting>GhcUnregisterised = YES
3006 GhcLibHcOpts = -O -fvia-C -keep-hc-files
3007 GhcRtsHcOpts = -keep-hc-files
3010 GhcWithNativeCodeGen = NO
3011 GhcWithInterpreter = NO
3012 GhcStage1HcOpts = -O
3013 GhcStage2HcOpts = -O -fvia-C -keep-hc-files
3014 SRC_HC_OPTS += -H32m
3015 GhcBootLibs = YES</programlisting>
3020 <filename><replaceable>H</replaceable>/mk/config.mk</filename>:</para>
3023 <para>change <literal>TARGETPLATFORM</literal>
3024 appropriately, and set the variables involving
3025 <literal>TARGET</literal> to the correct values for
3026 the target platform. This step is necessary because
3027 currently <literal>configure</literal> doesn't cope
3028 with specifying different values for the
3029 <literal>--host</literal> and
3030 <literal>--target</literal> flags.</para>
3033 <para>copy <literal>LeadingUnderscore</literal>
3034 setting from target.</para>
3041 <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>
3043 <filename><replaceable>H</replaceable>/ghc/includes</filename>.
3044 Note that we are building on the host machine, using the
3045 target machine's configuration files. This
3046 is so that the intermediate C files generated here will
3047 be suitable for compiling on the target system.</para>
3051 <para>Touch the generated configuration files, just to make
3052 sure they don't get replaced during the build:</para>
3053 <screen>$ cd <filename><replaceable>H</replaceable></filename>/ghc/includes
3054 $ touch ghcautoconf.h DerivedConstants.h GHCConstants.h mkDerivedConstants.c
3055 $ touch mkDerivedConstantsHdr mkDerivedConstants.o mkGHCConstants mkGHCConstants.o</screen>
3057 <para>Note: it has been reported that these files still get
3058 overwritten during the next stage. We have installed a fix
3059 for this in GHC 6.4.2, but if you are building a version
3060 before that you need to watch out for these files getting
3061 overwritte by the <literal>Makefile</literal> in
3062 <literal>ghc/includes</literal>. If your system supports
3063 it, you might be able to prevent it by making them
3065 <screen>$ chflags uchg ghc/includes/{ghcautoconf.h,DerivedConstants.h,GHCConstants.h}</screen>
3069 <para>Now build the compiler:</para>
3070 <screen>$ cd <replaceable>H</replaceable>/glafp-utils && make boot && make
3071 $ cd <replaceable>H</replaceable>/ghc && make boot && make</screen>
3072 <para>Don't worry if the build falls over in the RTS, we
3073 don't need the RTS yet.</para>
3077 <screen>$ cd <replaceable>H</replaceable>/libraries
3078 $ make boot && make</screen>
3082 <screen>$ cd <replaceable>H</replaceable>/ghc/compiler
3083 $ make boot stage=2 && make stage=2</screen>
3087 <screen>$ cd <replaceable>H</replaceable>/ghc/lib/compat
3090 $ make boot UseStage1=YES
3091 $ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'
3092 $ cd <replaceable>H</replaceable>/ghc/utils
3094 $ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'</screen>
3098 <screen>$ cd <replaceable>H</replaceable>
3099 $ make hc-file-bundle Project=Ghc</screen>
3104 <filename><replaceable>H</replaceable>/*-hc.tar.gz</filename>
3105 to <filename><replaceable>T</replaceable>/..</filename>.</para>
3111 <para>On the target machine:</para>
3113 <para>At this stage we simply need to bootstrap a compiler
3114 from the intermediate C files we generated above. The
3115 process of bootstrapping from C files is automated by the
3116 script in <literal>distrib/hc-build</literal>, and is
3117 described in <xref linkend="sec-booting-from-hc"/>.</para>
3119 <screen>$ ./distrib/hc-build --enable-hc-boot-unregisterised</screen>
3121 <para>However, since this is a bootstrap on a new machine,
3122 the automated process might not run to completion the
3123 first time. For that reason, you might want to treat the
3124 <literal>hc-build</literal> script as a list of
3125 instructions to follow, rather than as a fully automated
3126 script. This way you'll be able to restart the process
3127 part-way through if you need to fix anything on the
3130 <para>Don't bother with running
3131 <literal>make install</literal> in the newly
3132 bootstrapped tree; just use the compiler in that tree to
3133 build a fresh compiler from scratch, this time without
3134 booting from C files. Before doing this, you might want
3135 to check that the bootstrapped compiler is generating
3136 working binaries:</para>
3138 <screen>$ cat >hello.hs
3139 main = putStrLn "Hello World!\n"
3141 $ <replaceable>T</replaceable>/ghc/compiler/ghc-inplace hello.hs -o hello
3143 Hello World!</screen>
3145 <para>Once you have the unregisterised compiler up and
3146 running, you can use it to start a registerised port. The
3147 following sections describe the various parts of the
3148 system that will need architecture-specific tweaks in
3149 order to get a registerised build going.</para>
3156 <title>Porting the RTS</title>
3158 <para>The following files need architecture-specific code for a
3159 registerised build:</para>
3163 <term><filename>ghc/includes/MachRegs.h</filename>
3164 <indexterm><primary><filename>MachRegs.h</filename></primary></indexterm>
3167 <para>Defines the STG-register to machine-register
3168 mapping. You need to know your platform's C calling
3169 convention, and which registers are generally available
3170 for mapping to global register variables. There are
3171 plenty of useful comments in this file.</para>
3175 <term><filename>ghc/includes/TailCalls.h</filename>
3176 <indexterm><primary><filename>TailCalls.h</filename></primary></indexterm>
3179 <para>Macros that cooperate with the mangler (see <xref
3180 linkend="sec-mangler"/>) to make proper tail-calls
3185 <term><filename>ghc/rts/Adjustor.c</filename>
3186 <indexterm><primary><filename>Adjustor.c</filename></primary></indexterm>
3190 <literal>foreign import "wrapper"</literal>
3192 <literal>foreign export dynamic</literal>).
3193 Not essential for getting GHC bootstrapped, so this file
3194 can be deferred until later if necessary.</para>
3198 <term><filename>ghc/rts/StgCRun.c</filename>
3199 <indexterm><primary><filename>StgCRun.c</filename></primary></indexterm>
3202 <para>The little assembly layer between the C world and
3203 the Haskell world. See the comments and code for the
3204 other architectures in this file for pointers.</para>
3208 <term><filename>ghc/rts/MBlock.h</filename>
3209 <indexterm><primary><filename>MBlock.h</filename></primary></indexterm>
3211 <term><filename>ghc/rts/MBlock.c</filename>
3212 <indexterm><primary><filename>MBlock.c</filename></primary></indexterm>
3215 <para>These files are really OS-specific rather than
3216 architecture-specific. In <filename>MBlock.h</filename>
3217 is specified the absolute location at which the RTS
3218 should try to allocate memory on your platform (try to
3219 find an area which doesn't conflict with code or dynamic
3220 libraries). In <filename>Mblock.c</filename> you might
3221 need to tweak the call to <literal>mmap()</literal> for
3228 <sect3 id="sec-mangler">
3229 <title>The mangler</title>
3231 <para>The mangler is an evil Perl-script
3232 (<filename>ghc/driver/mangler/ghc-asm.lprl</filename>) that
3233 rearranges the assembly code output from gcc to do two main
3238 <para>Remove function prologues and epilogues, and all
3239 movement of the C stack pointer. This is to support
3240 tail-calls: every code block in Haskell code ends in an
3241 explicit jump, so we don't want the C-stack overflowing
3242 while we're jumping around between code blocks.</para>
3245 <para>Move the <firstterm>info table</firstterm> for a
3246 closure next to the entry code for that closure. In
3247 unregisterised code, info tables contain a pointer to the
3248 entry code, but in registerised compilation we arrange
3249 that the info table is shoved right up against the entry
3250 code, and addressed backwards from the entry code pointer
3251 (this saves a word in the info table and an extra
3252 indirection when jumping to the closure entry
3257 <para>The mangler is abstracted to a certain extent over some
3258 architecture-specific things such as the particular assembler
3259 directives used to herald symbols. Take a look at the
3260 definitions for other architectures and use these as a
3261 starting point.</para>
3265 <title>The splitter</title>
3267 <para>The splitter is another evil Perl script
3268 (<filename>ghc/driver/split/ghc-split.lprl</filename>). It
3269 cooperates with the mangler to support object splitting.
3270 Object splitting is what happens when the
3271 <option>-split-objs</option> option is passed to GHC: the
3272 object file is split into many smaller objects. This feature
3273 is used when building libraries, so that a program statically
3274 linked against the library will pull in less of the
3277 <para>The splitter has some platform-specific stuff; take a
3278 look and tweak it for your system.</para>
3282 <title>The native code generator</title>
3284 <para>The native code generator isn't essential to getting a
3285 registerised build going, but it's a desirable thing to have
3286 because it can cut compilation times in half. The native code
3287 generator is described in some detail in the <ulink
3288 url="http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/">GHC
3289 commentary</ulink>.</para>
3295 <para>To support GHCi, you need to port the dynamic linker
3296 (<filename>fptools/ghc/rts/Linker.c</filename>). The linker
3297 currently supports the ELF and PEi386 object file formats - if
3298 your platform uses one of these then things will be
3299 significantly easier. The majority of Unix platforms use the
3300 ELF format these days. Even so, there are some
3301 machine-specific parts of the ELF linker: for example, the
3302 code for resolving particular relocation types is
3303 machine-specific, so some porting of this code to your
3304 architecture will probaly be necessary.</para>
3306 <para>If your system uses a different object file format, then
3307 you have to write a linker — good luck!</para>
3313 <sect1 id="sec-build-pitfalls">
3314 <title>Known pitfalls in building Glasgow Haskell
3316 <indexterm><primary>problems, building</primary></indexterm>
3317 <indexterm><primary>pitfalls, in building</primary></indexterm>
3318 <indexterm><primary>building pitfalls</primary></indexterm></title>
3321 WARNINGS about pitfalls and known “problems”:
3330 One difficulty that comes up from time to time is running out of space
3331 in <literal>TMPDIR</literal>. (It is impossible for the configuration stuff to
3332 compensate for the vagaries of different sysadmin approaches to temp
3334 <indexterm><primary>tmp, running out of space in</primary></indexterm>
3336 The quickest way around it is <command>setenv TMPDIR /usr/tmp</command><indexterm><primary>TMPDIR</primary></indexterm> or
3337 even <command>setenv TMPDIR .</command> (or the equivalent incantation with your shell
3340 The best way around it is to say
3342 <programlisting>export TMPDIR=<dir></programlisting>
3344 in your <filename>build.mk</filename> file.
3345 Then GHC and the other <literal>fptools</literal> programs will use the appropriate directory
3354 In compiling some support-code bits, e.g., in <filename>ghc/rts/gmp</filename> and even
3355 in <filename>ghc/lib</filename>, you may get a few C-compiler warnings. We think these
3363 When compiling via C, you'll sometimes get “warning: assignment from
3364 incompatible pointer type” out of GCC. Harmless.
3371 Similarly, <command>ar</command>chiving warning messages like the following are not
3374 <screen>ar: filename GlaIOMonad__1_2s.o truncated to GlaIOMonad_
3375 ar: filename GlaIOMonad__2_2s.o truncated to GlaIOMonad_
3384 In compiling the compiler proper (in <filename>compiler/</filename>), you <emphasis>may</emphasis>
3385 get an “Out of heap space” error message. These can vary with the
3386 vagaries of different systems, it seems. The solution is simple:
3393 If you're compiling with GHC 4.00 or later, then the
3394 <emphasis>maximum</emphasis> heap size must have been reached. This
3395 is somewhat unlikely, since the maximum is set to 64M by default.
3396 Anyway, you can raise it with the
3397 <option>-optCrts-M<size></option> flag (add this flag to
3398 <constant><module>_HC_OPTS</constant>
3399 <command>make</command> variable in the appropriate
3400 <filename>Makefile</filename>).
3407 For GHC < 4.00, add a suitable <option>-H</option> flag to the <filename>Makefile</filename>, as
3416 and try again: <command>gmake</command>. (see <xref linkend="sec-suffix"/> for information about
3417 <constant><module>_HC_OPTS</constant>.)
3419 Alternatively, just cut to the chase:
3421 <screen>$ cd ghc/compiler
3422 $ make EXTRA_HC_OPTS=-optCrts-M128M</screen>
3430 If you try to compile some Haskell, and you get errors from GCC about
3431 lots of things from <filename>/usr/include/math.h</filename>, then your GCC was
3432 mis-installed. <command>fixincludes</command> wasn't run when it should've been.
3434 As <command>fixincludes</command> is now automagically run as part of GCC installation,
3435 this bug also suggests that you have an old GCC.
3443 You <emphasis>may</emphasis> need to re-<command>ranlib</command><indexterm><primary>ranlib</primary></indexterm> your libraries (on Sun4s).
3446 <screen>$ cd $(libdir)/ghc-x.xx/sparc-sun-sunos4
3447 $ foreach i ( `find . -name '*.a' -print` ) # or other-shell equiv...
3449 ? # or, on some machines: ar s $i
3453 We'd be interested to know if this is still necessary.
3461 GHC's sources go through <command>cpp</command> before being compiled, and <command>cpp</command> varies
3462 a bit from one Unix to another. One particular gotcha is macro calls
3466 <programlisting>SLIT("Hello, world")</programlisting>
3469 Some <command>cpp</command>s treat the comma inside the string as separating two macro
3470 arguments, so you get
3473 <screen>:731: macro `SLIT' used with too many (2) args</screen>
3476 Alas, <command>cpp</command> doesn't tell you the offending file!
3478 Workaround: don't put weird things in string args to <command>cpp</command> macros.
3489 <sect1 id="platforms"><title>Platforms, scripts, and file names</title>
3491 GHC is designed both to be built, and to run, on both Unix and Windows. This flexibility
3492 gives rise to a good deal of brain-bending detail, which we have tried to collect in this chapter.
3495 <sect2 id="cygwin-and-mingw"><title>Windows platforms: Cygwin, MSYS, and MinGW</title>
3497 <para> The build system is built around Unix-y makefiles. Because it's not native,
3498 the Windows situation for building GHC is particularly confusing. This section
3499 tries to clarify, and to establish terminology.</para>
3501 <sect3 id="ghc-mingw"><title>MinGW</title>
3503 <para> <ulink url="http://www.mingw.org">MinGW (Minimalist GNU for Windows)</ulink>
3504 is a collection of header
3505 files and import libraries that allow one to use <command>gcc</command> and produce
3506 native Win32 programs that do not rely on any third-party DLLs. The
3507 current set of tools include GNU Compiler Collection (<command>gcc</command>), GNU Binary
3508 Utilities (Binutils), GNU debugger (Gdb), GNU make, and a assorted
3512 <para> The down-side of MinGW is that the MinGW libraries do not support anything like the full
3517 <sect3 id="ghc-cygwin"><title>Cygwin and MSYS</title>
3519 <para>You can't use the MinGW to <emphasis>build</emphasis> GHC, because MinGW doesn't have a shell,
3520 or the standard Unix commands such as <command>mv</command>, <command>rm</command>,
3521 <command>ls</command>, nor build-system stuff such as <command>make</command> and <command>darcs</command>.
3522 For that, there are two choices: <ulink url="http://www.cygwin.com">Cygwin</ulink>
3523 and <ulink url="http://www.mingw.org/msys.shtml">MSYS</ulink>:
3527 Cygwin comes with compilation tools (<command>gcc</command>, <command>ld</command> and so on), which
3528 compile code that has access to all of Posix. The price is that the executables must be
3529 dynamically linked with the Cygwin DLL, so that <emphasis>you cannot run a Cywin-compiled program on a machine
3530 that doesn't have Cygwin</emphasis>. Worse, Cygwin is a moving target. The name of the main DLL, <literal>cygwin1.dll</literal>
3531 does not change, but the implementation certainly does. Even the interfaces to functions
3532 it exports seem to change occasionally. </para>
3536 MSYS is a fork of the Cygwin tree, so they
3537 are fundamentally similar. However, MSYS is by design much smaller and simpler. Access to the file system goes
3538 through fewer layers, so MSYS is quite a bit faster too.
3541 <para>Furthermore, MSYS provides no compilation tools; it relies instead on the MinGW tools. These
3542 compile binaries that run with no DLL support, on any Win32 system.
3543 However, MSYS does come with all the make-system tools, such as <command>make</command>, <command>autoconf</command>,
3544 <command>darcs</command>, <command>ssh</command> etc. To get these, you have to download the
3545 MsysDTK (Developer Tool Kit) package, as well as the base MSYS package.
3547 <para>MSYS does have a DLL, but it's only used by MSYS commands (<command>sh</command>, <command>rm</command>,
3548 <command>ssh</command> and so on),
3549 not by programs compiled under MSYS.
3557 <sect3><title>Targeting MinGW</title>
3559 <para>We want GHC to compile programs that work on any Win32 system. Hence:
3562 GHC does invoke a C compiler, assembler, linker and so on, but we ensure that it only
3563 invokes the MinGW tools, not the Cygwin ones. That means that the programs GHC compiles
3564 will work on any system, but it also means that the programs GHC compiles do not have access
3565 to all of Posix. In particular, they cannot import the (Haskell) Posix
3566 library; they have to do
3567 their input output using standard Haskell I/O libraries, or native Win32 bindings.</para>
3568 <para> We will call a GHC that targets MinGW in this way <emphasis>GHC-mingw</emphasis>.</para>
3572 To make the GHC distribution self-contained, the GHC distribution includes the MinGW <command>gcc</command>,
3573 <command>as</command>, <command>ld</command>, and a bunch of input/output libraries.
3576 So <emphasis>GHC targets MinGW</emphasis>, not Cygwin.
3577 It is in principle possible to build a version of GHC, <emphasis>GHC-cygwin</emphasis>,
3578 that targets Cygwin instead. The up-side of GHC-cygwin is
3579 that Haskell programs compiled by GHC-cygwin can import the (Haskell) Posix library.
3580 <emphasis>We do not support GHC-cygwin, however; it is beyond our resources.</emphasis>
3583 <para>While GHC <emphasis>targets</emphasis> MinGW, that says nothing about
3584 how GHC is <emphasis>built</emphasis>. We use both MSYS and Cygwin as build environments for
3585 GHC; both work fine, though MSYS is rather lighter weight.</para>
3587 <para>In your build tree, you build a compiler called <command>ghc-inplace</command>. It
3588 uses the <command>gcc</command> that you specify using the
3589 <option>--with-gcc</option> flag when you run
3590 <command>configure</command> (see below).
3591 The makefiles are careful to use <command>ghc-inplace</command> (not <command>gcc</command>)
3592 to compile any C files, so that it will in turn invoke the correct <command>gcc</command> rather that
3593 whatever one happens to be in your path. However, the makefiles do use whatever <command>ld</command>
3594 and <command>ar</command> happen to be in your path. This is a bit naughty, but (a) they are only
3595 used to glom together .o files into a bigger .o file, or a .a file,
3596 so they don't ever get libraries (which would be bogus; they might be the wrong libraries), and (b)
3597 Cygwin and MinGW use the same .o file format. So its ok.
3601 <sect3><title> File names </title>
3603 <para>Cygwin, MSYS, and the underlying Windows file system all understand file paths of form <literal>c:/tmp/foo</literal>.
3607 MSYS programs understand <filename>/bin</filename>, <filename>/usr/bin</filename>, and map Windows's lettered drives as
3608 <filename>/c/tmp/foo</filename> etc. The exact mount table is given in the doc subdirectory of the MSYS distribution.
3610 <para> When it invokes a command, the MSYS shell sees whether the invoked binary lives in the MSYS <filename>/bin</filename>
3611 directory. If so, it just invokes it. If not, it assumes the program is no an MSYS program, and walks over the command-line
3612 arguments changing MSYS paths into native-compatible paths. It does this inside sub-arguments and inside quotes. For example,
3614 <programlisting>foogle -B/c/tmp/baz</programlisting>
3615 the MSYS shell will actually call <literal>foogle</literal> with argument <literal>-Bc:/tmp/baz</literal>.
3619 Cygwin programs have a more complicated mount table, and map the lettered drives as <filename>/cygdrive/c/tmp/foo</filename>.
3621 <para>The Cygwin shell does no argument processing when invoking non-Cygwin programs.
3627 <sect3><title>Crippled <command>ld</command></title>
3630 It turns out that on both Cygwin and MSYS, the <command>ld</command> has a
3631 limit of 32kbytes on its command line. Especially when using split object
3632 files, the make system can emit calls to <command>ld</command> with thousands
3633 of files on it. Then you may see something like this:
3635 (cd Graphics/Rendering/OpenGL/GL/QueryUtils_split && /mingw/bin/ld -r -x -o ../QueryUtils.o *.o)
3636 /bin/sh: /mingw/bin/ld: Invalid argument
3638 The solution is either to switch off object file splitting (set
3639 <option>SplitObjs</option> to <literal>NO</literal> in your
3640 <filename>build.mk</filename>),
3641 or to make the module smaller.
3645 <sect3><title>Host System vs Target System</title>
3648 In the source code you'll find various ifdefs looking like:
3649 <programlisting>#ifdef mingw32_HOST_OS
3651 #endif</programlisting>
3653 <programlisting>#ifdef mingw32_TARGET_OS
3655 #endif</programlisting>
3656 These macros are set by the configure script (via the file config.h).
3657 Which is which? The criterion is this. In the ifdefs in GHC's source code:
3660 <para>The "host" system is the one on which GHC itself will be run.</para>
3663 <para>The "target" system is the one for which the program compiled by GHC will be run.</para>
3666 For a stage-2 compiler, in which GHCi is available, the "host" and "target" systems must be the same.
3667 So then it doesn't really matter whether you use the HOST_OS or TARGET_OS cpp macros.
3674 <sect2><title>Wrapper scripts</title>
3677 Many programs, including GHC itself and hsc2hs, need to find associated binaries and libraries.
3678 For <emphasis>installed</emphasis> programs, the strategy depends on the platform. We'll use
3679 GHC itself as an example:
3682 On Unix, the command <command>ghc</command> is a shell script, generated by adding installation
3683 paths to the front of the source file <filename>ghc.sh</filename>,
3684 that invokes the real binary, passing "-B<emphasis>path</emphasis>" as an argument to tell <command>ghc</command>
3685 where to find its supporting files.
3689 On vanilla Windows, it turns out to be much harder to make reliable script to be run by the
3690 native Windows shell <command>cmd</command> (e.g. limits on the length
3691 of the command line). So instead we invoke the GHC binary directly, with no -B flag.
3692 GHC uses the Windows <literal>getExecDir</literal> function to find where the executable is,
3693 and from that figures out where the supporting files are.
3696 (You can find the layout of GHC's supporting files in the
3697 section "Layout of installed files" of Section 2 of the GHC user guide.)
3700 Things work differently for <emphasis>in-place</emphasis> execution, where you want to
3701 execute a program that has just been built in a build tree. The difference is that the
3702 layout of the supporting files is different.
3703 In this case, whether on Windows or Unix, we always use a shell script. This works OK
3704 on Windows because the script is executed by MSYS or Cygwin, which don't have the
3705 shortcomings of the native Windows <command>cmd</command> shell.
3712 <sect1 id="winbuild"><title>Instructions for building under Windows</title>
3715 This section gives detailed instructions for how to build
3716 GHC from source on your Windows machine. Similar instructions for
3717 installing and running GHC may be found in the user guide. In general,
3718 Win95/Win98 behave the same, and WinNT/Win2k behave the same.
3721 Make sure you read the preceding section on platforms (<xref linkend="platforms"/>)
3722 before reading section.
3723 You don't need Cygwin or MSYS to <emphasis>use</emphasis> GHC,
3724 but you do need one or the other to <emphasis>build</emphasis> GHC.</para>
3727 <sect2 id="msys-install"><title>Installing and configuring MSYS</title>
3730 MSYS is a lightweight alternative to Cygwin.
3731 You don't need MSYS to <emphasis>use</emphasis> GHC,
3732 but you do need it or Cygwin to <emphasis>build</emphasis> GHC.
3733 Here's how to install MSYS.
3736 Go to <ulink url="http://www.mingw.org/download.shtml">http://www.mingw.org/download.shtml</ulink> and
3737 download the following (of course, the version numbers will differ):
3739 <listitem><para>The main MSYS package (binary is sufficient): <literal>MSYS-1.0.9.exe</literal>
3741 <listitem><para>The MSYS developer's toolkit (binary is sufficient): <literal>msysDTK-1.0.1.exe</literal>.
3742 This provides <command>make</command>, <command>autoconf</command>,
3743 <command>ssh</command> and probably more besides.
3746 Run both executables (in the order given above) to install them. I put them in <literal>c:/msys</literal>
3750 Set the following environment variables
3752 <listitem><para><literal>PATH</literal>: add <literal>c:/msys/1.0/bin</literal> and
3753 <literal>c:/msys/1.0/local/bin</literal>
3754 to your path. (Of course, the version number may differ.)
3755 MSYS mounts the former as both <literal>/bin</literal> and
3756 <literal>/usr/bin</literal> and the latter as <literal>/usr/local/bin</literal>.
3759 <listitem><para><literal>HOME</literal>: set to your home directory (e.g. <literal>c:/userid</literal>).
3760 This is where, among other things, <command>ssh</command> will look for your <literal>.ssh</literal> directory.
3763 <listitem><para><literal>SHELL</literal>: set to <literal>c:/msys/1.0/bin/sh.exe</literal>
3766 <listitem><para><literal>CVS_RSH</literal>: set to <literal>c:/msys/1.0/bin/ssh.exe</literal>. Only necessary if
3770 <listitem><para><literal>MAKE_MODE</literal>: set to <literal>UNIX</literal>. (I'm not certain this is necessary for MSYS.)
3777 Check that the <literal>CYGWIN</literal> environment variable is <emphasis>not</emphasis> set. It's a bad bug
3778 that MSYS is affected by this, but if you have CYGWIN set to "ntsec ntea", which is right for Cygwin, it
3779 causes the MSYS <command>ssh</command> to bogusly fail complaining that your <filename>.ssh/identity</filename>
3780 file has too-liberal permissinos.
3785 <para>Here are some points to bear in mind when using MSYS:
3787 <listitem> <para> MSYS does some kind of special magic to binaries stored in
3788 <filename>/bin</filename> and <filename>/usr/bin</filename>, which are by default both mapped
3789 to <filename>c:/msys/1.0/bin</filename> (assuming you installed MSYS in <filename>c:/msys</filename>).
3790 Do not put any other binaries (such as GHC or Alex) in this directory or its sub-directories:
3791 they fail in mysterious ways. However, it's fine to put other binaries in <filename>/usr/local/bin</filename>,
3792 which maps to <filename>c:/msys/1.0/local/bin</filename>.</para></listitem>
3794 <listitem> <para> MSYS seems to implement symbolic links by copying, so sharing is lost.
3798 Win32 has a <command>find</command> command which is not the same as MSYS's find.
3799 You will probably discover that the Win32 <command>find</command> appears in your <constant>PATH</constant>
3800 before the MSYS one, because it's in the <emphasis>system</emphasis> <constant>PATH</constant>
3801 environment variable, whereas you have probably modified the <emphasis>user</emphasis> <constant>PATH</constant>
3802 variable. You can always invoke <command>find</command> with an absolute path, or rename it.
3806 MSYS comes with <command>bzip</command>, and MSYS's <command>tar</command>'s <literal>-j</literal>
3807 will bunzip an archive (e.g. <literal>tar xvjf foo.tar.bz2</literal>). Useful when you get a
3808 bzip'd dump.</para></listitem>
3814 <sect2 id="install-cygwin"><title>Installing and configuring Cygwin</title>
3816 <para> Install Cygwin from <ulink url="http://www.cygwin.com/">http://www.cygwin.com/</ulink>.
3817 The installation process is straightforward; we install it in
3818 <filename>c:/cygwin</filename>.</para>
3820 You must install enough Cygwin <emphasis>packages</emphasis> to support
3821 building GHC. If you miss out any of these, strange things will happen to you. There are two ways to do this:
3823 <listitem><para>The direct, but laborious way is to
3824 select all of the following packages in the installation dialogue:
3825 <command>cvs</command>,
3826 <command>openssh</command>,
3827 <command>autoconf</command>,
3828 <command>binutils</command> (includes ld and (I think) ar),
3829 <command>gcc</command>,
3830 <command>flex</command>,
3831 <command>make</command>.
3832 To see thse packages,
3833 click on the "View" button in the "Select Packages"
3834 stage of Cygwin's installation dialogue, until the view says "Full". The default view, which is
3835 "Category" isn't very helpful, and the "View" button is rather unobtrousive.
3839 <listitem><para>The clever way is to point the Cygwin installer at the
3840 <command>ghc-depends</command> package, which is kept at <ulink
3841 url="http://haskell.org/ghc/cygwin">http://haskell.org/ghc/cygwin</ulink>.
3842 When the Cygwin installer asks you to "Choose a Download Site", choose one of
3844 offered mirror sites; and then type "http://haskell.org/ghc/cygwin" into the
3845 "User URL" box and click "Add"; now two sites are selected. (The Cygwin
3846 installer remembers this for next time.)
3847 Click "Next".</para>
3848 <para>In the "Select Packages" dialogue box that follows, click the "+" sign by
3849 "Devel", scroll down to the end of the "Devel" packages, and choose
3850 <command>ghc-depends</command>.
3851 The package <command>ghc-depends</command> will not actually install anything itself,
3852 but forces additional packages to be added by the Cygwin installer.
3858 <para> Now set the following user environment variables:
3861 <listitem><para> Add <filename>c:/cygwin/bin</filename> and <filename>c:/cygwin/usr/bin</filename> to your
3862 <constant>PATH</constant></para></listitem>
3866 Set <constant>MAKE_MODE</constant> to <literal>UNIX</literal>. If you
3867 don't do this you get very weird messages when you type
3868 <command>make</command>, such as:
3869 <screen>/c: /c: No such file or directory</screen>
3873 <listitem><para> Set <constant>SHELL</constant> to
3874 <filename>c:/cygwin/bin/bash</filename>. When you invoke a shell in Emacs, this
3875 <constant>SHELL</constant> is what you get.
3878 <listitem><para> Set <constant>HOME</constant> to point to your
3879 home directory. This is where, for example,
3880 <command>bash</command> will look for your <filename>.bashrc</filename>
3881 file. Ditto <command>emacs</command> looking for <filename>.emacsrc</filename>
3886 <para>Here are some things to be aware of when using Cygwin:
3888 <listitem> <para>Cygwin doesn't deal well with filenames that include
3889 spaces. "<filename>Program Files</filename>" and "<filename>Local files</filename>" are
3893 <listitem> <para> Cygwin implements a symbolic link as a text file with some
3894 magical text in it. So other programs that don't use Cygwin's
3895 I/O libraries won't recognise such files as symlinks.
3896 In particular, programs compiled by GHC are meant to be runnable
3897 without having Cygwin, so they don't use the Cygwin library, so
3898 they don't recognise symlinks.
3902 See the notes in <xref linkend="msys-install"/> about <command>find</command> and <command>bzip</command>,
3903 which apply to Cygwin too.
3908 Some script files used in the make system start with "<command>#!/bin/perl</command>",
3909 (and similarly for <command>sh</command>). Notice the hardwired path!
3910 So you need to ensure that your <filename>/bin</filename> directory has at least
3911 <command>sh</command>, <command>perl</command>, and <command>cat</command> in it.
3912 All these come in Cygwin's <filename>bin</filename> directory, which you probably have
3913 installed as <filename>c:/cygwin/bin</filename>. By default Cygwin mounts "<filename>/</filename>" as
3914 <filename>c:/cygwin</filename>, so if you just take the defaults it'll all work ok.
3915 (You can discover where your Cygwin
3916 root directory <filename>/</filename> is by typing <command>mount</command>.)
3917 Provided <filename>/bin</filename> points to the Cygwin <filename>bin</filename>
3918 directory, there's no need to copy anything. If not, copy these binaries from the <filename>cygwin/bin</filename>
3919 directory (after fixing the <filename>sh.exe</filename> stuff mentioned in the previous bullet).
3925 By default, cygwin provides the command shell <filename>ash</filename>
3926 as <filename>sh.exe</filename>. It seems to be fine now, but in the past we
3927 saw build-system problems that turned out to be due to bugs in <filename>ash</filename>
3928 (to do with quoting and length of command lines). On the other hand <filename>bash</filename> seems
3930 If this happens to you (which it shouldn't), in <filename>cygwin/bin</filename>
3931 remove the supplied <filename>sh.exe</filename> (or rename it as <filename>ash.exe</filename>),
3932 and copy <filename>bash.exe</filename> to <filename>sh.exe</filename>.
3933 You'll need to do this in Windows Explorer or the Windows <command>cmd</command> shell, because
3934 you can't rename a running program!
3943 <sect2 id="configure-ssh"><title>Configuring SSH</title>
3945 <para><command>ssh</command> comes with both Cygwin and MSYS.
3946 (Cygwin note: you need to ask for package <command>openssh</command> (not ssh)
3947 in the Cygwin list of packages; or use the <command>ghc-depends</command>
3948 package -- see <xref linkend="install-cygwin"/>.)</para>
3950 <para>There are several strange things about <command>ssh</command> on Windows that you need to know.
3954 The programs <command>ssh-keygen1</command>, <command>ssh1</command>, and <command>cvs</command>,
3955 seem to lock up <command>bash</command> entirely if they try to get user input (e.g. if
3956 they ask for a password). To solve this, start up <filename>cmd.exe</filename>
3957 and run it as follows:
3958 <screen>c:\tmp> set CYGWIN32=tty
3959 c:\tmp> c:/user/local/bin/ssh-keygen1</screen> </para>
3962 <listitem><para> (Cygwin-only problem, I think.)
3963 <command>ssh</command> needs to access your directory <filename>.ssh</filename>, in your home directory.
3964 To determine your home directory <command>ssh</command> first looks in
3965 <filename>c:/cygwin/etc/passwd</filename> (or wherever you have Cygwin installed). If there's an entry
3966 there with your userid, it'll use that entry to determine your home directory, <emphasis>ignoring
3967 the setting of the environment variable $HOME</emphasis>. If the home directory is
3968 bogus, <command>ssh</command> fails horribly. The best way to see what is going on is to say
3969 <screen>ssh -v cvs.haskell.org</screen>
3970 which makes <command>ssh</command> print out information about its activity.
3972 <para> You can fix this problem, either by correcting the home-directory field in
3973 <filename>c:/cygwin/etc/passwd</filename>, or by simply deleting the entire entry for your userid. If
3974 you do that, <command>ssh</command> uses the $HOME environment variable instead.
3980 <para>To protect your
3981 <literal>.ssh</literal> from access by anyone else,
3982 right-click your <literal>.ssh</literal> directory, and
3983 select <literal>Properties</literal>. If you are not on
3984 the access control list, add yourself, and give yourself
3985 full permissions (the second panel). Remove everyone else
3986 from the access control list. Don't leave them there but
3987 deny them access, because 'they' may be a list that
3988 includes you!</para>
3992 <para>In fact <command>ssh</command> 3.6.1 now seems to <emphasis>require</emphasis>
3993 you to have Unix permissions 600 (read/write for owner only)
3994 on the <literal>.ssh/identity</literal> file, else it
3995 bombs out. For your local C drive, it seems that <literal>chmod 600 identity</literal> works,
3996 but on Windows NT/XP, it doesn't work on a network drive (exact dteails obscure).
3997 The solution seems to be to set the $CYGWIN environment
3998 variable to "<literal>ntsec neta</literal>". The $CYGWIN environment variable is discussed
3999 in <ulink url="http://cygwin.com/cygwin-ug-net/using-cygwinenv.html">the Cygwin User's Guide</ulink>,
4000 and there are more details in <ulink url="http://cygwin.com/faq/faq_4.html#SEC44">the Cygwin FAQ</ulink>.
4007 <sect2><title>Other things you need to install</title>
4009 <para>You have to install the following other things to build GHC, listed below.</para>
4011 <para>On Windows you often install executables in directories with spaces, such as
4012 "<filename>Program Files</filename>". However, the <literal>make</literal> system for fptools doesn't
4013 deal with this situation (it'd have to do more quoting of binaries), so you are strongly advised
4014 to put binaries for all tools in places with no spaces in their path.
4015 On both MSYS and Cygwin, it's perfectly OK to install such programs in the standard Unixy places,
4016 <filename>/usr/local/bin</filename> and <filename>/usr/local/lib</filename>. But it doesn't matter,
4017 provided they are in your path.
4021 Install an executable GHC, from <ulink url="http://www.haskell.org/ghc">http://www.haskell.org/ghc</ulink>.
4022 This is what you will use to compile GHC. Add it in your
4023 <constant>PATH</constant>: the installer tells you the path element
4024 you need to add upon completion.
4030 Install an executable Happy, from <ulink url="http://www.haskell.org/happy">http://www.haskell.org/happy</ulink>.
4031 Happy is a parser generator used to compile the Haskell grammar. Under MSYS or Cygwin you can easily
4032 build it from the source distribution using
4033 <screen>$ ./configure
4035 $ make install</screen>
4036 This should install it in <filename>/usr/local/bin</filename> (which maps to <filename>c:/msys/1.0/local/bin</filename>
4038 Make sure the installation directory is in your
4039 <constant>PATH</constant>.
4044 <para>Install an executable Alex. This can be done by building from the
4045 source distribution in the same way as Happy. Sources are
4046 available from <ulink
4047 url="http://www.haskell.org/alex">http://www.haskell.org/alex</ulink>.</para>
4051 <para>GHC uses the <emphasis>mingw</emphasis> C compiler to
4052 generate code, so you have to install that (see <xref linkend="cygwin-and-mingw"/>).
4053 Just pick up a mingw bundle at
4054 <ulink url="http://www.mingw.org/">http://www.mingw.org/</ulink>.
4055 We install it in <filename>c:/mingw</filename>.
4058 <para><emphasis>On MSYS</emphasis>, add <literal>c:/mingw/bin</literal> to your PATH. MSYS does not provide <command>gcc</command>,
4059 <command>ld</command>, <command>ar</command>, and so on, because it just uses the MinGW ones. So you need them
4063 <para><emphasis>On Cygwin, do not</emphasis> add any of the <emphasis>mingw</emphasis> binaries to your path.
4064 They are only going to get used by explicit access (via the --with-gcc flag you
4065 give to <command>configure</command> later). If you do add them to your path
4066 you are likely to get into a mess because their names overlap with Cygwin
4068 On the other hand, you <emphasis>do</emphasis> need <command>ld</command>, <command>ar</command>
4069 (and perhaps one or two other things) in your path. The Cygwin ones are fine,
4070 but you must have them; hence needing the Cygwin binutils package.
4076 <para>We use <command>emacs</command> a lot, so we install that too.
4077 When you are in <filename>fptools/ghc/compiler</filename>, you can use
4078 "<literal>make tags</literal>" to make a TAGS file for emacs. That uses the utility
4079 <filename>fptools/ghc/utils/hasktags/hasktags</filename>, so you need to make that first.
4080 The most convenient way to do this is by going <literal>make boot</literal> in <filename>fptools/ghc</filename>.
4081 The <literal>make tags</literal> command also uses <command>etags</command>, which comes with <command>emacs</command>,
4082 so you will need to add <filename>emacs/bin</filename> to your <literal>PATH</literal>.
4087 <para>You might want to install GLUT in your MSYS/Cygwin
4088 installation, otherwise the GLUT package will not be built with
4093 <para> Finally, check out a copy of GHC sources from
4094 the darcs repository, following the instructions at <ulink url="http://hackage.haskell.org/trac/ghc/wiki/GhcDarcs" />.</para>
4100 <sect2><title>Building GHC</title>
4103 Now go read the documentation above on building from source (<xref linkend="sec-building-from-source"/>);
4104 the bullets below only tell
4105 you about Windows-specific wrinkles.</para>
4109 If you used <command>autoconf</command> instead of <command>autoreconf</command>,
4110 you'll get an error when you run <filename>./configure</filename>:
4113 creating mk/config.h
4114 mk/config.h is unchanged
4116 running /bin/sh ./configure --cache-file=.././config.cache --srcdir=.
4117 ./configure: ./configure: No such file or directory
4118 configure: error: ./configure failed for ghc</screen>
4122 <listitem> <para><command>autoreconf</command> seems to create the file <filename>configure</filename>
4123 read-only. So if you need to run autoreconf again (which I sometimes do for safety's sake),
4125 <screen>/usr/bin/autoconf: cannot create configure: permission denied</screen>
4126 Solution: delete <filename>configure</filename> first.
4131 After <command>autoreconf</command> run <command>./configure</command> in
4132 <filename>fptools/</filename> thus:
4134 <screen>$ ./configure --host=i386-unknown-mingw32 --with-gcc=c:/mingw/bin/gcc</screen>
4135 This is the point at which you specify that you are building GHC-mingw
4136 (see <xref linkend="ghc-mingw"/>). </para>
4138 <para> Both these options are important! It's possible to get into
4139 trouble using the wrong C compiler!</para>
4141 Furthermore, it's <emphasis>very important</emphasis> that you specify a
4142 full MinGW path for <command>gcc</command>, not a Cygwin path, because GHC (which
4143 uses this path to invoke <command>gcc</command>) is a MinGW program and won't
4144 understand a Cygwin path. For example, if you
4145 say <literal>--with-gcc=/mingw/bin/gcc</literal>, it'll be interpreted as
4146 <filename>/cygdrive/c/mingw/bin/gcc</filename>, and GHC will fail the first
4147 time it tries to invoke it. Worse, the failure comes with
4148 no error message whatsoever. GHC simply fails silently when first invoked,
4149 typically leaving you with this:
4150 <screen>make[4]: Leaving directory `/cygdrive/e/fptools-stage1/ghc/rts/gmp'
4151 ../../ghc/compiler/ghc-inplace -optc-mno-cygwin -optc-O
4152 -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes
4153 -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
4154 -optc-Wbad-function-cast -optc-Wcast-align -optc-I../includes
4155 -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS
4156 -optc-fomit-frame-pointer -O2 -static
4157 -package-name rts -O -dcore-lint -c Adjustor.c -o Adjustor.o
4158 make[2]: *** [Adjustor.o] Error 1
4159 make[1]: *** [all] Error 1
4160 make[1]: Leaving directory `/cygdrive/e/fptools-stage1/ghc'
4161 make: *** [all] Error 1</screen>
4166 If you want to build GHC-cygwin (<xref linkend="ghc-cygwin"/>)
4167 you'll have to do something more like:
4168 <screen>$ ./configure --with-gcc=...the Cygwin gcc...</screen>
4173 If you are paranoid, delete <filename>config.cache</filename> if it exists.
4174 This file occasionally remembers out-of-date configuration information, which
4175 can be really confusing.
4179 <listitem><para> You almost certainly want to set
4180 <programlisting>SplitObjs = NO</programlisting>
4181 in your <filename>build.mk</filename> configuration file (see <xref linkend="sec-build-config"/>).
4182 This tells the build system not to split each library into a myriad of little object files, one
4183 for each function. Doing so reduces binary sizes for statically-linked binaries, but on Windows
4184 it dramatically increases the time taken to build the libraries in the first place.
4188 <listitem><para> Do not attempt to build the documentation.
4189 It needs all kinds of wierd Jade stuff that we haven't worked out for
4190 Win32.</para></listitem>
4195 <sect2><title>A Windows build log using Cygwin</title>
4197 <para>Here is a complete, from-scratch, log of all you need to build GHC using
4198 Cygwin, kindly provided by Claus Reinke. It does not discuss alternative
4199 choices, but it gives a single path that works.</para>
4200 <programlisting>- Install some editor (vim, emacs, whatever)
4202 - Install cygwin (http://www.cygwin.com)
4203 ; i used 1.5.16-1, installed in c:\cygwin
4205 Choose a Download Source:
4206 select 'download from internet';
4207 Select Root Install Directory:
4208 root dir: c:\cygwin;
4209 install for: all users;
4210 default file type: unix
4211 Select Local Package Directory
4212 choose a spare temporary home
4213 Select Your Internet Connection
4215 Choose a Download Site
4216 Choose your preferred main mirror and
4217 Add 'http://www.haskell.org/ghc/cygwin'
4219 In addition to 'Base' (default install),
4220 select 'Devel->ghc-depends'
4222 - Install mingw (http://www.mingw.org/)
4223 ; i used MinGW-3.1.0-1.exe
4224 ; installed in c:\mingw
4225 - you probably want to add GLUT
4226 ; (http://www.xmission.com/~nate/glut.html)
4227 ; i used glut-3.7.3-mingw32.tar
4229 - Get recent binary snapshot of ghc-6.4.1 for mingw
4230 ; (http://www.haskell.org/ghc/dist/stable/dist/)
4232 - add C:\ghc\ghc-6.4.1\bin to %PATH%
4233 (Start->Control Panel->System->Advanced->Environment Variables)
4235 - Get darcs version of ghc
4236 ; also, subscribe to cvs-all@haskell.org, or follow the mailing list
4237 ; archive, in case you checkout a version with problems
4238 ; http://www.haskell.org//pipermail/cvs-all/
4239 - mkdir c:/fptools; cd c:/fptools
4240 ; (or whereever you want your darcs tree to be)
4241 - darcs get http://darcs.haskell.org/ghc
4243 - chmod +x darcs-all
4246 - Build ghc, using cygwin and mingw, targetting mingw
4247 - export PATH=/cygdrive/c/ghc/ghc-6.4.1:$PATH
4248 ; for haddock, alex, happy (*)
4249 - export PATH=/cygdrive/c/mingw/bin:$PATH
4250 ; without, we pick up some cygwin tools at best!
4251 - cd c:/fptools/fptools
4252 ; (if you aren't there already)
4254 - ./configure --host=i386-unknown-mingw32 --with-gcc=C:/Mingw/bin/gcc.exe
4255 ; we use cygwin, but build for windows
4256 - cp mk/build.mk.sample mk/build.mk
4258 add line: SplitObjs = NO
4259 (MSYS seems slow when there are zillions of object files)
4260 uncomment line: BuildFlavour = perf
4261 (or BuildFlavour = devel, if you are doing development)
4262 add line: BIN_DIST=1
4263 - make 2>&1 | tee make.log
4264 ; always useful to have a log around
4266 - Package up binary distribution
4267 - make binary-dist Project=Ghc 2>&1 | tee make-bin-dist.log
4268 ; always useful to have a log around
4270 - chmod +x ../distrib/prep-bin-dist-mingw
4271 ; if you're happy with the script's contents (*)
4272 - ../distrib/prep-bin-dist-mingw
4273 ; then tar up, unpack where wanted, and enjoy</programlisting>
projects / ghc-hetmet.git / blob