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. <ulink
100 url="http://hackage.haskell.org/trac/ghc/wiki/Platforms">GHC
101 Platform Support</ulink> lists the currently supported
102 platforms; if yours isn't amongst these then you can try
103 porting GHC (see <xref linkend="sec-porting-ghc"/>).</para>
107 <para>Be sure that the “pre-supposed” utilities are
108 installed. <xref linkend="sec-pre-supposed"/>
113 <para>If you have any problem when building or installing the
114 Glasgow tools, please check the “known pitfalls” (<xref
115 linkend="sec-build-pitfalls"/>). Also check the FAQ for the
116 version you're building, which is part of the User's Guide and
117 available on the <ulink url="http://www.haskell.org/ghc/" >GHC web
120 <indexterm><primary>bugs</primary><secondary>known</secondary></indexterm>
122 <para>If you feel there is still some shortcoming in our
123 procedure or instructions, please report it.</para>
125 <para>For GHC, please see the <ulink
126 url="http://www.haskell.org/ghc/docs/latest/set/bug-reporting.html">bug-reporting
127 section of the GHC Users' Guide</ulink>, to maximise the
128 usefulness of your report.</para>
130 <indexterm><primary>bugs</primary><secondary>seporting</secondary></indexterm>
131 <para>If in doubt, please send a message to
132 <email>glasgow-haskell-bugs@haskell.org</email>.
133 <indexterm><primary>bugs</primary><secondary>mailing
134 list</secondary></indexterm></para>
139 <sect1 id="sec-pre-supposed">
140 <title>Installing pre-supposed utilities</title>
142 <indexterm><primary>pre-supposed utilities</primary></indexterm>
143 <indexterm><primary>utilities, pre-supposed</primary></indexterm>
145 <para>Here are the gory details about some utility programs you
146 may need; <command>perl</command>, <command>gcc</command> and
147 <command>happy</command> are the only important
148 ones. (PVM<indexterm><primary>PVM</primary></indexterm> is
149 important if you're going for Parallel Haskell.) The
150 <command>configure</command><indexterm><primary>configure</primary></indexterm>
151 script will tell you if you are missing something.</para>
157 <indexterm><primary>pre-supposed: GHC</primary></indexterm>
158 <indexterm><primary>GHC, pre-supposed</primary></indexterm>
161 <para>GHC is required to build GHC, because GHC itself is
162 written in Haskell, and uses GHC extensions. It is possible
163 to build GHC using just a C compiler, and indeed some
164 distributions of GHC do just that, but it isn't the best
165 supported method, and you may encounter difficulties. Full
166 instructions are in <xref linkend="sec-porting-ghc"/>.</para>
168 <para>Which version of GHC you need will depend on the
169 packages you intend to build. GHC itself will normally
170 build using one of several older versions of itself - check
171 the announcement or release notes for details.</para>
177 <indexterm><primary>pre-supposed: Perl</primary></indexterm>
178 <indexterm><primary>Perl, pre-supposed</primary></indexterm>
181 <para><emphasis>You have to have Perl to proceed!</emphasis>
182 Perl version 5 at least is required. GHC has been known to
183 tickle bugs in Perl, so if you find that Perl crashes when
184 running GHC try updating (or downgrading) your Perl
185 installation. Versions of Perl before 5.6 have been known to have
186 various bugs tickled by GHC, so the configure script
187 will look for version 5.6 or later.</para>
189 <para>For Win32 platforms, you should use the binary
190 supplied in the InstallShield (copy it to
191 <filename>/bin</filename>). The Cygwin-supplied Perl seems
194 <para>Perl should be put somewhere so that it can be invoked
195 by the <literal>#!</literal> script-invoking
196 mechanism. The full pathname may need to be less than 32
197 characters long on some systems.</para>
202 <term>GNU C (<command>gcc</command>)
203 <indexterm><primary>pre-supposed: GCC (GNU C compiler)</primary></indexterm>
204 <indexterm><primary>GCC (GNU C compiler), pre-supposed</primary></indexterm>
207 <para>Most GCC versions should work with the most recent GHC
208 sources. Expect trouble if you use a recent GCC with
209 an older GHC, though (trouble in the form of mis-compiled code,
210 link errors, and errors from the <literal>ghc-asm</literal>
213 <para>If your GCC dies with “internal error” on
214 some GHC source file, please let us know, so we can report
215 it and get things improved. (Exception: on x86
216 boxes—you may need to fiddle with GHC's
217 <option>-monly-N-regs</option> option; see the User's
224 <indexterm><primary>make</primary><secondary>GNU</secondary></indexterm>
227 <para>The GHC build system makes heavy use of features
228 specific to GNU <command>make</command>, so you must have
229 this installed in order to build GHC.</para>
231 <para>NB. it has been reported that version 3.79 no longer
232 works to build GHC, and 3.80 is required.</para>
237 <term><ulink url="http://www.haskell.org/happy">Happy</ulink>
238 <indexterm><primary>Happy</primary></indexterm>
241 <para>Happy is a parser generator tool for Haskell, and is
242 used to generate GHC's parsers.</para>
244 <para>If you start from a source tarball of GHC (i.e. not a darcs
245 checkout), then you don't need Happy, because we supply the
246 pre-processed versions of the Happy parsers. If you intend to
247 modify the compiler and/or you're using a darcs checkout, then you
250 <para>Happy version 1.15 is currently required to build GHC.
251 Grab a copy from <ulink
252 url="http://www.haskell.org/happy/">Happy's Web
259 <indexterm><primary>Alex</primary></indexterm>
262 <para>Alex is a lexical-analyser generator for Haskell,
263 which GHC uses to generate its lexer.</para>
265 <para>Like Happy, you don't need Alex if you're building GHC from a
266 source tarball, but you do need it if you're modifying GHC and/or
267 building a darcs checkout.</para>
270 written in Haskell and is a project in the darcs repository.
271 Alex distributions are available from <ulink url="http://www.haskell.org/alex/">Alex's Web
278 <indexterm><primary>pre-supposed: autoconf</primary></indexterm>
279 <indexterm><primary>autoconf, pre-supposed</primary></indexterm>
282 <para>GNU autoconf is needed if you intend to build from the
283 darcs sources, it is <emphasis>not</emphasis> needed if you
284 just intend to build a standard source distribution.</para>
286 <para>Version 2.52 or later of the autoconf package is required.
287 NB. version 2.13 will no longer work, as of GHC version
290 <para><command>autoreconf</command> (from the autoconf package)
291 recursively builds <command>configure</command> scripts from
292 the corresponding <filename>configure.ac</filename> and
293 <filename>aclocal.m4</filename> files. If you modify one of
294 the latter files, you'll need <command>autoreconf</command> to
295 rebuild the corresponding <filename>configure</filename>.</para>
300 <term><command>sed</command>
301 <indexterm><primary>pre-supposed: sed</primary></indexterm>
302 <indexterm><primary>sed, pre-supposed</primary></indexterm>
305 <para>You need a working <command>sed</command> if you are
306 going to build from sources. The build-configuration stuff
307 needs it. GNU sed version 2.0.4 is no good! It has a bug
308 in it that is tickled by the build-configuration. 2.0.5 is
309 OK. Others are probably OK too (assuming we don't create too
310 elaborate configure scripts.)</para>
315 <sect2 id="pre-supposed-gph-tools">
316 <title>Tools for building parallel GHC (GPH)</title>
321 <indexterm><primary>pre-supposed: PVM3 (Parallel Virtual Machine)</primary></indexterm>
322 <indexterm><primary>PVM3 (Parallel Virtual Machine), pre-supposed</primary></indexterm>
325 <para>PVM is the Parallel Virtual Machine on which
326 Parallel Haskell programs run. (You only need this if you
327 plan to run Parallel Haskell. Concurrent Haskell, which
328 runs concurrent threads on a uniprocessor doesn't need
329 it.) Underneath PVM, you can have (for example) a network
330 of workstations (slow) or a multiprocessor box
333 <para>The current version of PVM is 3.3.11; we use 3.3.7.
334 It is readily available on the net; I think I got it from
335 <literal>research.att.com</literal>, in
336 <filename>netlib</filename>.</para>
338 <para>A PVM installation is slightly quirky, but easy to
339 do. Just follow the <filename>Readme</filename>
345 <term><command>bash</command>:
346 <indexterm><primary>bash, presupposed (Parallel Haskell only)</primary></indexterm>
349 <para>Sadly, the <command>gr2ps</command> script, used to
350 convert “parallelism profiles” to PostScript,
351 is written in Bash (GNU's Bourne Again shell). This bug
352 will be fixed (someday).</para>
357 <para>More tools are required if you want to format the
358 documentation that comes with GHC. See <xref
359 linkend="building-docs"/>.</para>
363 <sect1 id="sec-building-from-source">
364 <title>Building from source</title>
366 <indexterm><primary>Building from source</primary></indexterm>
367 <indexterm><primary>Source, building from</primary></indexterm>
369 <para>“I just want to build it!”</para>
371 <para>No problem. This recipe should build and install a working GHC with
372 all the default settings. (unless you're
373 on Windows, in which case go to <xref linkend="winbuild" />).</para>
375 <screen>$ autoreconf<footnote><para>not necessary if you started from a source tarball</para>
379 $ make install</screen>
381 <para>For GHC, this will do a 2-stage bootstrap build of the
382 compiler, with profiling libraries, and install the
383 results in the default location (under <filename>/usr/local</filename> on
384 Unix, for example).</para>
386 <para>The <literal>configure</literal> script is a standard GNU
387 <literal>autoconf</literal> script, and accepts the usual options for
388 changing install locations and the like. Run
389 <literal>./configure --help</literal> for a list of options.</para>
391 <para>If you want to do anything at all non-standard, or you
392 want to do some development, read on...</para>
395 <sect1 id="quick-start">
396 <title>Quick start for GHC developers</title>
398 <para>This section is a copy of the file
399 <literal>HACKING</literal> from the GHC source tree. It describes
400 how to get started with setting up your build tree for developing GHC
401 or its libraries, and how to start building.</para>
408 <sect1 id="sec-working-with-the-build-system">
409 <title>Working with the build system</title>
411 <para>This rest of this guide is intended for duffers like me, who
412 aren't really interested in Makefiles and systems configurations,
413 but who need a mental model of the interlocking pieces so that
414 they can make them work, extend them consistently when adding new
415 software, and lay hands on them gently when they don't
419 <title>History</title>
421 <para>First, a historical note. The GHC build system used to be
422 called "fptools": a generic build system used to build multiple
423 projects (GHC, Happy, GreenCard, H/Direct, etc.). It had a
424 concept of the generic project-independent parts, and
425 project-specific parts that resided in a project
428 <para>Nowadays, most of these other projects are using <ulink
429 url="http://www.haskell.org/cabal/">Cabal</ulink>, or have faded
430 away, and GHC is the only regular user of the fptools build
431 system. We decided therefore to simplify the situation for
432 developers, and specialise the build system for GHC. This
433 resulted in a simpler organisation of the source tree and the
434 build system, which hopefully makes the whole thing easier to
437 <para>You might find old comments that refer to "projects" or
438 "fptools" in the documentation and/or source; please let us know
443 <title>Build trees</title>
444 <indexterm><primary>build trees</primary></indexterm>
445 <indexterm><primary>link trees, for building</primary></indexterm>
447 <para>If you just want to build the software once on a single
448 platform, then your source tree can also be your build tree, and
449 you can skip the rest of this section.</para>
451 <para>We often want to build multiple versions of our software
452 for different architectures, or with different options
453 (e.g. profiling). It's very desirable to share a single copy of
454 the source code among all these builds.</para>
456 <para>So for every source tree we have zero or more
457 <emphasis>build trees</emphasis>. Each build tree is initially
458 an exact copy of the source tree, except that each file is a
459 symbolic link to the source file, rather than being a copy of
460 the source file. There are “standard” Unix
461 utilities that make such copies, so standard that they go by
463 <command>lndir</command><indexterm><primary>lndir</primary></indexterm>,
464 <command>mkshadowdir</command><indexterm><primary>mkshadowdir</primary></indexterm>
465 are two (If you don't have either, the source distribution
466 includes sources for the X11
467 <command>lndir</command>—check out
468 <filename>utils/lndir</filename>). See <xref
469 linkend="sec-storysofar"/> for a typical invocation.</para>
471 <para>The build tree does not need to be anywhere near the
472 source tree in the file system. Indeed, one advantage of
473 separating the build tree from the source is that the build tree
474 can be placed in a non-backed-up partition, saving your systems
475 support people from backing up untold megabytes of
476 easily-regenerated, and rapidly-changing, gubbins. The golden
477 rule is that (with a single exception—<xref
478 linkend="sec-build-config"/>) <emphasis>absolutely everything in
479 the build tree is either a symbolic link to the source tree, or
480 else is mechanically generated</emphasis>. It should be
481 perfectly OK for your build tree to vanish overnight; an hour or
482 two compiling and you're on the road again.</para>
484 <para>You need to be a bit careful, though, that any new files
485 you create (if you do any development work) are in the source
486 tree, not a build tree!</para>
488 <para>Remember, that the source files in the build tree are
489 <emphasis>symbolic links</emphasis> to the files in the source
490 tree. (The build tree soon accumulates lots of built files like
491 <filename>Foo.o</filename>, as well.) You can
492 <emphasis>delete</emphasis> a source file from the build tree
493 without affecting the source tree (though it's an odd thing to
494 do). On the other hand, if you <emphasis>edit</emphasis> a
495 source file from the build tree, you'll edit the source-tree
496 file directly. (You can set up Emacs so that if you edit a
497 source file from the build tree, Emacs will silently create an
498 edited copy of the source file in the build tree, leaving the
499 source file unchanged; but the danger is that you think you've
500 edited the source file whereas actually all you've done is edit
501 the build-tree copy. More commonly you do want to edit the
504 <para>Like the source tree, the top level of your build tree
505 must be (a linked copy of) the root directory of the GHC source
506 tree.. Inside Makefiles, the root of your build tree is called
507 <constant>$(GHC_TOP)</constant><indexterm><primary>GHC_TOP</primary></indexterm>.
508 In the rest of this document path names are relative to
509 <constant>$(GHC_TOP)</constant> unless
510 otherwise stated. For example, the file
511 <filename>mk/target.mk</filename> is actually
512 <filename>$(GHC_TOP)/mk/target.mk</filename>.</para>
515 <sect2 id="sec-build-config">
516 <title>Getting the build you want</title>
518 <para>When you build GHC you will be compiling code on a
519 particular <emphasis>host platform</emphasis>, to run on a
520 particular <emphasis>target platform</emphasis> (usually the
522 platform)<indexterm><primary>platform</primary></indexterm>.
523 The difficulty is that there are minor differences between
524 different platforms; minor, but enough that the code needs to be
525 a bit different for each. There are some big differences too:
526 for a different architecture we need to build GHC with a
527 different native-code generator.</para>
529 <para>There are also knobs you can turn to control how the
530 software is built. For example, you might want to build GHC
531 optimised (so that it runs fast) or unoptimised (so that you can
532 compile it fast after you've modified it. Or, you might want to
533 compile it with debugging on (so that extra consistency-checking
534 code gets included) or off. And so on.</para>
536 <para>All of this stuff is called the
537 <emphasis>configuration</emphasis> of your build. You set the
538 configuration using a three-step process.</para>
542 <term>Step 1: get ready for configuration.</term>
544 <para>NOTE: if you're starting from a source distribution,
545 rather than darcs sources, you can skip this step.</para>
547 <para>Change directory to
548 <constant>$(GHC_TOP)</constant> and
549 issue the command</para>
550 <screen>$ autoreconf</screen>
551 <indexterm><primary>autoreconf</primary></indexterm>
552 <para>(with no arguments). This GNU program (recursively) converts
553 <filename>$(GHC_TOP)/configure.ac</filename> and
554 <filename>$(GHC_TOP)/aclocal.m4</filename>
555 to a shell script called
556 <filename>$(GHC_TOP)/configure</filename>.
557 If <command>autoreconf</command> bleats that it can't write the file <filename>configure</filename>,
558 then delete the latter and try again. Note that you must use <command>autoreconf</command>,
559 and not the old <command>autoconf</command>! If you erroneously use the latter, you'll get
560 a message like "No rule to make target 'mk/config.h.in'".
563 <para>Some parts of the source tree, particularly
564 libraries, have their own configure script.
565 <command>autoreconf</command> takes care of that, too, so all you have
566 to do is calling <command>autoreconf</command> in the top-level directory
567 <filename>$(GHC_TOP)</filename>.</para>
569 <para>These steps are completely platform-independent; they just mean
570 that the human-written files (<filename>configure.ac</filename> and
571 <filename>aclocal.m4</filename>) can be short, although the resulting
572 files (the <command>configure</command> shell scripts and the C header
573 template <filename>mk/config.h.in</filename>) are long.</para>
578 <term>Step 2: system configuration.</term>
580 <para>Runs the newly-created <command>configure</command>
583 <screen>$ ./configure <optional><parameter>args</parameter></optional></screen>
585 <para><command>configure</command>'s mission is to scurry
586 round your computer working out what architecture it has,
587 what operating system, whether it has the
588 <function>vfork</function> system call, where
589 <command>tar</command> is kept, whether
590 <command>gcc</command> is available, where various obscure
591 <literal>#include</literal> files are, whether it's a
592 leap year, and what the systems manager had for lunch. It
593 communicates these snippets of information in two
600 <filename>mk/config.mk.in</filename><indexterm><primary>config.mk.in</primary></indexterm>
602 <filename>mk/config.mk</filename><indexterm><primary>config.mk</primary></indexterm>,
603 substituting for things between
604 “<literal>@</literal>” brackets. So,
605 “<literal>@HaveGcc@</literal>” will be
606 replaced by “<literal>YES</literal>” or
607 “<literal>NO</literal>” depending on what
608 <command>configure</command> finds.
609 <filename>mk/config.mk</filename> is included by every
610 Makefile (directly or indirectly), so the
611 configuration information is thereby communicated to
612 all Makefiles.</para>
617 <filename>mk/config.h.in</filename><indexterm><primary>config.h.in</primary></indexterm>
619 <filename>mk/config.h</filename><indexterm><primary>config.h</primary></indexterm>.
620 The latter is <literal>#include</literal>d by
621 various C programs, which can thereby make use of
622 configuration information.</para>
626 <para><command>configure</command> takes some optional
627 arguments. Use <literal>./configure --help</literal> to
628 get a list of the available arguments. Here are some of
629 the ones you might need:</para>
633 <term><literal>--with-ghc=<parameter>path</parameter></literal>
634 <indexterm><primary><literal>--with-ghc</literal></primary></indexterm>
637 <para>Specifies the path to an installed GHC which
638 you would like to use. This compiler will be used
639 for compiling GHC-specific code (eg. GHC itself).
640 This option <emphasis>cannot</emphasis> be specified
641 using <filename>build.mk</filename> (see later),
642 because <command>configure</command> needs to
643 auto-detect the version of GHC you're using. The
644 default is to look for a compiler named
645 <literal>ghc</literal> in your path.</para>
650 <term><literal>--with-hc=<parameter>path</parameter></literal>
651 <indexterm><primary><literal>--with-hc</literal></primary></indexterm>
654 <para>Specifies the path to any installed Haskell
655 compiler. This compiler will be used for compiling
656 generic Haskell code. The default is to use
657 <literal>ghc</literal>. (NOTE: I'm not sure it
658 actually works to specify a compiler other than GHC
659 here; unless you really know what you're doing I
660 suggest not using this option at all.)</para>
665 <term><literal>--with-gcc=<parameter>path</parameter></literal>
666 <indexterm><primary><literal>--with-gcc</literal></primary></indexterm>
669 <para>Specifies the path to the installed GCC. This
670 compiler will be used to compile all C files,
671 <emphasis>except</emphasis> any generated by the
672 installed Haskell compiler, which will have its own
673 idea of which C compiler (if any) to use. The
674 default is to use <literal>gcc</literal>.</para>
682 <term>Step 3: build configuration.</term>
684 <para>Next, you say how this build of
685 GHC is to differ from the standard
686 defaults by creating a new file
687 <filename>mk/build.mk</filename><indexterm><primary>build.mk</primary></indexterm>
688 <emphasis>in the build tree</emphasis>. This file is the
689 one and only file you edit in the build tree, precisely
690 because it says how this build differs from the source.
691 (Just in case your build tree does die, you might want to
692 keep a private directory of <filename>build.mk</filename>
693 files, and use a symbolic link in each build tree to point
694 to the appropriate one.) So
695 <filename>mk/build.mk</filename> never exists in the
696 source tree—you create one in each build tree from
697 the template. We'll discuss what to put in it
703 <para>And that's it for configuration. Simple, eh?</para>
705 <para>What do you put in your build-specific configuration file
706 <filename>mk/build.mk</filename>? <emphasis>For almost all
707 purposes all you will do is put make variable definitions that
708 override those in</emphasis>
709 <filename>mk/config.mk.in</filename>. The whole point of
710 <filename>mk/config.mk.in</filename>—and its derived
711 counterpart <filename>mk/config.mk</filename>—is to define
712 the build configuration. It is heavily commented, as you will
713 see if you look at it. So generally, what you do is look at
714 <filename>mk/config.mk.in</filename>, and add definitions in
715 <filename>mk/build.mk</filename> that override any of the
716 <filename>config.mk</filename> definitions that you want to
717 change. (The override occurs because the main boilerplate file,
718 <filename>mk/boilerplate.mk</filename><indexterm><primary>boilerplate.mk</primary></indexterm>,
719 includes <filename>build.mk</filename> after
720 <filename>config.mk</filename>.)</para>
722 <para>For your convenience, there's a file called
723 <filename>build.mk.sample</filename> that can serve as a starting
724 point for your <filename>build.mk</filename>.</para>
726 <para>For example, <filename>config.mk.in</filename> contains
727 the definition:</para>
729 <programlisting>GhcHcOpts=-Rghc-timing</programlisting>
731 <para>The accompanying comment explains that this is the list of
732 flags passed to GHC when building GHC itself. For doing
733 development, it is wise to add <literal>-DDEBUG</literal>, to
734 enable debugging code. So you would add the following to
735 <filename>build.mk</filename>:</para>
737 <programlisting>GhcHcOpts += -DDEBUG</programlisting>
739 <para>GNU <command>make</command> allows existing definitions to
740 have new text appended using the “<literal>+=</literal>”
741 operator, which is quite a convenient feature.</para>
743 <para>Haskell compilations by default have <literal>-O</literal>
744 turned on, by virtue of this setting from
745 <filename>config.mk</filename>:</para>
747 <programlisting>SRC_HC_OPTS += -H16m -O</programlisting>
749 <para><literal>SRC_HC_OPTS</literal> means "options for HC from
750 the source tree", where HC stands for Haskell Compiler.
751 <literal>SRC_HC_OPTS</literal> are added to every Haskell
752 compilation. To turn off optimisation, you could add this to
753 <filename>build.mk</filename>:</para>
755 <programlisting>SRC_HC_OPTS = -H16m -O0</programlisting>
757 <para>Or you could just add <literal>-O0</literal> to
758 <literal>GhcHcOpts</literal> to turn off optimisation for the
759 compiler. See <xref linkend="quick-start" /> for some more
762 <para>When reading <filename>config.mk.in</filename>, remember
763 that anything between “@...@” signs is going to be substituted
764 by <command>configure</command> later. You
765 <emphasis>can</emphasis> override the resulting definition if
766 you want, but you need to be a bit surer what you are doing.
767 For example, there's a line that says:</para>
769 <programlisting>TAR = @TarCmd@</programlisting>
771 <para>This defines the Make variables <constant>TAR</constant>
772 to the pathname for a <command>tar</command> that
773 <command>configure</command> finds somewhere. If you have your
774 own pet <command>tar</command> you want to use instead, that's
775 fine. Just add this line to <filename>mk/build.mk</filename>:</para>
777 <programlisting>TAR = mytar</programlisting>
779 <para>You do not <emphasis>have</emphasis> to have a
780 <filename>mk/build.mk</filename> file at all; if you don't,
781 you'll get all the default settings from
782 <filename>mk/config.mk.in</filename>.</para>
784 <para>You can also use <filename>build.mk</filename> to override
785 anything that <command>configure</command> got wrong. One place
786 where this happens often is with the definition of
787 <constant>GHC_TOP_ABS</constant>: this
788 variable is supposed to be the canonical path to the top of your
789 source tree, but if your system uses an automounter then the
790 correct directory is hard to find automatically. If you find
791 that <command>configure</command> has got it wrong, just put the
792 correct definition in <filename>build.mk</filename>.</para>
795 <sect2 id="sec-storysofar">
796 <title>The story so far</title>
798 <para>Let's summarise the steps you need to carry to get
799 yourself a fully-configured build tree from scratch.</para>
803 <para> Get your source tree from somewhere (darcs repository
804 or source distribution). Say you call the root directory
805 <filename>myghc</filename> (it does not have to be
806 called <filename>ghc</filename>).</para>
810 <para>(Optional) Use <command>lndir</command> or
811 <command>mkshadowdir</command> to create a build tree.</para>
814 $ mkshadowdir . /scratch/joe-bloggs/myghc-x86</screen>
816 <para>(N.B. <command>mkshadowdir</command>'s first argument
817 is taken relative to its second.) You probably want to give
818 the build tree a name that suggests its main defining
819 characteristic (in your mind at least), in case you later
824 <para>Change directory to the build tree. Everything is
825 going to happen there now.</para>
827 <screen>$ cd /scratch/joe-bloggs/myghc-x86</screen>
832 <para>Prepare for system configuration:</para>
834 <screen>$ autoreconf</screen>
836 <para>(You can skip this step if you are starting from a
837 source distribution, and you already have
838 <filename>configure</filename> and
839 <filename>mk/config.h.in</filename>.)</para>
843 <para>Do system configuration:</para>
845 <screen>$ ./configure</screen>
847 <para>Don't forget to check whether you need to add any
848 arguments to <literal>configure</literal>; for example, a
849 common requirement is to specify which GHC to use with
850 <option>--with-ghc=<replaceable>ghc</replaceable></option>.</para>
854 <para>Create the file <filename>mk/build.mk</filename>,
855 adding definitions for your desired configuration
860 <para>You can make subsequent changes to
861 <filename>mk/build.mk</filename> as often as you like. You do
862 not have to run any further configuration programs to make these
863 changes take effect. In theory you should, however, say
864 <command>make clean; make</command>, because configuration
865 option changes could affect anything—but in practice you
866 are likely to know what's affected.</para>
870 <title>Making things</title>
872 <para>At this point you have made yourself a fully-configured
873 build tree, so you are ready to start building real
876 <para>The first thing you need to know is that <emphasis>you
877 must use GNU <command>make</command></emphasis>. On some
878 systems (eg. FreeBSD) this is called <command>gmake</command>,
879 whereas on others it is the standard <command>make</command>
880 command. In this document we will always refer to it as
881 <command>make</command>; please substitute with
882 <command>gmake</command> if your system requires it. If you use
883 a the wrong <command>make</command> you will get all sorts of
884 error messages (but no damage) because the GHC
885 <command>Makefiles</command> use GNU <command>make</command>'s
886 facilities extensively.</para>
888 <para>To just build the whole thing, <command>cd</command> to
889 the top of your build tree and type <command>make</command>.
890 This will prepare the tree and build the various parts in the
891 correct order, resulting in a complete build of GHC that can
892 even be used directly from the tree, without being installed
896 <sect2 id="sec-bootstrapping">
897 <title>Bootstrapping GHC</title>
899 <para>GHC requires a 2-stage bootstrap in order to provide
900 full functionality, including GHCi. By a 2-stage bootstrap, we
901 mean that the compiler is built once using the installed GHC,
902 and then again using the compiler built in the first stage. You
903 can also build a stage 3 compiler, but this normally isn't
904 necessary except to verify that the stage 2 compiler is working
907 <para>Note that when doing a bootstrap, the stage 1 compiler
908 must be built, followed by the runtime system and libraries, and
909 then the stage 2 compiler. The correct ordering is implemented
910 by the top-level <filename>Makefile</filename>, so if you want
911 everything to work automatically it's best to start
912 <command>make</command> from the top of the tree. The top-level
913 <filename>Makefile</filename> is set up to do a 2-stage
914 bootstrap by default (when you say <command>make</command>).
915 Some other targets it supports are:</para>
921 <para>Build everything as normal, including the stage 1
929 <para>Build the stage 2 compiler only.</para>
936 <para>Build the stage 3 compiler only.</para>
941 <term>bootstrap</term> <term>bootstrap2</term>
943 <para>Build stage 1 followed by stage 2.</para>
948 <term>bootstrap3</term>
950 <para>Build stages 1, 2 and 3.</para>
957 <para>Install everything, including the compiler built in
958 stage 2. To override the stage, say <literal>make install
959 stage=<replaceable>n</replaceable></literal> where
960 <replaceable>n</replaceable> is the stage to install.</para>
965 <term><literal>binary-dist</literal></term>
967 <para>make a binary distribution. This is the target we
968 use to build the binary distributions of GHC.</para>
973 <term><literal>dist</literal></term>
975 <para>make a source distribution. Note that this target
976 does “make distclean” as part of its work;
977 don't use it if you want to keep what you've built.</para>
982 <para>The top-level <filename>Makefile</filename> also arranges
983 to do the appropriate <literal>make boot</literal> steps (see
984 below) before actually building anything.</para>
986 <para>The <literal>stage1</literal>, <literal>stage2</literal>
987 and <literal>stage3</literal> targets also work in the
988 <literal>compiler</literal> directory, but don't forget that
989 each stage requires its own <literal>make boot</literal> step:
990 for example, you must do</para>
992 <screen>$ make boot stage=2</screen>
994 <para>before <literal>make stage2</literal> in
995 <literal>compiler</literal>.</para>
998 <sect2 id="sec-standard-targets">
999 <title>Standard Targets</title>
1000 <indexterm><primary>targets, standard makefile</primary></indexterm>
1001 <indexterm><primary>makefile targets</primary></indexterm>
1003 <para>In any directory you should be able to make the following:</para>
1007 <term><literal>boot</literal></term>
1009 <para>does the one-off preparation required to get ready
1010 for the real work. Notably, it does <command>make
1011 depend</command> in all directories that contain programs.
1012 It also builds the necessary tools for compilation to
1015 <para>Invoking the <literal>boot</literal> target
1016 explicitly is not normally necessary. From the top-level
1017 directory, invoking <literal>make</literal> causes
1018 <literal>make boot</literal> to be invoked in various
1019 subdirectories first, in the right order. Unless you
1020 really know what you are doing, it is best to always say
1021 <literal>make</literal> from the top level first.</para>
1023 <para>If you're working in a subdirectory somewhere and
1024 need to update the dependencies, <literal>make
1025 boot</literal> is a good way to do it.</para>
1030 <term><literal>all</literal></term>
1032 <para>makes all the final target(s) for this Makefile.
1033 Depending on which directory you are in a “final
1034 target” may be an executable program, a library
1035 archive, a shell script, or a Postscript file. Typing
1036 <command>make</command> alone is generally the same as
1037 typing <command>make all</command>.</para>
1042 <term><literal>install</literal></term>
1044 <para>installs the things built by <literal>all</literal>
1045 (except for the documentation). Where does it install
1046 them? That is specified by
1047 <filename>mk/config.mk.in</filename>; you can override it
1048 in <filename>mk/build.mk</filename>, or by running
1049 <command>configure</command> with command-line arguments
1050 like <literal>--bindir=/home/simonpj/bin</literal>; see
1051 <literal>./configure --help</literal> for the full
1057 <term><literal>install-docs</literal></term>
1059 <para>installs the documentation. Otherwise behaves just
1060 like <literal>install</literal>.</para>
1065 <term><literal>uninstall</literal></term>
1067 <para>reverses the effect of
1068 <literal>install</literal> (WARNING: probably doesn't work).</para>
1073 <term><literal>clean</literal></term>
1075 <para>Delete all files from the current directory that are
1076 normally created by building the program. Don't delete
1077 the files that record the configuration, or files
1078 generated by <command>make boot</command>. Also preserve
1079 files that could be made by building, but normally aren't
1080 because the distribution comes with them.</para>
1085 <term><literal>distclean</literal></term>
1087 <para>Delete all files from the current directory that are
1088 created by configuring or building the program. If you
1089 have unpacked the source and built the program without
1090 creating any other files, <literal>make
1091 distclean</literal> should leave only the files that were
1092 in the distribution.</para>
1097 <term><literal>mostlyclean</literal></term>
1099 <para>Like <literal>clean</literal>, but may refrain from
1100 deleting a few files that people normally don't want to
1106 <term><literal>maintainer-clean</literal></term>
1108 <para>Delete everything from the current directory that
1109 can be reconstructed with this Makefile. This typically
1110 includes everything deleted by
1111 <literal>distclean</literal>, plus more: C source files
1112 produced by Bison, tags tables, Info files, and so
1115 <para>One exception, however: <literal>make
1116 maintainer-clean</literal> should not delete
1117 <filename>configure</filename> even if
1118 <filename>configure</filename> can be remade using a rule
1119 in the <filename>Makefile</filename>. More generally,
1120 <literal>make maintainer-clean</literal> should not delete
1121 anything that needs to exist in order to run
1122 <filename>configure</filename> and then begin to build the
1125 <para>After a <literal>maintainer-clean</literal>, a
1126 <literal>configure</literal> will be necessary before
1127 building again.</para>
1132 <para>All of these standard targets automatically recurse into
1133 sub-directories. Certain other standard targets do not:</para>
1137 <term><literal>depend</literal></term>
1139 <para>make a <filename>.depend</filename> file in each
1140 directory that needs it. This <filename>.depend</filename>
1141 file contains mechanically-generated dependency
1142 information; for example, suppose a directory contains a
1143 Haskell source module <filename>Foo.lhs</filename> which
1144 imports another module <literal>Baz</literal>. Then the
1145 generated <filename>.depend</filename> file will contain
1146 the dependency:</para>
1148 <programlisting>Foo.o : Baz.hi</programlisting>
1150 <para>which says that the object file
1151 <filename>Foo.o</filename> depends on the interface file
1152 <filename>Baz.hi</filename> generated by compiling module
1153 <literal>Baz</literal>. The <filename>.depend</filename>
1154 file is automatically included by every Makefile.</para>
1159 <para>Some <filename>Makefile</filename>s have targets other
1160 than these. You can discover them by looking in the
1161 <filename>Makefile</filename> itself.</para>
1165 <title>Using GHC from the build tree</title>
1167 <para>If you want to build GHC and just use it direct from the
1168 build tree without doing <literal>make install</literal> first,
1169 you can run the in-place driver script. To run the stage 1
1170 compiler, use <filename>compiler/stage1/ghc-inplace</filename>,
1171 stage 2 is <filename>compiler/stage2/ghc-inplace</filename>, and
1174 <para> Do <emphasis>NOT</emphasis> use
1175 <filename>compiler/stage1/ghc</filename>, or
1176 <filename>compiler/stage1/ghc-6.xx</filename>, as these are the
1177 scripts intended for installation, and contain hard-wired paths
1178 to the installed libraries, rather than the libraries in the
1183 <title>Fast Making</title>
1185 <indexterm><primary>fastmake</primary></indexterm>
1186 <indexterm><primary>dependencies, omitting</primary></indexterm>
1187 <indexterm><primary>FAST, makefile variable</primary></indexterm>
1189 <para>Sometimes the dependencies get in the way: if you've made
1190 a small change to one file, and you're absolutely sure that it
1191 won't affect anything else, but you know that
1192 <command>make</command> is going to rebuild everything anyway,
1193 the following hack may be useful:</para>
1195 <screen>$ make FAST=YES</screen>
1197 <para>This tells the make system to ignore dependencies and just
1198 build what you tell it to. In other words, it's equivalent to
1199 temporarily removing the <filename>.depend</filename> file in
1200 the current directory (where <command>mkdependHS</command> and
1201 friends store their dependency information).</para>
1203 <para>A bit of history: GHC used to come with a
1204 <command>fastmake</command> script that did the above job, but
1205 GNU make provides the features we need to do it without
1206 resorting to a script. Also, we've found that fastmaking is
1207 less useful since the advent of GHC's recompilation checker (see
1208 the User's Guide section on "Separate Compilation").</para>
1212 <sect1 id="sec-makefile-arch">
1213 <title>The <filename>Makefile</filename> architecture</title>
1214 <indexterm><primary>makefile architecture</primary></indexterm>
1216 <para><command>make</command> is great if everything
1217 works—you type <command>make install</command> and lo! the
1218 right things get compiled and installed in the right places. Our
1219 goal is to make this happen often, but somehow it often doesn't;
1220 instead some weird error message eventually emerges from the
1221 bowels of a directory you didn't know existed.</para>
1223 <para>The purpose of this section is to give you a road-map to
1224 help you figure out what is going right and what is going
1228 <title>Debugging</title>
1230 <para>Debugging <filename>Makefile</filename>s is something of a
1231 black art, but here's a couple of tricks that we find
1232 particularly useful. The following command allows you to see
1233 the contents of any make variable in the context of the current
1234 <filename>Makefile</filename>:</para>
1236 <screen>$ make show VALUE=HS_SRCS</screen>
1238 <para>where you can replace <literal>HS_SRCS</literal> with the
1239 name of any variable you wish to see the value of.</para>
1241 <para>GNU make has a <option>-d</option> option which generates
1242 a dump of the decision procedure used to arrive at a conclusion
1243 about which files should be recompiled. Sometimes useful for
1244 tracking down problems with superfluous or missing
1245 recompilations.</para>
1249 <title>A small example</title>
1251 <para>To get started, let us look at the
1252 <filename>Makefile</filename> for an imaginary small program,
1253 <literal>small</literal>. Each program or library in the GHC
1254 source tree typically has its own directory, in this case we'll
1255 use <filename>$(GHC_TOP)/small</filename>.
1256 Inside the <filename>small/</filename> directory there will be a
1257 <filename>Makefile</filename>, looking something like
1260 <indexterm><primary>Makefile, minimal</primary></indexterm>
1262 <programlisting># Makefile for program "small"
1264 include $(TOP)/mk/boilerplate.mk
1268 include $(TOP)/target.mk</programlisting>
1270 <para>this <filename>Makefile</filename> has three
1275 <para>The first section includes
1278 One of the most important
1279 features of GNU <command>make</command> that we use is the ability for a <filename>Makefile</filename> to
1280 include another named file, very like <command>cpp</command>'s <literal>#include</literal>
1285 a file of “boilerplate” code from the top level
1286 <indexterm><primary>boilerplate.mk</primary></indexterm>).
1287 As its name suggests, <filename>boilerplate.mk</filename>
1288 consists of a large quantity of standard
1289 <filename>Makefile</filename> code. We discuss this
1290 boilerplate in more detail in <xref linkend="sec-boiler"/>.
1291 <indexterm><primary>include, directive in
1292 Makefiles</primary></indexterm> <indexterm><primary>Makefile
1293 inclusion</primary></indexterm></para>
1295 <para>Before the <literal>include</literal> statement, you
1296 must define the <command>make</command> variable
1297 <constant>TOP</constant><indexterm><primary>TOP</primary></indexterm>
1298 to be the top-level directory of the source tree, containing
1299 the <filename>mk</filename>
1300 directory in which the <filename>boilerplate.mk</filename>
1301 file is. It is <emphasis>not</emphasis> OK to simply say</para>
1303 <programlisting>include ../mk/boilerplate.mk # NO NO NO</programlisting>
1305 <para>Why? Because the <filename>boilerplate.mk</filename>
1306 file needs to know where it is, so that it can, in turn,
1307 <literal>include</literal> other files. (Unfortunately,
1308 when an <literal>include</literal>d file does an
1309 <literal>include</literal>, the filename is treated relative
1310 to the directory in which <command>make</command> is being
1311 run, not the directory in which the
1312 <literal>include</literal>d sits.) In general,
1313 <emphasis>every file <filename>foo.mk</filename> assumes
1315 <filename>$(TOP)/mk/foo.mk</filename>
1316 refers to itself.</emphasis> It is up to the
1317 <filename>Makefile</filename> doing the
1318 <literal>include</literal> to ensure this is the case.</para>
1322 <para> The second section defines the standard
1323 <command>make</command> variable
1324 <constant>HS_PROG</constant><indexterm><primary>HS_PROG</primary></indexterm>
1325 (the executable binary to be built). We will discuss in
1326 more detail what the “standard variables” are,
1327 and how they affect what happens, in <xref
1328 linkend="sec-targets"/>.</para>
1332 <para>The last section includes a second file of standard
1334 <filename>target.mk</filename><indexterm><primary>target.mk</primary></indexterm>.
1335 It contains the rules that tell <command>make</command> how
1336 to make the standard targets (<xref
1337 linkend="sec-standard-targets"/>). Why, you ask, can't this
1338 standard code be part of
1339 <filename>boilerplate.mk</filename>? Good question. We
1340 discuss the reason later, in <xref
1341 linkend="sec-boiler-arch"/>.</para>
1343 <para>You do not <emphasis>have</emphasis> to
1344 <literal>include</literal> the
1345 <filename>target.mk</filename> file. Instead, you can write
1346 rules of your own for all the standard targets. Usually,
1347 though, you will find quite a big payoff from using the
1348 canned rules in <filename>target.mk</filename>; the price
1349 tag is that you have to understand what canned rules get
1350 enabled, and what they do (<xref
1351 linkend="sec-targets"/>).</para>
1355 <para>In our example <filename>Makefile</filename>, most of the
1356 work is done by the two <literal>include</literal>d files. When
1357 you say <command>make all</command>, the following things
1362 <para><command>make</command> looks in the current directory
1363 to see what source files it can find
1364 (eg. <filename>Foo.hs</filename>,
1365 <filename>Baz.c</filename>), and from that it figures out
1366 what object files need to be built
1367 (eg. <filename>Foo.o</filename>,
1368 <filename>Baz.o</filename>). Because source files are found
1369 and used automatically, omitting them from a program or
1370 library has to be done manually (see
1371 <literal>EXCLUDED_SRCS</literal> in <xref
1372 linkend="sec-boiler" />).</para>
1376 <para>It uses a boilerplate pattern rule to compile
1377 <filename>Foo.hs</filename> to <filename>Foo.o</filename>
1378 using a Haskell compiler. (Which one? That is set in the
1379 build configuration.)</para>
1383 <para>It uses another standard pattern rule to compile
1384 <filename>Baz.c</filename> to <filename>Baz.o</filename>,
1385 using a C compiler. (Ditto.)</para>
1389 <para>It links the resulting <filename>.o</filename> files
1390 together to make <literal>small</literal>, using the Haskell
1391 compiler to do the link step. (Why not use
1392 <command>ld</command>? Because the Haskell compiler knows
1393 what standard libraries to link in. How did
1394 <command>make</command> know to use the Haskell compiler to
1395 do the link, rather than the C compiler? Because we set the
1396 variable <constant>HS_PROG</constant> rather than
1397 <constant>C_PROG</constant>.)</para>
1401 <para>All <filename>Makefile</filename>s should follow the above
1402 three-section format.</para>
1405 <sect2 id="sec-boiler-arch">
1406 <title>Boilerplate architecture</title>
1407 <indexterm><primary>boilerplate architecture</primary></indexterm>
1409 <para>Every <filename>Makefile</filename> includes a
1410 <filename>boilerplate.mk</filename><indexterm><primary>boilerplate.mk</primary></indexterm>
1411 file at the top, and
1412 <filename>target.mk</filename><indexterm><primary>target.mk</primary></indexterm>
1413 file at the bottom. In this section we discuss what is in these
1414 files, and why there have to be two of them. In general:</para>
1418 <para><filename>boilerplate.mk</filename> consists of:</para>
1422 <para><emphasis>Definitions of millions of
1423 <command>make</command> variables</emphasis> that
1424 collectively specify the build configuration. Examples:
1425 <constant>HC_OPTS</constant><indexterm><primary>HC_OPTS</primary></indexterm>,
1426 the options to feed to the Haskell compiler;
1427 <constant>NoFibSubDirs</constant><indexterm><primary>NoFibSubDirs</primary></indexterm>,
1428 the sub-directories to enable within the
1429 <literal>nofib</literal> project;
1430 <constant>GhcWithHc</constant><indexterm><primary>GhcWithHc</primary></indexterm>,
1431 the name of the Haskell compiler to use when compiling
1432 GHC in the <literal>ghc</literal> project.</para>
1436 <para><emphasis>Standard pattern rules</emphasis> that
1437 tell <command>make</command> how to construct one file
1438 from another.</para>
1442 <para><filename>boilerplate.mk</filename> needs to be
1443 <literal>include</literal>d at the <emphasis>top</emphasis>
1444 of each <filename>Makefile</filename>, so that the user can
1445 replace the boilerplate definitions or pattern rules by
1446 simply giving a new definition or pattern rule in the
1447 <filename>Makefile</filename>. <command>make</command>
1448 simply takes the last definition as the definitive one.</para>
1450 <para>Instead of <emphasis>replacing</emphasis> boilerplate
1451 definitions, it is also quite common to
1452 <emphasis>augment</emphasis> them. For example, a
1453 <filename>Makefile</filename> might say:</para>
1455 <programlisting>SRC_HC_OPTS += -O</programlisting>
1457 <para>thereby adding “<option>-O</option>” to
1459 <constant>SRC_HC_OPTS</constant><indexterm><primary>SRC_HC_OPTS</primary></indexterm>.</para>
1463 <para><filename>target.mk</filename> contains
1464 <command>make</command> rules for the standard targets
1465 described in <xref linkend="sec-standard-targets"/>. These
1466 rules are selectively included, depending on the setting of
1467 certain <command>make</command> variables. These variables
1468 are usually set in the middle section of the
1469 <filename>Makefile</filename> between the two
1470 <literal>include</literal>s.</para>
1472 <para><filename>target.mk</filename> must be included at the
1473 end (rather than being part of
1474 <filename>boilerplate.mk</filename>) for several tiresome
1480 <para><command>make</command> commits target and
1481 dependency lists earlier than it should. For example,
1482 <filename>target.mk</filename> has a rule that looks
1485 <programlisting>$(HS_PROG) : $(OBJS)
1486 $(HC) $(LD_OPTS) $< -o $@</programlisting>
1488 <para>If this rule was in
1489 <filename>boilerplate.mk</filename> then
1490 <constant>$(HS_PROG)</constant><indexterm><primary>HS_PROG</primary></indexterm>
1492 <constant>$(OBJS)</constant><indexterm><primary>OBJS</primary></indexterm>
1493 would not have their final values at the moment
1494 <command>make</command> encountered the rule. Alas,
1495 <command>make</command> takes a snapshot of their
1496 current values, and wires that snapshot into the rule.
1497 (In contrast, the commands executed when the rule
1498 “fires” are only substituted at the moment
1499 of firing.) So, the rule must follow the definitions
1500 given in the <filename>Makefile</filename> itself.</para>
1504 <para>Unlike pattern rules, ordinary rules cannot be
1505 overriden or replaced by subsequent rules for the same
1506 target (at least, not without an error message).
1507 Including ordinary rules in
1508 <filename>boilerplate.mk</filename> would prevent the
1509 user from writing rules for specific targets in specific
1514 <para>There are a couple of other reasons I've
1515 forgotten, but it doesn't matter too much.</para>
1522 <sect2 id="sec-boiler">
1523 <title>The <filename>mk/boilerplate.mk</filename> file</title>
1524 <indexterm><primary>boilerplate.mk</primary></indexterm>
1526 <para>If you look at
1527 <filename>$(GHC_TOP)/mk/boilerplate.mk</filename>
1528 you will find that it consists of the following sections, each
1529 held in a separate file:</para>
1533 <term><filename>config.mk</filename>
1534 <indexterm><primary>config.mk</primary></indexterm>
1537 <para>is the build configuration file we discussed at
1538 length in <xref linkend="sec-build-config"/>.</para>
1543 <term><filename>paths.mk</filename>
1544 <indexterm><primary>paths.mk</primary></indexterm>
1547 <para>defines <command>make</command> variables for
1548 pathnames and file lists. This file contains code for
1549 automatically compiling lists of source files and deriving
1550 lists of object files from those. The results can be
1551 overriden in the <filename>Makefile</filename>, but in
1552 most cases the automatic setup should do the right
1555 <para>The following variables may be set in the
1556 <filename>Makefile</filename> to affect how the automatic
1557 source file search is done:</para>
1561 <term><literal>ALL_DIRS</literal>
1562 <indexterm><primary><literal>ALL_DIRS</literal></primary></indexterm>
1565 <para>Set to a list of directories to search in
1566 addition to the current directory for source
1572 <term><literal>EXCLUDED_SRCS</literal>
1573 <indexterm><primary><literal>EXCLUDED_SRCS</literal></primary></indexterm>
1576 <para>Set to a list of source files (relative to the
1577 current directory) to omit from the automatic
1578 search. The source searching machinery is clever
1579 enough to know that if you exclude a source file
1580 from which other sources are derived, then the
1581 derived sources should also be excluded. For
1582 example, if you set <literal>EXCLUDED_SRCS</literal>
1583 to include <filename>Foo.y</filename>, then
1584 <filename>Foo.hs</filename> will also be
1590 <term><literal>EXTRA_SRCS</literal>
1591 <indexterm><primary><literal>EXTRA_SRCS</literal></primary></indexterm>
1594 <para>Set to a list of extra source files (perhaps
1595 in directories not listed in
1596 <literal>ALL_DIRS</literal>) that should be
1602 <para>The results of the automatic source file search are
1603 placed in the following make variables:</para>
1607 <term><literal>SRCS</literal>
1608 <indexterm><primary><literal>SRCS</literal></primary></indexterm>
1611 <para>All source files found, sorted and without
1612 duplicates, including those which might not exist
1613 yet but will be derived from other existing sources.
1614 <literal>SRCS</literal> <emphasis>can</emphasis> be
1615 overriden if necessary, in which case the variables
1616 below will follow suit.</para>
1621 <term><literal>HS_SRCS</literal>
1622 <indexterm><primary><literal>HS_SRCS</literal></primary></indexterm>
1625 <para>all Haskell source files in the current
1626 directory, including those derived from other source
1627 files (eg. Happy sources also give rise to Haskell
1633 <term><literal>HS_OBJS</literal>
1634 <indexterm><primary><literal>HS_OBJS</literal></primary></indexterm>
1637 <para>Object files derived from
1638 <literal>HS_SRCS</literal>.</para>
1643 <term><literal>HS_IFACES</literal>
1644 <indexterm><primary><literal>HS_IFACES</literal></primary></indexterm>
1647 <para>Interface files (<literal>.hi</literal> files)
1648 derived from <literal>HS_SRCS</literal>.</para>
1653 <term><literal>C_SRCS</literal>
1654 <indexterm><primary><literal>C_SRCS</literal></primary></indexterm>
1657 <para>All C source files found.</para>
1662 <term><literal>C_OBJS</literal>
1663 <indexterm><primary><literal>C_OBJS</literal></primary></indexterm>
1666 <para>Object files derived from
1667 <literal>C_SRCS</literal>.</para>
1672 <term><literal>SCRIPT_SRCS</literal>
1673 <indexterm><primary><literal>SCRIPT_SRCS</literal></primary></indexterm>
1676 <para>All script source files found
1677 (<literal>.lprl</literal> files).</para>
1682 <term><literal>SCRIPT_OBJS</literal>
1683 <indexterm><primary><literal>SCRIPT_OBJS</literal></primary></indexterm>
1686 <para><quote>object</quote> files derived from
1687 <literal>SCRIPT_SRCS</literal>
1688 (<literal>.prl</literal> files).</para>
1693 <term><literal>HSC_SRCS</literal>
1694 <indexterm><primary><literal>HSC_SRCS</literal></primary></indexterm>
1697 <para>All <literal>hsc2hs</literal> source files
1698 (<literal>.hsc</literal> files).</para>
1703 <term><literal>HAPPY_SRCS</literal>
1704 <indexterm><primary><literal>HAPPY_SRCS</literal></primary></indexterm>
1707 <para>All <literal>happy</literal> source files
1708 (<literal>.y</literal> or <literal>.hy</literal> files).</para>
1713 <term><literal>OBJS</literal>
1714 <indexterm><primary>OBJS</primary></indexterm>
1717 <para>the concatenation of
1718 <literal>$(HS_OBJS)</literal>,
1719 <literal>$(C_OBJS)</literal>, and
1720 <literal>$(SCRIPT_OBJS)</literal>.</para>
1725 <para>Any or all of these definitions can easily be
1726 overriden by giving new definitions in your
1727 <filename>Makefile</filename>.</para>
1729 <para>What, exactly, does <filename>paths.mk</filename>
1730 consider a <quote>source file</quote> to be? It's based
1731 on the file's suffix (e.g. <filename>.hs</filename>,
1732 <filename>.lhs</filename>, <filename>.c</filename>,
1733 <filename>.hy</filename>, etc), but this is the kind of
1734 detail that changes, so rather than enumerate the source
1735 suffices here the best thing to do is to look in
1736 <filename>paths.mk</filename>.</para>
1741 <term><filename>opts.mk</filename>
1742 <indexterm><primary>opts.mk</primary></indexterm>
1745 <para>defines <command>make</command> variables for option
1746 strings to pass to each program. For example, it defines
1747 <constant>HC_OPTS</constant><indexterm><primary>HC_OPTS</primary></indexterm>,
1748 the option strings to pass to the Haskell compiler. See
1749 <xref linkend="sec-suffix"/>.</para>
1754 <term><filename>suffix.mk</filename>
1755 <indexterm><primary>suffix.mk</primary></indexterm>
1758 <para>defines standard pattern rules—see <xref
1759 linkend="sec-suffix"/>.</para>
1764 <para>Any of the variables and pattern rules defined by the
1765 boilerplate file can easily be overridden in any particular
1766 <filename>Makefile</filename>, because the boilerplate
1767 <literal>include</literal> comes first. Definitions after this
1768 <literal>include</literal> directive simply override the default
1769 ones in <filename>boilerplate.mk</filename>.</para>
1772 <sect2 id="sec-platforms">
1773 <title>Platform settings</title>
1774 <indexterm><primary>Platform settings</primary>
1777 <para>There are three platforms of interest when building GHC:</para>
1781 <term>The <emphasis>build</emphasis> platform</term>
1783 <para>The platform on which we are doing this build.</para>
1788 <term>The <emphasis>host</emphasis> platform</term>
1790 <para>The platform on which these binaries will run.</para>
1795 <term>The <emphasis>target</emphasis> platform</term>
1797 <para>The platform for which this compiler will generate code.</para>
1802 <para>These platforms are set when running the
1803 <literal>configure</literal> script, using the
1804 <option>--build</option>, <option>--host</option>, and
1805 <option>--target</option> options. The <filename>mk/config.mk</filename>
1806 file defines several symbols related to the platform settings (see
1807 <filename>mk/config.mk</filename> for details).</para>
1809 <para>We don't currently support build & host being different, because
1810 the build process creates binaries that are both run during the build,
1811 and also installed.</para>
1813 <para>If host and target are different, then we are building a
1814 cross-compiler. For GHC, this means a compiler
1815 which will generate intermediate .hc files to port to the target
1816 architecture for bootstrapping. The libraries and stage 2 compiler
1817 will be built as HC files for the target system (see <xref
1818 linkend="sec-porting-ghc" /> for details.</para>
1820 <para>More details on when to use BUILD, HOST or TARGET can be found in
1821 the comments in <filename>config.mk</filename>.</para>
1824 <sect2 id="sec-suffix">
1825 <title>Pattern rules and options</title>
1826 <indexterm><primary>Pattern rules</primary></indexterm>
1829 <filename>suffix.mk</filename><indexterm><primary>suffix.mk</primary></indexterm>
1830 defines standard <emphasis>pattern rules</emphasis> that say how
1831 to build one kind of file from another, for example, how to
1832 build a <filename>.o</filename> file from a
1833 <filename>.c</filename> file. (GNU <command>make</command>'s
1834 <emphasis>pattern rules</emphasis> are more powerful and easier
1835 to use than Unix <command>make</command>'s <emphasis>suffix
1836 rules</emphasis>.)</para>
1838 <para>Almost all the rules look something like this:</para>
1840 <programlisting>%.o : %.c
1842 $(CC) $(CC_OPTS) -c $< -o $@</programlisting>
1844 <para>Here's how to understand the rule. It says that
1845 <emphasis>something</emphasis><filename>.o</filename> (say
1846 <filename>Foo.o</filename>) can be built from
1847 <emphasis>something</emphasis><filename>.c</filename>
1848 (<filename>Foo.c</filename>), by invoking the C compiler (path
1849 name held in <constant>$(CC)</constant>), passing to it
1850 the options <constant>$(CC_OPTS)</constant> and
1851 the rule's dependent file of the rule
1852 <literal>$<</literal> (<filename>Foo.c</filename> in
1853 this case), and putting the result in the rule's target
1854 <literal>$@</literal> (<filename>Foo.o</filename> in this
1857 <para>Every program is held in a <command>make</command>
1858 variable defined in <filename>mk/config.mk</filename>—look
1859 in <filename>mk/config.mk</filename> for the complete list. One
1860 important one is the Haskell compiler, which is called
1861 <constant>$(HC)</constant>.</para>
1863 <para>Every program's options are are held in a
1864 <command>make</command> variables called
1865 <constant><prog>_OPTS</constant>. the
1866 <constant><prog>_OPTS</constant> variables are
1867 defined in <filename>mk/opts.mk</filename>. Almost all of them
1868 are defined like this:</para>
1870 <programlisting>CC_OPTS = \
1871 $(SRC_CC_OPTS) $(WAY$(_way)_CC_OPTS) $($*_CC_OPTS) $(EXTRA_CC_OPTS)</programlisting>
1873 <para>The four variables from which
1874 <constant>CC_OPTS</constant> is built have the following
1879 <term><constant>SRC_CC_OPTS</constant><indexterm><primary>SRC_CC_OPTS</primary></indexterm>:</term>
1881 <para>options passed to all C compilations.</para>
1886 <term><constant>WAY_<way>_CC_OPTS</constant>:</term>
1888 <para>options passed to C compilations for way
1889 <literal><way></literal>. For example,
1890 <constant>WAY_mp_CC_OPTS</constant>
1891 gives options to pass to the C compiler when compiling way
1892 <literal>mp</literal>. The variable
1893 <constant>WAY_CC_OPTS</constant> holds
1894 options to pass to the C compiler when compiling the
1895 standard way. (<xref linkend="sec-ways"/> dicusses
1896 multi-way compilation.)</para>
1901 <term><constant><module>_CC_OPTS</constant>:</term>
1903 <para>options to pass to the C compiler that are specific
1904 to module <literal><module></literal>. For example,
1905 <constant>SMap_CC_OPTS</constant> gives the
1906 specific options to pass to the C compiler when compiling
1907 <filename>SMap.c</filename>.</para>
1912 <term><constant>EXTRA_CC_OPTS</constant><indexterm><primary>EXTRA_CC_OPTS</primary></indexterm>:</term>
1914 <para>extra options to pass to all C compilations. This
1915 is intended for command line use, thus:</para>
1917 <screen>$ make libHS.a EXTRA_HC_OPTS="-v"</screen>
1923 <sect2 id="sec-targets">
1924 <title>The main <filename>mk/target.mk</filename> file</title>
1925 <indexterm><primary>target.mk</primary></indexterm>
1927 <para><filename>target.mk</filename> contains canned rules for
1928 all the standard targets described in <xref
1929 linkend="sec-standard-targets"/>. It is complicated by the fact
1930 that you don't want all of these rules to be active in every
1931 <filename>Makefile</filename>. Rather than have a plethora of
1932 tiny files which you can include selectively, there is a single
1933 file, <filename>target.mk</filename>, which selectively includes
1934 rules based on whether you have defined certain variables in
1935 your <filename>Makefile</filename>. This section explains what
1936 rules you get, what variables control them, and what the rules
1937 do. Hopefully, you will also get enough of an idea of what is
1938 supposed to happen that you can read and understand any weird
1939 special cases yourself.</para>
1943 <term><constant>HS_PROG</constant><indexterm><primary>HS_PROG</primary></indexterm>.</term>
1945 <para>If <constant>HS_PROG</constant> is defined,
1946 you get rules with the following targets:</para>
1950 <term><filename>HS_PROG</filename><indexterm><primary>HS_PROG</primary></indexterm></term>
1952 <para>itself. This rule links
1953 <constant>$(OBJS)</constant> with the Haskell
1954 runtime system to get an executable called
1955 <constant>$(HS_PROG)</constant>.</para>
1960 <term><literal>install</literal><indexterm><primary>install</primary></indexterm></term>
1963 <constant>$(HS_PROG)</constant> in
1964 <constant>$(bindir)</constant>.</para>
1973 <term><constant>C_PROG</constant><indexterm><primary>C_PROG</primary></indexterm></term>
1975 <para>is similar to <constant>HS_PROG</constant>,
1976 except that the link step links
1977 <constant>$(C_OBJS)</constant> with the C
1978 runtime system.</para>
1983 <term><constant>LIBRARY</constant><indexterm><primary>LIBRARY</primary></indexterm></term>
1985 <para>is similar to <constant>HS_PROG</constant>,
1986 except that it links
1987 <constant>$(LIB_OBJS)</constant> to make the
1988 library archive <constant>$(LIBRARY)</constant>,
1989 and <literal>install</literal> installs it in
1990 <constant>$(libdir)</constant>.</para>
1995 <para>Some rules are “double-colon” rules,
1998 <programlisting>install :: $(HS_PROG)
1999 ...how to install it...</programlisting>
2001 <para>GNU <command>make</command> treats double-colon rules as
2002 separate entities. If there are several double-colon rules for
2003 the same target it takes each in turn and fires it if its
2004 dependencies say to do so. This means that you can, for
2005 example, define both <constant>HS_PROG</constant> and
2006 <constant>LIBRARY</constant>, which will generate two rules for
2007 <literal>install</literal>. When you type <command>make
2008 install</command> both rules will be fired, and both the program
2009 and the library will be installed, just as you wanted.</para>
2012 <sect2 id="sec-subdirs">
2013 <title>Recursion</title>
2014 <indexterm><primary>recursion, in makefiles</primary></indexterm>
2015 <indexterm><primary>Makefile, recursing into subdirectories</primary></indexterm>
2017 <para>In leaf <filename>Makefile</filename>s the variable
2018 <constant>SUBDIRS</constant><indexterm><primary>SUBDIRS</primary></indexterm>
2019 is undefined. In non-leaf <filename>Makefile</filename>s,
2020 <constant>SUBDIRS</constant> is set to the list of
2021 sub-directories that contain subordinate
2022 <filename>Makefile</filename>s. <emphasis>It is up to you to
2023 set <constant>SUBDIRS</constant> in the
2024 <filename>Makefile</filename>.</emphasis> There is no automation
2025 here—<constant>SUBDIRS</constant> is too important to
2028 <para>When <constant>SUBDIRS</constant> is defined,
2029 <filename>target.mk</filename> includes a rather neat rule for
2030 the standard targets (<xref linkend="sec-standard-targets"/> that
2031 simply invokes <command>make</command> recursively in each of
2032 the sub-directories.</para>
2034 <para><emphasis>These recursive invocations are guaranteed to
2035 occur in the order in which the list of directories is specified
2036 in <constant>SUBDIRS</constant>. </emphasis>This guarantee can
2037 be important. For example, when you say <command>make
2038 boot</command> it can be important that the recursive invocation
2039 of <command>make boot</command> is done in one sub-directory
2040 (the include files, say) before another (the source files).
2041 Generally, put the most independent sub-directory first, and the
2042 most dependent last.</para>
2045 <sect2 id="sec-ways">
2046 <title>Way management</title>
2047 <indexterm><primary>way management</primary></indexterm>
2049 <para>We sometimes want to build essentially the same system in
2050 several different “ways”. For example, we want to build GHC's
2051 <literal>Prelude</literal> libraries with and without profiling,
2052 so that there is an appropriately-built library archive to link
2053 with when the user compiles his program. It would be possible
2054 to have a completely separate build tree for each such “way”,
2055 but it would be horribly bureaucratic, especially since often
2056 only parts of the build tree need to be constructed in multiple
2060 <filename>target.mk</filename><indexterm><primary>target.mk</primary></indexterm>
2061 contains some clever magic to allow you to build several
2062 versions of a system; and to control locally how many versions
2063 are built and how they differ. This section explains the
2066 <para>The files for a particular way are distinguished by
2067 munging the suffix. The <quote>normal way</quote> is always
2068 built, and its files have the standard suffices
2069 <filename>.o</filename>, <filename>.hi</filename>, and so on.
2070 In addition, you can build one or more extra ways, each
2071 distinguished by a <emphasis>way tag</emphasis>. The object
2072 files and interface files for one of these extra ways are
2073 distinguished by their suffix. For example, way
2074 <literal>mp</literal> has files
2075 <filename>.mp_o</filename> and
2076 <filename>.mp_hi</filename>. Library archives have their
2077 way tag the other side of the dot, for boring reasons; thus,
2078 <filename>libHS_mp.a</filename>.</para>
2080 <para>A <command>make</command> variable called
2081 <constant>way</constant> holds the current way tag.
2082 <emphasis><constant>way</constant> is only ever set on the
2083 command line of <command>make</command></emphasis> (usually in
2084 a recursive invocation of <command>make</command> by the
2085 system). It is never set inside a
2086 <filename>Makefile</filename>. So it is a global constant for
2087 any one invocation of <command>make</command>. Two other
2088 <command>make</command> variables,
2089 <constant>way_</constant> and
2090 <constant>_way</constant> are immediately derived from
2091 <constant>$(way)</constant> and never altered. If
2092 <constant>way</constant> is not set, then neither are
2093 <constant>way_</constant> and
2094 <constant>_way</constant>, and the invocation of
2095 <command>make</command> will build the <quote>normal
2096 way</quote>. If <constant>way</constant> is set, then the other
2097 two variables are set in sympathy. For example, if
2098 <constant>$(way)</constant> is “<literal>mp</literal>”,
2099 then <constant>way_</constant> is set to
2100 “<literal>mp_</literal>” and
2101 <constant>_way</constant> is set to
2102 “<literal>_mp</literal>”. These three variables are
2103 then used when constructing file names.</para>
2105 <para>So how does <command>make</command> ever get recursively
2106 invoked with <constant>way</constant> set? There are two ways
2107 in which this happens:</para>
2111 <para>For some (but not all) of the standard targets, when
2112 in a leaf sub-directory, <command>make</command> is
2113 recursively invoked for each way tag in
2114 <constant>$(WAYS)</constant>. You set
2115 <constant>WAYS</constant> in the
2116 <filename>Makefile</filename> to the list of way tags you
2117 want these targets built for. The mechanism here is very
2118 much like the recursive invocation of
2119 <command>make</command> in sub-directories (<xref
2120 linkend="sec-subdirs"/>). It is up to you to set
2121 <constant>WAYS</constant> in your
2122 <filename>Makefile</filename>; this is how you control what
2123 ways will get built.</para>
2127 <para>For a useful collection of targets (such as
2128 <filename>libHS_mp.a</filename>,
2129 <filename>Foo.mp_o</filename>) there is a rule which
2130 recursively invokes <command>make</command> to make the
2131 specified target, setting the <constant>way</constant>
2132 variable. So if you say <command>make
2133 Foo.mp_o</command> you should see a recursive
2134 invocation <command>make Foo.mp_o way=mp</command>,
2135 and <emphasis>in this recursive invocation the pattern rule
2136 for compiling a Haskell file into a <filename>.o</filename>
2137 file will match</emphasis>. The key pattern rules (in
2138 <filename>suffix.mk</filename>) look like this:
2140 <programlisting>%.$(way_)o : %.lhs
2141 $(HC) $(HC_OPTS) $< -o $@</programlisting>
2147 <para>You can invoke <command>make</command> with a
2148 particular <literal>way</literal> setting yourself, in order
2149 to build files related to a particular
2150 <literal>way</literal> in the current directory. eg.
2152 <screen>$ make way=p</screen>
2154 will build files for the profiling way only in the current
2161 <title>When the canned rule isn't right</title>
2163 <para>Sometimes the canned rule just doesn't do the right thing.
2164 For example, in the <literal>nofib</literal> suite we want the
2165 link step to print out timing information. The thing to do here
2166 is <emphasis>not</emphasis> to define
2167 <constant>HS_PROG</constant> or
2168 <constant>C_PROG</constant>, and instead define a special
2169 purpose rule in your own <filename>Makefile</filename>. By
2170 using different variable names you will avoid the canned rules
2171 being included, and conflicting with yours.</para>
2175 <sect1 id="building-docs">
2176 <title>Building the documentation</title>
2178 <sect2 id="pre-supposed-doc-tools">
2179 <title>Tools for building the Documentation</title>
2181 <para>The following additional tools are required if you want to
2182 format the documentation that comes with GHC:</para>
2187 <indexterm><primary>pre-supposed: DocBook</primary></indexterm>
2188 <indexterm><primary>DocBook, pre-supposed</primary></indexterm>
2191 <para>Much of our documentation is written in DocBook XML, instructions
2192 on installing and configuring the DocBook tools are below.</para>
2198 <indexterm><primary>pre-supposed: TeX</primary></indexterm>
2199 <indexterm><primary>TeX, pre-supposed</primary></indexterm>
2202 <para>A decent TeX distribution is required if you want to
2203 produce printable documentation. We recomment teTeX,
2204 which includes just about everything you need.</para>
2210 <indexterm><primary>Haddock</primary></indexterm>
2213 <para>Haddock is a Haskell documentation tool that we use
2214 for automatically generating documentation from the
2215 library source code. To build documentation for the
2216 libraries (<literal>$(GHC_TOP)/libraries</literal>) you
2217 should build and install Haddock. Haddock requires GHC
2225 <title>Installing the DocBook tools</title>
2228 <title>Installing the DocBook tools on Linux</title>
2230 <para>If you're on a recent RedHat (7.0+) or SuSE (8.1+) system,
2231 you probably have working DocBook tools already installed. The
2232 configure script should detect your setup and you're away.</para>
2234 <para>If you don't have DocBook tools installed, and you are
2235 using a system that can handle RPM packages, you can use <ulink
2236 url="http://rpmfind.net/">Rpmfind.net</ulink> to find suitable
2237 packages for your system. Search for the packages
2238 <literal>docbook-dtd</literal>,
2239 <literal>docbook-xsl-stylesheets</literal>,
2240 <literal>libxslt</literal>,
2241 <literal>libxml2</literal>,
2242 <literal>fop</literal>,
2243 <literal>xmltex</literal>, and
2244 <literal>dvips</literal>.</para>
2248 <title>Installing DocBook on FreeBSD</title>
2250 <para>On FreeBSD systems, the easiest way to get DocBook up
2251 and running is to install it from the ports tree or a
2252 pre-compiled package (packages are available from your local
2253 FreeBSD mirror site).</para>
2255 <para>To use the ports tree, do this:
2256 <screen>$ cd /usr/ports/textproc/docproj
2257 $ make install</screen>
2258 This installs the FreeBSD documentation project tools, which
2259 includes everything needed to format the GHC
2260 documentation.</para>
2264 <title>Installing from binaries on Windows</title>
2266 <para>Probably the fastest route to a working DocBook environment on
2267 Windows is to install <ulink url="http://www.cygwin.com/">Cygwin</ulink>
2268 with the complete <literal>Doc</literal> category. If you are using
2269 <ulink url="http://www.mingw.org/">MinGW</ulink> for compilation, you
2270 have to help <command>configure</command> a little bit: Set the
2271 environment variables <envar>XmllintCmd</envar> and
2272 <envar>XsltprocCmd</envar> to the paths of the Cygwin executables
2273 <command>xmllint</command> and <command>xsltproc</command>,
2274 respectively, and set <envar>fp_cv_dir_docbook_xsl</envar> to the path
2275 of the directory where the XSL stylesheets are installed,
2276 e.g. <filename>c:/cygwin/usr/share/docbook-xsl</filename>.
2279 <para>If you want to build HTML Help, you have to install the
2280 <ulink url="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/htmlhelp/html/hworiHTMLHelpStartPage.asp">HTML Help SDK</ulink>,
2281 too, and make sure that <command>hhc</command> is in your <envar>PATH</envar>.</para>
2287 <title>Configuring the DocBook tools</title>
2289 <para>Once the DocBook tools are installed, the configure script
2290 will detect them and set up the build system accordingly. If you
2291 have a system that isn't supported, let us know, and we'll try
2296 <title>Building the documentation</title>
2298 <para>To build documentation in a certain format, you can
2299 say, for example,</para>
2301 <screen>$ make html</screen>
2303 <para>to build HTML documentation below the current directory.
2304 The available formats are: <literal>dvi</literal>,
2305 <literal>ps</literal>, <literal>pdf</literal>,
2306 <literal>html</literal>, and <literal>rtf</literal>. Note that
2307 not all documentation can be built in all of these formats: HTML
2308 documentation is generally supported everywhere, and DocBook
2309 documentation might support the other formats (depending on what
2310 other tools you have installed).</para>
2312 <para>All of these targets are recursive; that is, saying
2313 <literal>make html</literal> will make HTML docs for all the
2314 documents recursively below the current directory.</para>
2316 <para>Because there are many different formats that the DocBook
2317 documentation can be generated in, you have to select which ones
2318 you want by setting the <literal>XMLDocWays</literal> variable
2319 to a list of them. For example, in
2320 <filename>build.mk</filename> you might have a line:</para>
2322 <screen>XMLDocWays = html ps</screen>
2324 <para>This will cause the documentation to be built in the requested
2325 formats as part of the main build (the default is not to build
2326 any documentation at all).</para>
2330 <title>Installing the documentation</title>
2332 <para>To install the documentation, use:</para>
2334 <screen>$ make install-docs</screen>
2336 <para>This will install the documentation into
2337 <literal>$(datadir)</literal> (which defaults to
2338 <literal>$(prefix)/share</literal>). The exception is HTML
2339 documentation, which goes into
2340 <literal>$(datadir)/html</literal>, to keep things tidy.</para>
2342 <para>Note that unless you set <literal>$(XMLDocWays)</literal>
2343 to a list of formats, the <literal>install-docs</literal> target
2344 won't do anything for DocBook XML documentation.</para>
2350 <sect1 id="sec-porting-ghc">
2351 <title>Porting GHC</title>
2353 <para>This section describes how to port GHC to a currenly
2354 unsupported platform. There are two distinct
2355 possibilities:</para>
2359 <para>The hardware architecture for your system is already
2360 supported by GHC, but you're running an OS that isn't
2361 supported (or perhaps has been supported in the past, but
2362 currently isn't). This is the easiest type of porting job,
2363 but it still requires some careful bootstrapping. Proceed to
2364 <xref linkend="sec-booting-from-hc"/>.</para>
2368 <para>Your system's hardware architecture isn't supported by
2369 GHC. This will be a more difficult port (though by comparison
2370 perhaps not as difficult as porting gcc). Proceed to <xref
2371 linkend="unregisterised-porting"/>.</para>
2375 <sect2 id="sec-booting-from-hc">
2376 <title>Booting/porting from C (<filename>.hc</filename>) files</title>
2378 <indexterm><primary>building GHC from .hc files</primary></indexterm>
2379 <indexterm><primary>booting GHC from .hc files</primary></indexterm>
2380 <indexterm><primary>porting GHC</primary></indexterm>
2382 <para>Bootstrapping GHC on a system without GHC already
2383 installed is achieved by taking the intermediate C files (known
2384 as HC files) from another GHC compilation, compiling them using gcc to
2385 get a working GHC.</para>
2387 <para><emphasis>NOTE: GHC versions 5.xx were hard to bootstrap
2388 from C. We recommend using GHC 6.0.1 or
2389 later.</emphasis></para>
2391 <para>HC files are platform-dependent, so you have to get a set
2392 that were generated on <emphasis>the same platform</emphasis>. There
2393 may be some supplied on the GHC download page, otherwise you'll have to
2394 compile some up yourself, or start from
2395 <emphasis>unregisterised</emphasis> HC files - see <xref
2396 linkend="unregisterised-porting"/>.</para>
2398 <para>The following steps should result in a working GHC build
2399 with full libraries:</para>
2403 <para>Unpack the HC files on top of a fresh source tree
2404 (make sure the source tree version matches the version of
2405 the HC files <emphasis>exactly</emphasis>!). This will
2406 place matching <filename>.hc</filename> files next to the
2407 corresponding Haskell source (<filename>.hs</filename> or
2408 <filename>.lhs</filename>) in the compiler subdirectory
2409 <filename>ghc/compiler</filename> and in the libraries
2411 <literal>libraries</literal>).</para>
2415 <para>The actual build process is fully automated by the
2416 <filename>hc-build</filename> script located in the
2417 <filename>distrib</filename> directory. If you eventually
2418 want to install GHC into the directory
2419 <replaceable>dir</replaceable>, the following
2420 command will execute the whole build process (it won't
2421 install yet):</para>
2423 <screen>$ distrib/hc-build --prefix=<replaceable>dir</replaceable></screen>
2424 <indexterm><primary>--hc-build</primary></indexterm>
2426 <para>By default, the installation directory is
2427 <filename>/usr/local</filename>. If that is what you want,
2428 you may omit the argument to <filename>hc-build</filename>.
2429 Generally, any option given to <filename>hc-build</filename>
2430 is passed through to the configuration script
2431 <filename>configure</filename>. If
2432 <filename>hc-build</filename> successfully completes the
2433 build process, you can install the resulting system, as
2436 <screen>$ make install</screen>
2441 <sect2 id="unregisterised-porting">
2442 <title>Porting GHC to a new architecture</title>
2444 <para>The first step in porting to a new architecture is to get
2445 an <firstterm>unregisterised</firstterm> build working. An
2446 unregisterised build is one that compiles via vanilla C only.
2447 By contrast, a registerised build uses the following
2448 architecture-specific hacks for speed:</para>
2452 <para>Global register variables: certain abstract machine
2453 <quote>registers</quote> are mapped to real machine
2454 registers, depending on how many machine registers are
2456 <filename>ghc/includes/MachRegs.h</filename>).</para>
2460 <para>Assembly-mangling: when compiling via C, we feed the
2461 assembly generated by gcc though a Perl script known as the
2462 <firstterm>mangler</firstterm> (see
2463 <filename>ghc/driver/mangler/ghc-asm.lprl</filename>). The
2464 mangler rearranges the assembly to support tail-calls and
2465 various other optimisations.</para>
2469 <para>In an unregisterised build, neither of these hacks are
2470 used — the idea is that the C code generated by the
2471 compiler should compile using gcc only. The lack of these
2472 optimisations costs about a factor of two in performance, but
2473 since unregisterised compilation is usually just a step on the
2474 way to a full registerised port, we don't mind too much.</para>
2476 <para>Notes on GHC portability in general: we've tried to stick
2477 to writing portable code in most parts of the system, so it
2478 should compile on any POSIXish system with gcc, but in our
2479 experience most systems differ from the standards in one way or
2480 another. Deal with any problems as they arise - if you get
2481 stuck, ask the experts on
2482 <email>glasgow-haskell-users@haskell.org</email>.</para>
2484 <para>Lots of useful information about the innards of GHC is
2485 available in the <ulink
2486 url="http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/">GHC
2487 Commentary</ulink>, which might be helpful if you run into some
2488 code which needs tweaking for your system.</para>
2491 <title>Cross-compiling to produce an unregisterised GHC</title>
2493 <para>NOTE! These instructions apply to GHC 6.4 and (hopefully)
2494 later. If you need instructions for an earlier version of GHC, try
2495 to get hold of the version of this document that was current at the
2496 time. It should be available from the appropriate download page on
2498 url="http://www.haskell.org/ghc/">GHC homepage</ulink>.</para>
2500 <para>In this section, we explain how to bootstrap GHC on a
2501 new platform, using unregisterised intermediate C files. We
2502 haven't put a great deal of effort into automating this
2503 process, for two reasons: it is done very rarely, and the
2504 process usually requires human intervention to cope with minor
2505 porting issues anyway.</para>
2507 <para>The following step-by-step instructions should result in
2508 a fully working, albeit unregisterised, GHC. Firstly, you
2509 need a machine that already has a working GHC (we'll call this
2510 the <firstterm>host</firstterm> machine), in order to
2511 cross-compile the intermediate C files that we will use to
2512 bootstrap the compiler on the <firstterm>target</firstterm>
2517 <para>On the target machine:</para>
2521 <para>Unpack a source tree (preferably a released
2522 version). We will call the path to the root of this
2523 tree <replaceable>T</replaceable>.</para>
2527 <screen>$ cd <replaceable>T</replaceable>
2528 $ ./configure --enable-hc-boot --enable-hc-boot-unregisterised</screen>
2530 <para>You might need to update
2531 <filename>configure.in</filename> to recognise the new
2532 architecture, and re-generate
2533 <filename>configure</filename> with
2534 <literal>autoreconf</literal>.</para>
2538 <screen>$ cd <replaceable>T</replaceable>/ghc/includes
2545 <para>On the host machine:</para>
2549 <para>Unpack a source tree (same released version). Call
2550 this directory <replaceable>H</replaceable>.</para>
2554 <screen>$ cd <replaceable>H</replaceable>
2555 $ ./configure</screen>
2560 <filename><replaceable>H</replaceable>/mk/build.mk</filename>,
2561 with the following contents:</para>
2563 <programlisting>GhcUnregisterised = YES
2564 GhcLibHcOpts = -O -fvia-C -keep-hc-files
2565 GhcRtsHcOpts = -keep-hc-files
2568 GhcWithNativeCodeGen = NO
2569 GhcWithInterpreter = NO
2570 GhcStage1HcOpts = -O
2571 GhcStage2HcOpts = -O -fvia-C -keep-hc-files
2572 SRC_HC_OPTS += -H32m
2573 GhcBootLibs = YES</programlisting>
2578 <filename><replaceable>H</replaceable>/mk/config.mk</filename>:</para>
2581 <para>change <literal>TARGETPLATFORM</literal>
2582 appropriately, and set the variables involving
2583 <literal>TARGET</literal> or
2584 <literal>Target</literal> to the correct values for
2585 the target platform. This step is necessary because
2586 currently <literal>configure</literal> doesn't cope
2587 with specifying different values for the
2588 <literal>--host</literal> and
2589 <literal>--target</literal> flags.</para>
2592 <para>copy <literal>LeadingUnderscore</literal>
2593 setting from target.</para>
2600 <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>
2602 <filename><replaceable>H</replaceable>/ghc/includes</filename>.
2603 Note that we are building on the host machine, using the
2604 target machine's configuration files. This
2605 is so that the intermediate C files generated here will
2606 be suitable for compiling on the target system.</para>
2610 <para>Touch the generated configuration files, just to make
2611 sure they don't get replaced during the build:</para>
2612 <screen>$ cd <filename><replaceable>H</replaceable></filename>/ghc/includes
2613 $ touch ghcautoconf.h DerivedConstants.h GHCConstants.h mkDerivedConstants.c
2614 $ touch mkDerivedConstantsHdr mkDerivedConstants.o mkGHCConstants mkGHCConstants.o</screen>
2616 <para>Note: it has been reported that these files still get
2617 overwritten during the next stage. We have installed a fix
2618 for this in GHC 6.4.2, but if you are building a version
2619 before that you need to watch out for these files getting
2620 overwritte by the <literal>Makefile</literal> in
2621 <literal>ghc/includes</literal>. If your system supports
2622 it, you might be able to prevent it by making them
2624 <screen>$ chflags uchg ghc/includes/{ghcautoconf.h,DerivedConstants.h,GHCConstants.h}</screen>
2628 <para>Now build the compiler:</para>
2629 <screen>$ cd <replaceable>H</replaceable>/glafp-utils && make boot && make
2630 $ cd <replaceable>H</replaceable>/ghc && make boot && make</screen>
2631 <para>Don't worry if the build falls over in the RTS, we
2632 don't need the RTS yet.</para>
2636 <screen>$ cd <replaceable>H</replaceable>/libraries
2637 $ make boot && make</screen>
2641 <screen>$ cd <replaceable>H</replaceable>/ghc/compiler
2642 $ make boot stage=2 && make stage=2</screen>
2646 <screen>$ cd <replaceable>H</replaceable>/compat
2649 $ make boot UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'
2650 $ cd <replaceable>H</replaceable>/ghc/utils
2652 $ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'</screen>
2656 <screen>$ cd <replaceable>H</replaceable>
2657 $ make hc-file-bundle Project=Ghc</screen>
2662 <filename><replaceable>H</replaceable>/*-hc.tar.gz</filename>
2663 to <filename><replaceable>T</replaceable>/..</filename>.</para>
2669 <para>On the target machine:</para>
2671 <para>At this stage we simply need to bootstrap a compiler
2672 from the intermediate C files we generated above. The
2673 process of bootstrapping from C files is automated by the
2674 script in <literal>distrib/hc-build</literal>, and is
2675 described in <xref linkend="sec-booting-from-hc"/>.</para>
2677 <screen>$ ./distrib/hc-build --enable-hc-boot-unregisterised</screen>
2679 <para>However, since this is a bootstrap on a new machine,
2680 the automated process might not run to completion the
2681 first time. For that reason, you might want to treat the
2682 <literal>hc-build</literal> script as a list of
2683 instructions to follow, rather than as a fully automated
2684 script. This way you'll be able to restart the process
2685 part-way through if you need to fix anything on the
2688 <para>Don't bother with running
2689 <literal>make install</literal> in the newly
2690 bootstrapped tree; just use the compiler in that tree to
2691 build a fresh compiler from scratch, this time without
2692 booting from C files. Before doing this, you might want
2693 to check that the bootstrapped compiler is generating
2694 working binaries:</para>
2696 <screen>$ cat >hello.hs
2697 main = putStrLn "Hello World!\n"
2699 $ <replaceable>T</replaceable>/ghc/compiler/ghc-inplace hello.hs -o hello
2701 Hello World!</screen>
2703 <para>Once you have the unregisterised compiler up and
2704 running, you can use it to start a registerised port. The
2705 following sections describe the various parts of the
2706 system that will need architecture-specific tweaks in
2707 order to get a registerised build going.</para>
2714 <title>Porting the RTS</title>
2716 <para>The following files need architecture-specific code for a
2717 registerised build:</para>
2721 <term><filename>ghc/includes/MachRegs.h</filename>
2722 <indexterm><primary><filename>MachRegs.h</filename></primary></indexterm>
2725 <para>Defines the STG-register to machine-register
2726 mapping. You need to know your platform's C calling
2727 convention, and which registers are generally available
2728 for mapping to global register variables. There are
2729 plenty of useful comments in this file.</para>
2733 <term><filename>ghc/includes/TailCalls.h</filename>
2734 <indexterm><primary><filename>TailCalls.h</filename></primary></indexterm>
2737 <para>Macros that cooperate with the mangler (see <xref
2738 linkend="sec-mangler"/>) to make proper tail-calls
2743 <term><filename>ghc/rts/Adjustor.c</filename>
2744 <indexterm><primary><filename>Adjustor.c</filename></primary></indexterm>
2748 <literal>foreign import "wrapper"</literal>
2750 <literal>foreign export dynamic</literal>).
2751 Not essential for getting GHC bootstrapped, so this file
2752 can be deferred until later if necessary.</para>
2756 <term><filename>ghc/rts/StgCRun.c</filename>
2757 <indexterm><primary><filename>StgCRun.c</filename></primary></indexterm>
2760 <para>The little assembly layer between the C world and
2761 the Haskell world. See the comments and code for the
2762 other architectures in this file for pointers.</para>
2766 <term><filename>ghc/rts/MBlock.h</filename>
2767 <indexterm><primary><filename>MBlock.h</filename></primary></indexterm>
2769 <term><filename>ghc/rts/MBlock.c</filename>
2770 <indexterm><primary><filename>MBlock.c</filename></primary></indexterm>
2773 <para>These files are really OS-specific rather than
2774 architecture-specific. In <filename>MBlock.h</filename>
2775 is specified the absolute location at which the RTS
2776 should try to allocate memory on your platform (try to
2777 find an area which doesn't conflict with code or dynamic
2778 libraries). In <filename>Mblock.c</filename> you might
2779 need to tweak the call to <literal>mmap()</literal> for
2786 <sect3 id="sec-mangler">
2787 <title>The mangler</title>
2789 <para>The mangler is an evil Perl-script
2790 (<filename>ghc/driver/mangler/ghc-asm.lprl</filename>) that
2791 rearranges the assembly code output from gcc to do two main
2796 <para>Remove function prologues and epilogues, and all
2797 movement of the C stack pointer. This is to support
2798 tail-calls: every code block in Haskell code ends in an
2799 explicit jump, so we don't want the C-stack overflowing
2800 while we're jumping around between code blocks.</para>
2803 <para>Move the <firstterm>info table</firstterm> for a
2804 closure next to the entry code for that closure. In
2805 unregisterised code, info tables contain a pointer to the
2806 entry code, but in registerised compilation we arrange
2807 that the info table is shoved right up against the entry
2808 code, and addressed backwards from the entry code pointer
2809 (this saves a word in the info table and an extra
2810 indirection when jumping to the closure entry
2815 <para>The mangler is abstracted to a certain extent over some
2816 architecture-specific things such as the particular assembler
2817 directives used to herald symbols. Take a look at the
2818 definitions for other architectures and use these as a
2819 starting point.</para>
2823 <title>The splitter</title>
2825 <para>The splitter is another evil Perl script
2826 (<filename>ghc/driver/split/ghc-split.lprl</filename>). It
2827 cooperates with the mangler to support object splitting.
2828 Object splitting is what happens when the
2829 <option>-split-objs</option> option is passed to GHC: the
2830 object file is split into many smaller objects. This feature
2831 is used when building libraries, so that a program statically
2832 linked against the library will pull in less of the
2835 <para>The splitter has some platform-specific stuff; take a
2836 look and tweak it for your system.</para>
2840 <title>The native code generator</title>
2842 <para>The native code generator isn't essential to getting a
2843 registerised build going, but it's a desirable thing to have
2844 because it can cut compilation times in half. The native code
2845 generator is described in some detail in the <ulink
2846 url="http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/">GHC
2847 commentary</ulink>.</para>
2853 <para>To support GHCi, you need to port the dynamic linker
2854 (<filename>$(GHC_TOP)/rts/Linker.c</filename>). The linker
2855 currently supports the ELF and PEi386 object file formats - if
2856 your platform uses one of these then things will be
2857 significantly easier. The majority of Unix platforms use the
2858 ELF format these days. Even so, there are some
2859 machine-specific parts of the ELF linker: for example, the
2860 code for resolving particular relocation types is
2861 machine-specific, so some porting of this code to your
2862 architecture will probaly be necessary.</para>
2864 <para>If your system uses a different object file format, then
2865 you have to write a linker — good luck!</para>
2871 <sect1 id="sec-build-pitfalls">
2872 <title>Known pitfalls in building Glasgow Haskell
2874 <indexterm><primary>problems, building</primary></indexterm>
2875 <indexterm><primary>pitfalls, in building</primary></indexterm>
2876 <indexterm><primary>building pitfalls</primary></indexterm></title>
2879 WARNINGS about pitfalls and known “problems”:
2888 One difficulty that comes up from time to time is running out of space
2889 in <literal>TMPDIR</literal>. (It is impossible for the configuration stuff to
2890 compensate for the vagaries of different sysadmin approaches to temp
2892 <indexterm><primary>tmp, running out of space in</primary></indexterm>
2894 The quickest way around it is <command>setenv TMPDIR /usr/tmp</command><indexterm><primary>TMPDIR</primary></indexterm> or
2895 even <command>setenv TMPDIR .</command> (or the equivalent incantation with your shell
2898 The best way around it is to say
2900 <programlisting>export TMPDIR=<dir></programlisting>
2902 in your <filename>build.mk</filename> file. Then GHC and the other
2903 tools will use the appropriate directory in all cases.
2911 In compiling some support-code bits, e.g., in <filename>ghc/rts/gmp</filename> and even
2912 in <filename>ghc/lib</filename>, you may get a few C-compiler warnings. We think these
2920 When compiling via C, you'll sometimes get “warning: assignment from
2921 incompatible pointer type” out of GCC. Harmless.
2928 Similarly, <command>ar</command>chiving warning messages like the following are not
2931 <screen>ar: filename GlaIOMonad__1_2s.o truncated to GlaIOMonad_
2932 ar: filename GlaIOMonad__2_2s.o truncated to GlaIOMonad_
2941 In compiling the compiler proper (in <filename>compiler/</filename>), you <emphasis>may</emphasis>
2942 get an “Out of heap space” error message. These can vary with the
2943 vagaries of different systems, it seems. The solution is simple:
2950 If you're compiling with GHC 4.00 or later, then the
2951 <emphasis>maximum</emphasis> heap size must have been reached. This
2952 is somewhat unlikely, since the maximum is set to 64M by default.
2953 Anyway, you can raise it with the
2954 <option>-optCrts-M<size></option> flag (add this flag to
2955 <constant><module>_HC_OPTS</constant>
2956 <command>make</command> variable in the appropriate
2957 <filename>Makefile</filename>).
2964 For GHC < 4.00, add a suitable <option>-H</option> flag to the <filename>Makefile</filename>, as
2973 and try again: <command>make</command>. (see <xref linkend="sec-suffix"/> for information about
2974 <constant><module>_HC_OPTS</constant>.)
2976 Alternatively, just cut to the chase:
2978 <screen>$ cd ghc/compiler
2979 $ make EXTRA_HC_OPTS=-optCrts-M128M</screen>
2987 If you try to compile some Haskell, and you get errors from GCC about
2988 lots of things from <filename>/usr/include/math.h</filename>, then your GCC was
2989 mis-installed. <command>fixincludes</command> wasn't run when it should've been.
2991 As <command>fixincludes</command> is now automagically run as part of GCC installation,
2992 this bug also suggests that you have an old GCC.
3000 You <emphasis>may</emphasis> need to re-<command>ranlib</command><indexterm><primary>ranlib</primary></indexterm> your libraries (on Sun4s).
3003 <screen>$ cd $(libdir)/ghc-x.xx/sparc-sun-sunos4
3004 $ foreach i ( `find . -name '*.a' -print` ) # or other-shell equiv...
3006 ? # or, on some machines: ar s $i
3010 We'd be interested to know if this is still necessary.
3018 GHC's sources go through <command>cpp</command> before being compiled, and <command>cpp</command> varies
3019 a bit from one Unix to another. One particular gotcha is macro calls
3023 <programlisting>SLIT("Hello, world")</programlisting>
3026 Some <command>cpp</command>s treat the comma inside the string as separating two macro
3027 arguments, so you get
3030 <screen>:731: macro `SLIT' used with too many (2) args</screen>
3033 Alas, <command>cpp</command> doesn't tell you the offending file!
3035 Workaround: don't put weird things in string args to <command>cpp</command> macros.
3046 <sect1 id="platforms"><title>Platforms, scripts, and file names</title>
3048 GHC is designed both to be built, and to run, on both Unix and Windows. This flexibility
3049 gives rise to a good deal of brain-bending detail, which we have tried to collect in this chapter.
3052 <sect2 id="cygwin-and-mingw"><title>Windows platforms: Cygwin, MSYS, and MinGW</title>
3054 <para> The build system is built around Unix-y makefiles. Because it's not native,
3055 the Windows situation for building GHC is particularly confusing. This section
3056 tries to clarify, and to establish terminology.</para>
3058 <sect3 id="ghc-mingw"><title>MinGW</title>
3060 <para> <ulink url="http://www.mingw.org">MinGW (Minimalist GNU for Windows)</ulink>
3061 is a collection of header
3062 files and import libraries that allow one to use <command>gcc</command> and produce
3063 native Win32 programs that do not rely on any third-party DLLs. The
3064 current set of tools include GNU Compiler Collection (<command>gcc</command>), GNU Binary
3065 Utilities (Binutils), GNU debugger (Gdb), GNU make, and a assorted
3069 <para> The down-side of MinGW is that the MinGW libraries do not support anything like the full
3074 <sect3 id="ghc-cygwin"><title>Cygwin and MSYS</title>
3076 <para>You can't use the MinGW to <emphasis>build</emphasis> GHC, because MinGW doesn't have a shell,
3077 or the standard Unix commands such as <command>mv</command>, <command>rm</command>,
3078 <command>ls</command>, nor build-system stuff such as <command>make</command> and <command>darcs</command>.
3079 For that, there are two choices: <ulink url="http://www.cygwin.com">Cygwin</ulink>
3080 and <ulink url="http://www.mingw.org/msys.shtml">MSYS</ulink>:
3084 Cygwin comes with compilation tools (<command>gcc</command>, <command>ld</command> and so on), which
3085 compile code that has access to all of Posix. The price is that the executables must be
3086 dynamically linked with the Cygwin DLL, so that <emphasis>you cannot run a Cywin-compiled program on a machine
3087 that doesn't have Cygwin</emphasis>. Worse, Cygwin is a moving target. The name of the main DLL, <literal>cygwin1.dll</literal>
3088 does not change, but the implementation certainly does. Even the interfaces to functions
3089 it exports seem to change occasionally. </para>
3093 MSYS is a fork of the Cygwin tree, so they
3094 are fundamentally similar. However, MSYS is by design much smaller and simpler. Access to the file system goes
3095 through fewer layers, so MSYS is quite a bit faster too.
3098 <para>Furthermore, MSYS provides no compilation tools; it relies instead on the MinGW tools. These
3099 compile binaries that run with no DLL support, on any Win32 system.
3100 However, MSYS does come with all the make-system tools, such as <command>make</command>, <command>autoconf</command>,
3101 <command>darcs</command>, <command>ssh</command> etc. To get these, you have to download the
3102 MsysDTK (Developer Tool Kit) package, as well as the base MSYS package.
3104 <para>MSYS does have a DLL, but it's only used by MSYS commands (<command>sh</command>, <command>rm</command>,
3105 <command>ssh</command> and so on),
3106 not by programs compiled under MSYS.
3114 <sect3><title>Targeting MinGW</title>
3116 <para>We want GHC to compile programs that work on any Win32 system. Hence:
3119 GHC does invoke a C compiler, assembler, linker and so on, but we ensure that it only
3120 invokes the MinGW tools, not the Cygwin ones. That means that the programs GHC compiles
3121 will work on any system, but it also means that the programs GHC compiles do not have access
3122 to all of Posix. In particular, they cannot import the (Haskell) Posix
3123 library; they have to do
3124 their input output using standard Haskell I/O libraries, or native Win32 bindings.</para>
3125 <para> We will call a GHC that targets MinGW in this way <emphasis>GHC-mingw</emphasis>.</para>
3129 To make the GHC distribution self-contained, the GHC distribution includes the MinGW <command>gcc</command>,
3130 <command>as</command>, <command>ld</command>, and a bunch of input/output libraries.
3133 So <emphasis>GHC targets MinGW</emphasis>, not Cygwin.
3134 It is in principle possible to build a version of GHC, <emphasis>GHC-cygwin</emphasis>,
3135 that targets Cygwin instead. The up-side of GHC-cygwin is
3136 that Haskell programs compiled by GHC-cygwin can import the (Haskell) Posix library.
3137 <emphasis>We do not support GHC-cygwin, however; it is beyond our resources.</emphasis>
3140 <para>While GHC <emphasis>targets</emphasis> MinGW, that says nothing about
3141 how GHC is <emphasis>built</emphasis>. We use both MSYS and Cygwin as build environments for
3142 GHC; both work fine, though MSYS is rather lighter weight.</para>
3144 <para>In your build tree, you build a compiler called <command>ghc-inplace</command>. It
3145 uses the <command>gcc</command> that you specify using the
3146 <option>--with-gcc</option> flag when you run
3147 <command>configure</command> (see below).
3148 The makefiles are careful to use <command>ghc-inplace</command> (not <command>gcc</command>)
3149 to compile any C files, so that it will in turn invoke the correct <command>gcc</command> rather that
3150 whatever one happens to be in your path. However, the makefiles do use whatever <command>ld</command>
3151 and <command>ar</command> happen to be in your path. This is a bit naughty, but (a) they are only
3152 used to glom together .o files into a bigger .o file, or a .a file,
3153 so they don't ever get libraries (which would be bogus; they might be the wrong libraries), and (b)
3154 Cygwin and MinGW use the same .o file format. So its ok.
3158 <sect3><title> File names </title>
3160 <para>Cygwin, MSYS, and the underlying Windows file system all understand file paths of form <literal>c:/tmp/foo</literal>.
3164 MSYS programs understand <filename>/bin</filename>, <filename>/usr/bin</filename>, and map Windows's lettered drives as
3165 <filename>/c/tmp/foo</filename> etc. The exact mount table is given in the doc subdirectory of the MSYS distribution.
3167 <para> When it invokes a command, the MSYS shell sees whether the invoked binary lives in the MSYS <filename>/bin</filename>
3168 directory. If so, it just invokes it. If not, it assumes the program is no an MSYS program, and walks over the command-line
3169 arguments changing MSYS paths into native-compatible paths. It does this inside sub-arguments and inside quotes. For example,
3171 <programlisting>foogle -B/c/tmp/baz</programlisting>
3172 the MSYS shell will actually call <literal>foogle</literal> with argument <literal>-Bc:/tmp/baz</literal>.
3176 Cygwin programs have a more complicated mount table, and map the lettered drives as <filename>/cygdrive/c/tmp/foo</filename>.
3178 <para>The Cygwin shell does no argument processing when invoking non-Cygwin programs.
3184 <sect3><title>Crippled <command>ld</command></title>
3187 It turns out that on both Cygwin and MSYS, the <command>ld</command> has a
3188 limit of 32kbytes on its command line. Especially when using split object
3189 files, the make system can emit calls to <command>ld</command> with thousands
3190 of files on it. Then you may see something like this:
3192 (cd Graphics/Rendering/OpenGL/GL/QueryUtils_split && /mingw/bin/ld -r -x -o ../QueryUtils.o *.o)
3193 /bin/sh: /mingw/bin/ld: Invalid argument
3195 The solution is either to switch off object file splitting (set
3196 <option>SplitObjs</option> to <literal>NO</literal> in your
3197 <filename>build.mk</filename>),
3198 or to make the module smaller.
3202 <sect3><title>Host System vs Target System</title>
3205 In the source code you'll find various ifdefs looking like:
3206 <programlisting>#ifdef mingw32_HOST_OS
3208 #endif</programlisting>
3210 <programlisting>#ifdef mingw32_TARGET_OS
3212 #endif</programlisting>
3213 These macros are set by the configure script (via the file config.h).
3214 Which is which? The criterion is this. In the ifdefs in GHC's source code:
3217 <para>The "host" system is the one on which GHC itself will be run.</para>
3220 <para>The "target" system is the one for which the program compiled by GHC will be run.</para>
3223 For a stage-2 compiler, in which GHCi is available, the "host" and "target" systems must be the same.
3224 So then it doesn't really matter whether you use the HOST_OS or TARGET_OS cpp macros.
3231 <sect2><title>Wrapper scripts</title>
3234 Many programs, including GHC itself and hsc2hs, need to find associated binaries and libraries.
3235 For <emphasis>installed</emphasis> programs, the strategy depends on the platform. We'll use
3236 GHC itself as an example:
3239 On Unix, the command <command>ghc</command> is a shell script, generated by adding installation
3240 paths to the front of the source file <filename>ghc.sh</filename>,
3241 that invokes the real binary, passing "-B<emphasis>path</emphasis>" as an argument to tell <command>ghc</command>
3242 where to find its supporting files.
3246 On vanilla Windows, it turns out to be much harder to make reliable script to be run by the
3247 native Windows shell <command>cmd</command> (e.g. limits on the length
3248 of the command line). So instead we invoke the GHC binary directly, with no -B flag.
3249 GHC uses the Windows <literal>getExecDir</literal> function to find where the executable is,
3250 and from that figures out where the supporting files are.
3253 (You can find the layout of GHC's supporting files in the
3254 section "Layout of installed files" of Section 2 of the GHC user guide.)
3257 Things work differently for <emphasis>in-place</emphasis> execution, where you want to
3258 execute a program that has just been built in a build tree. The difference is that the
3259 layout of the supporting files is different.
3260 In this case, whether on Windows or Unix, we always use a shell script. This works OK
3261 on Windows because the script is executed by MSYS or Cygwin, which don't have the
3262 shortcomings of the native Windows <command>cmd</command> shell.
3269 <sect1 id="winbuild"><title>Instructions for building under Windows</title>
3272 This section gives detailed instructions for how to build
3273 GHC from source on your Windows machine. Similar instructions for
3274 installing and running GHC may be found in the user guide. In general,
3275 Win95/Win98 behave the same, and WinNT/Win2k behave the same.
3278 Make sure you read the preceding section on platforms (<xref linkend="platforms"/>)
3279 before reading section.
3280 You don't need Cygwin or MSYS to <emphasis>use</emphasis> GHC,
3281 but you do need one or the other to <emphasis>build</emphasis> GHC.</para>
3284 <sect2 id="msys-install"><title>Installing and configuring MSYS</title>
3287 MSYS is a lightweight alternative to Cygwin.
3288 You don't need MSYS to <emphasis>use</emphasis> GHC,
3289 but you do need it or Cygwin to <emphasis>build</emphasis> GHC.
3290 Here's how to install MSYS.
3293 Go to <ulink url="http://www.mingw.org/download.shtml">http://www.mingw.org/download.shtml</ulink> and
3294 download the following (of course, the version numbers will differ):
3296 <listitem><para>The main MSYS package (binary is sufficient): <literal>MSYS-1.0.9.exe</literal>
3298 <listitem><para>The MSYS developer's toolkit (binary is sufficient): <literal>msysDTK-1.0.1.exe</literal>.
3299 This provides <command>make</command>, <command>autoconf</command>,
3300 <command>ssh</command> and probably more besides.
3303 Run both executables (in the order given above) to install them. I put them in <literal>c:/msys</literal>
3307 Set the following environment variables
3309 <listitem><para><literal>PATH</literal>: add <literal>c:/msys/1.0/bin</literal> and
3310 <literal>c:/msys/1.0/local/bin</literal>
3311 to your path. (Of course, the version number may differ.)
3312 MSYS mounts the former as both <literal>/bin</literal> and
3313 <literal>/usr/bin</literal> and the latter as <literal>/usr/local/bin</literal>.
3316 <listitem><para><literal>HOME</literal>: set to your home directory (e.g. <literal>c:/userid</literal>).
3317 This is where, among other things, <command>ssh</command> will look for your <literal>.ssh</literal> directory.
3320 <listitem><para><literal>SHELL</literal>: set to <literal>c:/msys/1.0/bin/sh.exe</literal>
3323 <listitem><para><literal>CVS_RSH</literal>: set to <literal>c:/msys/1.0/bin/ssh.exe</literal>. Only necessary if
3327 <listitem><para><literal>MAKE_MODE</literal>: set to <literal>UNIX</literal>. (I'm not certain this is necessary for MSYS.)
3334 Check that the <literal>CYGWIN</literal> environment variable is <emphasis>not</emphasis> set. It's a bad bug
3335 that MSYS is affected by this, but if you have CYGWIN set to "ntsec ntea", which is right for Cygwin, it
3336 causes the MSYS <command>ssh</command> to bogusly fail complaining that your <filename>.ssh/identity</filename>
3337 file has too-liberal permissinos.
3342 <para>Here are some points to bear in mind when using MSYS:
3344 <listitem> <para> MSYS does some kind of special magic to binaries stored in
3345 <filename>/bin</filename> and <filename>/usr/bin</filename>, which are by default both mapped
3346 to <filename>c:/msys/1.0/bin</filename> (assuming you installed MSYS in <filename>c:/msys</filename>).
3347 Do not put any other binaries (such as GHC or Alex) in this directory or its sub-directories:
3348 they fail in mysterious ways. However, it's fine to put other binaries in <filename>/usr/local/bin</filename>,
3349 which maps to <filename>c:/msys/1.0/local/bin</filename>.</para></listitem>
3351 <listitem> <para> MSYS seems to implement symbolic links by copying, so sharing is lost.
3355 Win32 has a <command>find</command> command which is not the same as MSYS's find.
3356 You will probably discover that the Win32 <command>find</command> appears in your <constant>PATH</constant>
3357 before the MSYS one, because it's in the <emphasis>system</emphasis> <constant>PATH</constant>
3358 environment variable, whereas you have probably modified the <emphasis>user</emphasis> <constant>PATH</constant>
3359 variable. You can always invoke <command>find</command> with an absolute path, or rename it.
3363 MSYS comes with <command>bzip</command>, and MSYS's <command>tar</command>'s <literal>-j</literal>
3364 will bunzip an archive (e.g. <literal>tar xvjf foo.tar.bz2</literal>). Useful when you get a
3365 bzip'd dump.</para></listitem>
3371 <sect2 id="install-cygwin"><title>Installing and configuring Cygwin</title>
3373 <para> Install Cygwin from <ulink url="http://www.cygwin.com/">http://www.cygwin.com/</ulink>.
3374 The installation process is straightforward; we install it in
3375 <filename>c:/cygwin</filename>.</para>
3377 You must install enough Cygwin <emphasis>packages</emphasis> to support
3378 building GHC. If you miss out any of these, strange things will happen to you. There are two ways to do this:
3380 <listitem><para>The direct, but laborious way is to
3381 select all of the following packages in the installation dialogue:
3382 <command>cvs</command>,
3383 <command>openssh</command>,
3384 <command>autoconf</command>,
3385 <command>binutils</command> (includes ld and (I think) ar),
3386 <command>gcc</command>,
3387 <command>flex</command>,
3388 <command>make</command>.
3389 To see thse packages,
3390 click on the "View" button in the "Select Packages"
3391 stage of Cygwin's installation dialogue, until the view says "Full". The default view, which is
3392 "Category" isn't very helpful, and the "View" button is rather unobtrousive.
3396 <listitem><para>The clever way is to point the Cygwin installer at the
3397 <command>ghc-depends</command> package, which is kept at <ulink
3398 url="http://haskell.org/ghc/cygwin">http://haskell.org/ghc/cygwin</ulink>.
3399 When the Cygwin installer asks you to "Choose a Download Site", choose one of
3401 offered mirror sites; and then type "http://haskell.org/ghc/cygwin" into the
3402 "User URL" box and click "Add"; now two sites are selected. (The Cygwin
3403 installer remembers this for next time.)
3404 Click "Next".</para>
3405 <para>In the "Select Packages" dialogue box that follows, click the "+" sign by
3406 "Devel", scroll down to the end of the "Devel" packages, and choose
3407 <command>ghc-depends</command>.
3408 The package <command>ghc-depends</command> will not actually install anything itself,
3409 but forces additional packages to be added by the Cygwin installer.
3415 <para> Now set the following user environment variables:
3418 <listitem><para> Add <filename>c:/cygwin/bin</filename> and <filename>c:/cygwin/usr/bin</filename> to your
3419 <constant>PATH</constant></para></listitem>
3423 Set <constant>MAKE_MODE</constant> to <literal>UNIX</literal>. If you
3424 don't do this you get very weird messages when you type
3425 <command>make</command>, such as:
3426 <screen>/c: /c: No such file or directory</screen>
3430 <listitem><para> Set <constant>SHELL</constant> to
3431 <filename>c:/cygwin/bin/bash</filename>. When you invoke a shell in Emacs, this
3432 <constant>SHELL</constant> is what you get.
3435 <listitem><para> Set <constant>HOME</constant> to point to your
3436 home directory. This is where, for example,
3437 <command>bash</command> will look for your <filename>.bashrc</filename>
3438 file. Ditto <command>emacs</command> looking for <filename>.emacsrc</filename>
3443 <para>Here are some things to be aware of when using Cygwin:
3445 <listitem> <para>Cygwin doesn't deal well with filenames that include
3446 spaces. "<filename>Program Files</filename>" and "<filename>Local files</filename>" are
3450 <listitem> <para> Cygwin implements a symbolic link as a text file with some
3451 magical text in it. So other programs that don't use Cygwin's
3452 I/O libraries won't recognise such files as symlinks.
3453 In particular, programs compiled by GHC are meant to be runnable
3454 without having Cygwin, so they don't use the Cygwin library, so
3455 they don't recognise symlinks.
3459 See the notes in <xref linkend="msys-install"/> about <command>find</command> and <command>bzip</command>,
3460 which apply to Cygwin too.
3465 Some script files used in the make system start with "<command>#!/bin/perl</command>",
3466 (and similarly for <command>sh</command>). Notice the hardwired path!
3467 So you need to ensure that your <filename>/bin</filename> directory has at least
3468 <command>sh</command>, <command>perl</command>, and <command>cat</command> in it.
3469 All these come in Cygwin's <filename>bin</filename> directory, which you probably have
3470 installed as <filename>c:/cygwin/bin</filename>. By default Cygwin mounts "<filename>/</filename>" as
3471 <filename>c:/cygwin</filename>, so if you just take the defaults it'll all work ok.
3472 (You can discover where your Cygwin
3473 root directory <filename>/</filename> is by typing <command>mount</command>.)
3474 Provided <filename>/bin</filename> points to the Cygwin <filename>bin</filename>
3475 directory, there's no need to copy anything. If not, copy these binaries from the <filename>cygwin/bin</filename>
3476 directory (after fixing the <filename>sh.exe</filename> stuff mentioned in the previous bullet).
3482 By default, cygwin provides the command shell <filename>ash</filename>
3483 as <filename>sh.exe</filename>. It seems to be fine now, but in the past we
3484 saw build-system problems that turned out to be due to bugs in <filename>ash</filename>
3485 (to do with quoting and length of command lines). On the other hand <filename>bash</filename> seems
3487 If this happens to you (which it shouldn't), in <filename>cygwin/bin</filename>
3488 remove the supplied <filename>sh.exe</filename> (or rename it as <filename>ash.exe</filename>),
3489 and copy <filename>bash.exe</filename> to <filename>sh.exe</filename>.
3490 You'll need to do this in Windows Explorer or the Windows <command>cmd</command> shell, because
3491 you can't rename a running program!
3500 <sect2 id="configure-ssh"><title>Configuring SSH</title>
3502 <para><command>ssh</command> comes with both Cygwin and MSYS.
3503 (Cygwin note: you need to ask for package <command>openssh</command> (not ssh)
3504 in the Cygwin list of packages; or use the <command>ghc-depends</command>
3505 package -- see <xref linkend="install-cygwin"/>.)</para>
3507 <para>There are several strange things about <command>ssh</command> on Windows that you need to know.
3511 The programs <command>ssh-keygen1</command>, <command>ssh1</command>, and <command>cvs</command>,
3512 seem to lock up <command>bash</command> entirely if they try to get user input (e.g. if
3513 they ask for a password). To solve this, start up <filename>cmd.exe</filename>
3514 and run it as follows:
3515 <screen>c:\tmp> set CYGWIN32=tty
3516 c:\tmp> c:/user/local/bin/ssh-keygen1</screen> </para>
3519 <listitem><para> (Cygwin-only problem, I think.)
3520 <command>ssh</command> needs to access your directory <filename>.ssh</filename>, in your home directory.
3521 To determine your home directory <command>ssh</command> first looks in
3522 <filename>c:/cygwin/etc/passwd</filename> (or wherever you have Cygwin installed). If there's an entry
3523 there with your userid, it'll use that entry to determine your home directory, <emphasis>ignoring
3524 the setting of the environment variable $HOME</emphasis>. If the home directory is
3525 bogus, <command>ssh</command> fails horribly. The best way to see what is going on is to say
3526 <screen>ssh -v cvs.haskell.org</screen>
3527 which makes <command>ssh</command> print out information about its activity.
3529 <para> You can fix this problem, either by correcting the home-directory field in
3530 <filename>c:/cygwin/etc/passwd</filename>, or by simply deleting the entire entry for your userid. If
3531 you do that, <command>ssh</command> uses the $HOME environment variable instead.
3537 <para>To protect your
3538 <literal>.ssh</literal> from access by anyone else,
3539 right-click your <literal>.ssh</literal> directory, and
3540 select <literal>Properties</literal>. If you are not on
3541 the access control list, add yourself, and give yourself
3542 full permissions (the second panel). Remove everyone else
3543 from the access control list. Don't leave them there but
3544 deny them access, because 'they' may be a list that
3545 includes you!</para>
3549 <para>In fact <command>ssh</command> 3.6.1 now seems to <emphasis>require</emphasis>
3550 you to have Unix permissions 600 (read/write for owner only)
3551 on the <literal>.ssh/identity</literal> file, else it
3552 bombs out. For your local C drive, it seems that <literal>chmod 600 identity</literal> works,
3553 but on Windows NT/XP, it doesn't work on a network drive (exact dteails obscure).
3554 The solution seems to be to set the $CYGWIN environment
3555 variable to "<literal>ntsec neta</literal>". The $CYGWIN environment variable is discussed
3556 in <ulink url="http://cygwin.com/cygwin-ug-net/using-cygwinenv.html">the Cygwin User's Guide</ulink>,
3557 and there are more details in <ulink url="http://cygwin.com/faq/faq_4.html#SEC44">the Cygwin FAQ</ulink>.
3564 <sect2><title>Other things you need to install</title>
3566 <para>You have to install the following other things to build GHC, listed below.</para>
3568 <para>On Windows you often install executables in directories with spaces, such as
3569 "<filename>Program Files</filename>". However, the <literal>make</literal> system doesn't
3570 deal with this situation (it'd have to do more quoting of binaries), so you are strongly advised
3571 to put binaries for all tools in places with no spaces in their path.
3572 On both MSYS and Cygwin, it's perfectly OK to install such programs in the standard Unixy places,
3573 <filename>/usr/local/bin</filename> and <filename>/usr/local/lib</filename>. But it doesn't matter,
3574 provided they are in your path.
3578 Install an executable GHC, from <ulink url="http://www.haskell.org/ghc">http://www.haskell.org/ghc</ulink>.
3579 This is what you will use to compile GHC. Add it in your
3580 <constant>PATH</constant>: the installer tells you the path element
3581 you need to add upon completion.
3587 Install an executable Happy, from <ulink url="http://www.haskell.org/happy">http://www.haskell.org/happy</ulink>.
3588 Happy is a parser generator used to compile the Haskell grammar. Under MSYS or Cygwin you can easily
3589 build it from the source distribution using
3590 <screen>$ ./configure
3592 $ make install</screen>
3593 This should install it in <filename>/usr/local/bin</filename> (which maps to <filename>c:/msys/1.0/local/bin</filename>
3595 Make sure the installation directory is in your
3596 <constant>PATH</constant>.
3601 <para>Install an executable Alex. This can be done by building from the
3602 source distribution in the same way as Happy. Sources are
3603 available from <ulink
3604 url="http://www.haskell.org/alex">http://www.haskell.org/alex</ulink>.</para>
3608 <para>GHC uses the <emphasis>mingw</emphasis> C compiler to
3609 generate code, so you have to install that (see <xref linkend="cygwin-and-mingw"/>).
3610 Just pick up a mingw bundle at
3611 <ulink url="http://www.mingw.org/">http://www.mingw.org/</ulink>.
3612 We install it in <filename>c:/mingw</filename>.
3615 <para><emphasis>On MSYS</emphasis>, add <literal>c:/mingw/bin</literal> to your PATH. MSYS does not provide <command>gcc</command>,
3616 <command>ld</command>, <command>ar</command>, and so on, because it just uses the MinGW ones. So you need them
3620 <para><emphasis>On Cygwin, do not</emphasis> add any of the <emphasis>mingw</emphasis> binaries to your path.
3621 They are only going to get used by explicit access (via the --with-gcc flag you
3622 give to <command>configure</command> later). If you do add them to your path
3623 you are likely to get into a mess because their names overlap with Cygwin
3625 On the other hand, you <emphasis>do</emphasis> need <command>ld</command>, <command>ar</command>
3626 (and perhaps one or two other things) in your path. The Cygwin ones are fine,
3627 but you must have them; hence needing the Cygwin binutils package.
3633 <para>We use <command>emacs</command> a lot, so we install that too.
3634 When you are in <filename>$(GHC_TOP)/compiler</filename>, you can use
3635 "<literal>make tags</literal>" to make a TAGS file for emacs. That uses the utility
3636 <filename>$(GHC_TOP)/ghc/utils/hasktags/hasktags</filename>, so you need to make that first.
3637 The most convenient way to do this is by going <literal>make boot</literal> in <filename>$(GHC_TOP)/ghc</filename>.
3638 The <literal>make tags</literal> command also uses <command>etags</command>, which comes with <command>emacs</command>,
3639 so you will need to add <filename>emacs/bin</filename> to your <literal>PATH</literal>.
3644 <para>You might want to install GLUT in your MSYS/Cygwin
3645 installation, otherwise the GLUT package will not be built with
3650 <para> Finally, check out a copy of GHC sources from
3651 the darcs repository, following the instructions at <ulink url="http://hackage.haskell.org/trac/ghc/wiki/GhcDarcs" />.</para>
3657 <sect2><title>Building GHC</title>
3660 Now go read the documentation above on building from source (<xref linkend="sec-building-from-source"/>);
3661 the bullets below only tell
3662 you about Windows-specific wrinkles.</para>
3666 If you used <command>autoconf</command> instead of <command>autoreconf</command>,
3667 you'll get an error when you run <filename>./configure</filename>:
3670 creating mk/config.h
3671 mk/config.h is unchanged
3673 running /bin/sh ./configure --cache-file=.././config.cache --srcdir=.
3674 ./configure: ./configure: No such file or directory
3675 configure: error: ./configure failed for ghc</screen>
3679 <listitem> <para><command>autoreconf</command> seems to create the file <filename>configure</filename>
3680 read-only. So if you need to run autoreconf again (which I sometimes do for safety's sake),
3682 <screen>/usr/bin/autoconf: cannot create configure: permission denied</screen>
3683 Solution: delete <filename>configure</filename> first.
3688 After <command>autoreconf</command> run <command>./configure</command> in
3689 <filename>$(GHC_TOP)/</filename> thus:
3691 <screen>$ ./configure --host=i386-unknown-mingw32 --with-gcc=c:/mingw/bin/gcc</screen>
3692 This is the point at which you specify that you are building GHC-mingw
3693 (see <xref linkend="ghc-mingw"/>). </para>
3695 <para> Both these options are important! It's possible to get into
3696 trouble using the wrong C compiler!</para>
3698 Furthermore, it's <emphasis>very important</emphasis> that you specify a
3699 full MinGW path for <command>gcc</command>, not a Cygwin path, because GHC (which
3700 uses this path to invoke <command>gcc</command>) is a MinGW program and won't
3701 understand a Cygwin path. For example, if you
3702 say <literal>--with-gcc=/mingw/bin/gcc</literal>, it'll be interpreted as
3703 <filename>/cygdrive/c/mingw/bin/gcc</filename>, and GHC will fail the first
3704 time it tries to invoke it. Worse, the failure comes with
3705 no error message whatsoever. GHC simply fails silently when first invoked,
3706 typically leaving you with this:
3707 <screen>make[4]: Leaving directory `/cygdrive/e/ghc-stage1/ghc/rts/gmp'
3708 ../../ghc/compiler/ghc-inplace -optc-mno-cygwin -optc-O
3709 -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes
3710 -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
3711 -optc-Wbad-function-cast -optc-Wcast-align -optc-I../includes
3712 -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS
3713 -optc-fomit-frame-pointer -O2 -static
3714 -package-name rts -O -dcore-lint -c Adjustor.c -o Adjustor.o
3715 make[2]: *** [Adjustor.o] Error 1
3716 make[1]: *** [all] Error 1
3717 make[1]: Leaving directory `/cygdrive/e/ghc-stage1/ghc'
3718 make: *** [all] Error 1</screen>
3723 If you want to build GHC-cygwin (<xref linkend="ghc-cygwin"/>)
3724 you'll have to do something more like:
3725 <screen>$ ./configure --with-gcc=...the Cygwin gcc...</screen>
3730 If you are paranoid, delete <filename>config.cache</filename> if it exists.
3731 This file occasionally remembers out-of-date configuration information, which
3732 can be really confusing.
3736 <listitem><para> You almost certainly want to set
3737 <programlisting>SplitObjs = NO</programlisting>
3738 in your <filename>build.mk</filename> configuration file (see <xref linkend="sec-build-config"/>).
3739 This tells the build system not to split each library into a myriad of little object files, one
3740 for each function. Doing so reduces binary sizes for statically-linked binaries, but on Windows
3741 it dramatically increases the time taken to build the libraries in the first place.
3745 <listitem><para> Do not attempt to build the documentation.
3746 It needs all kinds of wierd Jade stuff that we haven't worked out for
3747 Win32.</para></listitem>
3752 <sect2><title>A Windows build log using Cygwin</title>
3754 <para>Here is a complete, from-scratch, log of all you need to build GHC using
3755 Cygwin, kindly provided by Claus Reinke. It does not discuss alternative
3756 choices, but it gives a single path that works.</para>
3757 <programlisting>- Install some editor (vim, emacs, whatever)
3759 - Install cygwin (http://www.cygwin.com)
3760 ; i used 1.5.16-1, installed in c:\cygwin
3762 Choose a Download Source:
3763 select 'download from internet';
3764 Select Root Install Directory:
3765 root dir: c:\cygwin;
3766 install for: all users;
3767 default file type: unix
3768 Select Local Package Directory
3769 choose a spare temporary home
3770 Select Your Internet Connection
3772 Choose a Download Site
3773 Choose your preferred main mirror and
3774 Add 'http://www.haskell.org/ghc/cygwin'
3776 In addition to 'Base' (default install),
3777 select 'Devel->ghc-depends'
3779 - Install mingw (http://www.mingw.org/)
3780 ; i used MinGW-3.1.0-1.exe
3781 ; installed in c:\mingw
3782 - you probably want to add GLUT
3783 ; (http://www.xmission.com/~nate/glut.html)
3784 ; i used glut-3.7.3-mingw32.tar
3786 - Get recent binary snapshot of ghc-6.4.1 for mingw
3787 ; (http://www.haskell.org/ghc/dist/stable/dist/)
3789 - add C:\ghc\ghc-6.4.1\bin to %PATH%
3790 (Start->Control Panel->System->Advanced->Environment Variables)
3792 - Get darcs version of ghc
3793 ; also, subscribe to cvs-all@haskell.org, or follow the mailing list
3794 ; archive, in case you checkout a version with problems
3795 ; http://www.haskell.org//pipermail/cvs-all/
3796 - mkdir c:/ghc-build; cd c:/ghc-build
3797 ; (or whereever you want your darcs tree to be)
3798 - darcs get http://darcs.haskell.org/ghc
3800 - chmod +x darcs-all
3803 - Build ghc, using cygwin and mingw, targetting mingw
3804 - export PATH=/cygdrive/c/ghc/ghc-6.4.1:$PATH
3805 ; for haddock, alex, happy (*)
3806 - export PATH=/cygdrive/c/mingw/bin:$PATH
3807 ; without, we pick up some cygwin tools at best!
3809 ; (if you aren't there already)
3811 - ./configure --host=i386-unknown-mingw32 --with-gcc=C:/Mingw/bin/gcc.exe
3812 ; we use cygwin, but build for windows
3813 - cp mk/build.mk.sample mk/build.mk
3815 add line: SplitObjs = NO
3816 (MSYS seems slow when there are zillions of object files)
3817 uncomment line: BuildFlavour = perf
3818 (or BuildFlavour = devel, if you are doing development)
3819 add line: BIN_DIST=1
3820 - make 2>&1 | tee make.log
3821 ; always useful to have a log around
3823 - Package up binary distribution
3824 - make binary-dist Project=Ghc 2>&1 | tee make-bin-dist.log
3825 ; always useful to have a log around
3827 - chmod +x ../distrib/prep-bin-dist-mingw
3828 ; if you're happy with the script's contents (*)
3829 - ../distrib/prep-bin-dist-mingw
3830 ; then tar up, unpack where wanted, and enjoy</programlisting>
projects / ghc-hetmet.git / blob