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>$(FPTOOLS_TOP)</constant><indexterm><primary>FPTOOLS_TOP</primary></indexterm>.
508 In the rest of this document path names are relative to
509 <constant>$(FPTOOLS_TOP)</constant> unless
510 otherwise stated. For example, the file
511 <filename>mk/target.mk</filename> is actually
512 <filename>$(FPTOOLS_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>$(FPTOOLS_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>$(FPTOOLS_TOP)/configure.ac</filename> and
554 <filename>$(FPTOOLS_TOP)/aclocal.m4</filename>
555 to a shell script called
556 <filename>$(FPTOOLS_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>$(FPTOOLS_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>FPTOOLS_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>$(FPTOOLS_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>$(FPTOOLS_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 the
2183 <literal>fptools</literal> projects:</para>
2188 <indexterm><primary>pre-supposed: DocBook</primary></indexterm>
2189 <indexterm><primary>DocBook, pre-supposed</primary></indexterm>
2192 <para>Much of our documentation is written in DocBook XML, instructions
2193 on installing and configuring the DocBook tools are below.</para>
2199 <indexterm><primary>pre-supposed: TeX</primary></indexterm>
2200 <indexterm><primary>TeX, pre-supposed</primary></indexterm>
2203 <para>A decent TeX distribution is required if you want to
2204 produce printable documentation. We recomment teTeX,
2205 which includes just about everything you need.</para>
2211 <indexterm><primary>Haddock</primary></indexterm>
2214 <para>Haddock is a Haskell documentation tool that we use
2215 for automatically generating documentation from the
2216 library source code. It is an <literal>fptools</literal>
2217 project in itself. To build documentation for the
2218 libraries (<literal>fptools/libraries</literal>) you
2219 should check out and build Haddock in
2220 <literal>fptools/haddock</literal>. Haddock requires GHC
2228 <title>Installing the DocBook tools</title>
2231 <title>Installing the DocBook tools on Linux</title>
2233 <para>If you're on a recent RedHat (7.0+) or SuSE (8.1+) system,
2234 you probably have working DocBook tools already installed. The
2235 configure script should detect your setup and you're away.</para>
2237 <para>If you don't have DocBook tools installed, and you are
2238 using a system that can handle RPM packages, you can use <ulink
2239 url="http://rpmfind.net/">Rpmfind.net</ulink> to find suitable
2240 packages for your system. Search for the packages
2241 <literal>docbook-dtd</literal>,
2242 <literal>docbook-xsl-stylesheets</literal>,
2243 <literal>libxslt</literal>,
2244 <literal>libxml2</literal>,
2245 <literal>fop</literal>,
2246 <literal>xmltex</literal>, and
2247 <literal>dvips</literal>.</para>
2251 <title>Installing DocBook on FreeBSD</title>
2253 <para>On FreeBSD systems, the easiest way to get DocBook up
2254 and running is to install it from the ports tree or a
2255 pre-compiled package (packages are available from your local
2256 FreeBSD mirror site).</para>
2258 <para>To use the ports tree, do this:
2259 <screen>$ cd /usr/ports/textproc/docproj
2260 $ make install</screen>
2261 This installs the FreeBSD documentation project tools, which
2262 includes everything needed to format the GHC
2263 documentation.</para>
2267 <title>Installing from binaries on Windows</title>
2269 <para>Probably the fastest route to a working DocBook environment on
2270 Windows is to install <ulink url="http://www.cygwin.com/">Cygwin</ulink>
2271 with the complete <literal>Doc</literal> category. If you are using
2272 <ulink url="http://www.mingw.org/">MinGW</ulink> for compilation, you
2273 have to help <command>configure</command> a little bit: Set the
2274 environment variables <envar>XmllintCmd</envar> and
2275 <envar>XsltprocCmd</envar> to the paths of the Cygwin executables
2276 <command>xmllint</command> and <command>xsltproc</command>,
2277 respectively, and set <envar>fp_cv_dir_docbook_xsl</envar> to the path
2278 of the directory where the XSL stylesheets are installed,
2279 e.g. <filename>c:/cygwin/usr/share/docbook-xsl</filename>.
2282 <para>If you want to build HTML Help, you have to install the
2283 <ulink url="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/htmlhelp/html/hworiHTMLHelpStartPage.asp">HTML Help SDK</ulink>,
2284 too, and make sure that <command>hhc</command> is in your <envar>PATH</envar>.</para>
2290 <title>Configuring the DocBook tools</title>
2292 <para>Once the DocBook tools are installed, the configure script
2293 will detect them and set up the build system accordingly. If you
2294 have a system that isn't supported, let us know, and we'll try
2299 <title>Building the documentation</title>
2301 <para>To build documentation in a certain format, you can
2302 say, for example,</para>
2304 <screen>$ make html</screen>
2306 <para>to build HTML documentation below the current directory.
2307 The available formats are: <literal>dvi</literal>,
2308 <literal>ps</literal>, <literal>pdf</literal>,
2309 <literal>html</literal>, and <literal>rtf</literal>. Note that
2310 not all documentation can be built in all of these formats: HTML
2311 documentation is generally supported everywhere, and DocBook
2312 documentation might support the other formats (depending on what
2313 other tools you have installed).</para>
2315 <para>All of these targets are recursive; that is, saying
2316 <literal>make html</literal> will make HTML docs for all the
2317 documents recursively below the current directory.</para>
2319 <para>Because there are many different formats that the DocBook
2320 documentation can be generated in, you have to select which ones
2321 you want by setting the <literal>XMLDocWays</literal> variable
2322 to a list of them. For example, in
2323 <filename>build.mk</filename> you might have a line:</para>
2325 <screen>XMLDocWays = html ps</screen>
2327 <para>This will cause the documentation to be built in the requested
2328 formats as part of the main build (the default is not to build
2329 any documentation at all).</para>
2333 <title>Installing the documentation</title>
2335 <para>To install the documentation, use:</para>
2337 <screen>$ make install-docs</screen>
2339 <para>This will install the documentation into
2340 <literal>$(datadir)</literal> (which defaults to
2341 <literal>$(prefix)/share</literal>). The exception is HTML
2342 documentation, which goes into
2343 <literal>$(datadir)/html</literal>, to keep things tidy.</para>
2345 <para>Note that unless you set <literal>$(XMLDocWays)</literal>
2346 to a list of formats, the <literal>install-docs</literal> target
2347 won't do anything for DocBook XML documentation.</para>
2353 <sect1 id="sec-porting-ghc">
2354 <title>Porting GHC</title>
2356 <para>This section describes how to port GHC to a currenly
2357 unsupported platform. There are two distinct
2358 possibilities:</para>
2362 <para>The hardware architecture for your system is already
2363 supported by GHC, but you're running an OS that isn't
2364 supported (or perhaps has been supported in the past, but
2365 currently isn't). This is the easiest type of porting job,
2366 but it still requires some careful bootstrapping. Proceed to
2367 <xref linkend="sec-booting-from-hc"/>.</para>
2371 <para>Your system's hardware architecture isn't supported by
2372 GHC. This will be a more difficult port (though by comparison
2373 perhaps not as difficult as porting gcc). Proceed to <xref
2374 linkend="unregisterised-porting"/>.</para>
2378 <sect2 id="sec-booting-from-hc">
2379 <title>Booting/porting from C (<filename>.hc</filename>) files</title>
2381 <indexterm><primary>building GHC from .hc files</primary></indexterm>
2382 <indexterm><primary>booting GHC from .hc files</primary></indexterm>
2383 <indexterm><primary>porting GHC</primary></indexterm>
2385 <para>Bootstrapping GHC on a system without GHC already
2386 installed is achieved by taking the intermediate C files (known
2387 as HC files) from another GHC compilation, compiling them using gcc to
2388 get a working GHC.</para>
2390 <para><emphasis>NOTE: GHC versions 5.xx were hard to bootstrap
2391 from C. We recommend using GHC 6.0.1 or
2392 later.</emphasis></para>
2394 <para>HC files are platform-dependent, so you have to get a set
2395 that were generated on <emphasis>the same platform</emphasis>. There
2396 may be some supplied on the GHC download page, otherwise you'll have to
2397 compile some up yourself, or start from
2398 <emphasis>unregisterised</emphasis> HC files - see <xref
2399 linkend="unregisterised-porting"/>.</para>
2401 <para>The following steps should result in a working GHC build
2402 with full libraries:</para>
2406 <para>Unpack the HC files on top of a fresh source tree
2407 (make sure the source tree version matches the version of
2408 the HC files <emphasis>exactly</emphasis>!). This will
2409 place matching <filename>.hc</filename> files next to the
2410 corresponding Haskell source (<filename>.hs</filename> or
2411 <filename>.lhs</filename>) in the compiler subdirectory
2412 <filename>ghc/compiler</filename> and in the libraries
2414 <literal>libraries</literal>).</para>
2418 <para>The actual build process is fully automated by the
2419 <filename>hc-build</filename> script located in the
2420 <filename>distrib</filename> directory. If you eventually
2421 want to install GHC into the directory
2422 <replaceable>dir</replaceable>, the following
2423 command will execute the whole build process (it won't
2424 install yet):</para>
2426 <screen>$ distrib/hc-build --prefix=<replaceable>dir</replaceable></screen>
2427 <indexterm><primary>--hc-build</primary></indexterm>
2429 <para>By default, the installation directory is
2430 <filename>/usr/local</filename>. If that is what you want,
2431 you may omit the argument to <filename>hc-build</filename>.
2432 Generally, any option given to <filename>hc-build</filename>
2433 is passed through to the configuration script
2434 <filename>configure</filename>. If
2435 <filename>hc-build</filename> successfully completes the
2436 build process, you can install the resulting system, as
2439 <screen>$ make install</screen>
2444 <sect2 id="unregisterised-porting">
2445 <title>Porting GHC to a new architecture</title>
2447 <para>The first step in porting to a new architecture is to get
2448 an <firstterm>unregisterised</firstterm> build working. An
2449 unregisterised build is one that compiles via vanilla C only.
2450 By contrast, a registerised build uses the following
2451 architecture-specific hacks for speed:</para>
2455 <para>Global register variables: certain abstract machine
2456 <quote>registers</quote> are mapped to real machine
2457 registers, depending on how many machine registers are
2459 <filename>ghc/includes/MachRegs.h</filename>).</para>
2463 <para>Assembly-mangling: when compiling via C, we feed the
2464 assembly generated by gcc though a Perl script known as the
2465 <firstterm>mangler</firstterm> (see
2466 <filename>ghc/driver/mangler/ghc-asm.lprl</filename>). The
2467 mangler rearranges the assembly to support tail-calls and
2468 various other optimisations.</para>
2472 <para>In an unregisterised build, neither of these hacks are
2473 used — the idea is that the C code generated by the
2474 compiler should compile using gcc only. The lack of these
2475 optimisations costs about a factor of two in performance, but
2476 since unregisterised compilation is usually just a step on the
2477 way to a full registerised port, we don't mind too much.</para>
2479 <para>Notes on GHC portability in general: we've tried to stick
2480 to writing portable code in most parts of the system, so it
2481 should compile on any POSIXish system with gcc, but in our
2482 experience most systems differ from the standards in one way or
2483 another. Deal with any problems as they arise - if you get
2484 stuck, ask the experts on
2485 <email>glasgow-haskell-users@haskell.org</email>.</para>
2487 <para>Lots of useful information about the innards of GHC is
2488 available in the <ulink
2489 url="http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/">GHC
2490 Commentary</ulink>, which might be helpful if you run into some
2491 code which needs tweaking for your system.</para>
2494 <title>Cross-compiling to produce an unregisterised GHC</title>
2496 <para>NOTE! These instructions apply to GHC 6.4 and (hopefully)
2497 later. If you need instructions for an earlier version of GHC, try
2498 to get hold of the version of this document that was current at the
2499 time. It should be available from the appropriate download page on
2501 url="http://www.haskell.org/ghc/">GHC homepage</ulink>.</para>
2503 <para>In this section, we explain how to bootstrap GHC on a
2504 new platform, using unregisterised intermediate C files. We
2505 haven't put a great deal of effort into automating this
2506 process, for two reasons: it is done very rarely, and the
2507 process usually requires human intervention to cope with minor
2508 porting issues anyway.</para>
2510 <para>The following step-by-step instructions should result in
2511 a fully working, albeit unregisterised, GHC. Firstly, you
2512 need a machine that already has a working GHC (we'll call this
2513 the <firstterm>host</firstterm> machine), in order to
2514 cross-compile the intermediate C files that we will use to
2515 bootstrap the compiler on the <firstterm>target</firstterm>
2520 <para>On the target machine:</para>
2524 <para>Unpack a source tree (preferably a released
2525 version). We will call the path to the root of this
2526 tree <replaceable>T</replaceable>.</para>
2530 <screen>$ cd <replaceable>T</replaceable>
2531 $ ./configure --enable-hc-boot --enable-hc-boot-unregisterised</screen>
2533 <para>You might need to update
2534 <filename>configure.in</filename> to recognise the new
2535 architecture, and re-generate
2536 <filename>configure</filename> with
2537 <literal>autoreconf</literal>.</para>
2541 <screen>$ cd <replaceable>T</replaceable>/ghc/includes
2548 <para>On the host machine:</para>
2552 <para>Unpack a source tree (same released version). Call
2553 this directory <replaceable>H</replaceable>.</para>
2557 <screen>$ cd <replaceable>H</replaceable>
2558 $ ./configure</screen>
2563 <filename><replaceable>H</replaceable>/mk/build.mk</filename>,
2564 with the following contents:</para>
2566 <programlisting>GhcUnregisterised = YES
2567 GhcLibHcOpts = -O -fvia-C -keep-hc-files
2568 GhcRtsHcOpts = -keep-hc-files
2571 GhcWithNativeCodeGen = NO
2572 GhcWithInterpreter = NO
2573 GhcStage1HcOpts = -O
2574 GhcStage2HcOpts = -O -fvia-C -keep-hc-files
2575 SRC_HC_OPTS += -H32m
2576 GhcBootLibs = YES</programlisting>
2581 <filename><replaceable>H</replaceable>/mk/config.mk</filename>:</para>
2584 <para>change <literal>TARGETPLATFORM</literal>
2585 appropriately, and set the variables involving
2586 <literal>TARGET</literal> or
2587 <literal>Target</literal> to the correct values for
2588 the target platform. This step is necessary because
2589 currently <literal>configure</literal> doesn't cope
2590 with specifying different values for the
2591 <literal>--host</literal> and
2592 <literal>--target</literal> flags.</para>
2595 <para>copy <literal>LeadingUnderscore</literal>
2596 setting from target.</para>
2603 <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>
2605 <filename><replaceable>H</replaceable>/ghc/includes</filename>.
2606 Note that we are building on the host machine, using the
2607 target machine's configuration files. This
2608 is so that the intermediate C files generated here will
2609 be suitable for compiling on the target system.</para>
2613 <para>Touch the generated configuration files, just to make
2614 sure they don't get replaced during the build:</para>
2615 <screen>$ cd <filename><replaceable>H</replaceable></filename>/ghc/includes
2616 $ touch ghcautoconf.h DerivedConstants.h GHCConstants.h mkDerivedConstants.c
2617 $ touch mkDerivedConstantsHdr mkDerivedConstants.o mkGHCConstants mkGHCConstants.o</screen>
2619 <para>Note: it has been reported that these files still get
2620 overwritten during the next stage. We have installed a fix
2621 for this in GHC 6.4.2, but if you are building a version
2622 before that you need to watch out for these files getting
2623 overwritte by the <literal>Makefile</literal> in
2624 <literal>ghc/includes</literal>. If your system supports
2625 it, you might be able to prevent it by making them
2627 <screen>$ chflags uchg ghc/includes/{ghcautoconf.h,DerivedConstants.h,GHCConstants.h}</screen>
2631 <para>Now build the compiler:</para>
2632 <screen>$ cd <replaceable>H</replaceable>/glafp-utils && make boot && make
2633 $ cd <replaceable>H</replaceable>/ghc && make boot && make</screen>
2634 <para>Don't worry if the build falls over in the RTS, we
2635 don't need the RTS yet.</para>
2639 <screen>$ cd <replaceable>H</replaceable>/libraries
2640 $ make boot && make</screen>
2644 <screen>$ cd <replaceable>H</replaceable>/ghc/compiler
2645 $ make boot stage=2 && make stage=2</screen>
2649 <screen>$ cd <replaceable>H</replaceable>/compat
2652 $ make boot UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'
2653 $ cd <replaceable>H</replaceable>/ghc/utils
2655 $ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'</screen>
2659 <screen>$ cd <replaceable>H</replaceable>
2660 $ make hc-file-bundle Project=Ghc</screen>
2665 <filename><replaceable>H</replaceable>/*-hc.tar.gz</filename>
2666 to <filename><replaceable>T</replaceable>/..</filename>.</para>
2672 <para>On the target machine:</para>
2674 <para>At this stage we simply need to bootstrap a compiler
2675 from the intermediate C files we generated above. The
2676 process of bootstrapping from C files is automated by the
2677 script in <literal>distrib/hc-build</literal>, and is
2678 described in <xref linkend="sec-booting-from-hc"/>.</para>
2680 <screen>$ ./distrib/hc-build --enable-hc-boot-unregisterised</screen>
2682 <para>However, since this is a bootstrap on a new machine,
2683 the automated process might not run to completion the
2684 first time. For that reason, you might want to treat the
2685 <literal>hc-build</literal> script as a list of
2686 instructions to follow, rather than as a fully automated
2687 script. This way you'll be able to restart the process
2688 part-way through if you need to fix anything on the
2691 <para>Don't bother with running
2692 <literal>make install</literal> in the newly
2693 bootstrapped tree; just use the compiler in that tree to
2694 build a fresh compiler from scratch, this time without
2695 booting from C files. Before doing this, you might want
2696 to check that the bootstrapped compiler is generating
2697 working binaries:</para>
2699 <screen>$ cat >hello.hs
2700 main = putStrLn "Hello World!\n"
2702 $ <replaceable>T</replaceable>/ghc/compiler/ghc-inplace hello.hs -o hello
2704 Hello World!</screen>
2706 <para>Once you have the unregisterised compiler up and
2707 running, you can use it to start a registerised port. The
2708 following sections describe the various parts of the
2709 system that will need architecture-specific tweaks in
2710 order to get a registerised build going.</para>
2717 <title>Porting the RTS</title>
2719 <para>The following files need architecture-specific code for a
2720 registerised build:</para>
2724 <term><filename>ghc/includes/MachRegs.h</filename>
2725 <indexterm><primary><filename>MachRegs.h</filename></primary></indexterm>
2728 <para>Defines the STG-register to machine-register
2729 mapping. You need to know your platform's C calling
2730 convention, and which registers are generally available
2731 for mapping to global register variables. There are
2732 plenty of useful comments in this file.</para>
2736 <term><filename>ghc/includes/TailCalls.h</filename>
2737 <indexterm><primary><filename>TailCalls.h</filename></primary></indexterm>
2740 <para>Macros that cooperate with the mangler (see <xref
2741 linkend="sec-mangler"/>) to make proper tail-calls
2746 <term><filename>ghc/rts/Adjustor.c</filename>
2747 <indexterm><primary><filename>Adjustor.c</filename></primary></indexterm>
2751 <literal>foreign import "wrapper"</literal>
2753 <literal>foreign export dynamic</literal>).
2754 Not essential for getting GHC bootstrapped, so this file
2755 can be deferred until later if necessary.</para>
2759 <term><filename>ghc/rts/StgCRun.c</filename>
2760 <indexterm><primary><filename>StgCRun.c</filename></primary></indexterm>
2763 <para>The little assembly layer between the C world and
2764 the Haskell world. See the comments and code for the
2765 other architectures in this file for pointers.</para>
2769 <term><filename>ghc/rts/MBlock.h</filename>
2770 <indexterm><primary><filename>MBlock.h</filename></primary></indexterm>
2772 <term><filename>ghc/rts/MBlock.c</filename>
2773 <indexterm><primary><filename>MBlock.c</filename></primary></indexterm>
2776 <para>These files are really OS-specific rather than
2777 architecture-specific. In <filename>MBlock.h</filename>
2778 is specified the absolute location at which the RTS
2779 should try to allocate memory on your platform (try to
2780 find an area which doesn't conflict with code or dynamic
2781 libraries). In <filename>Mblock.c</filename> you might
2782 need to tweak the call to <literal>mmap()</literal> for
2789 <sect3 id="sec-mangler">
2790 <title>The mangler</title>
2792 <para>The mangler is an evil Perl-script
2793 (<filename>ghc/driver/mangler/ghc-asm.lprl</filename>) that
2794 rearranges the assembly code output from gcc to do two main
2799 <para>Remove function prologues and epilogues, and all
2800 movement of the C stack pointer. This is to support
2801 tail-calls: every code block in Haskell code ends in an
2802 explicit jump, so we don't want the C-stack overflowing
2803 while we're jumping around between code blocks.</para>
2806 <para>Move the <firstterm>info table</firstterm> for a
2807 closure next to the entry code for that closure. In
2808 unregisterised code, info tables contain a pointer to the
2809 entry code, but in registerised compilation we arrange
2810 that the info table is shoved right up against the entry
2811 code, and addressed backwards from the entry code pointer
2812 (this saves a word in the info table and an extra
2813 indirection when jumping to the closure entry
2818 <para>The mangler is abstracted to a certain extent over some
2819 architecture-specific things such as the particular assembler
2820 directives used to herald symbols. Take a look at the
2821 definitions for other architectures and use these as a
2822 starting point.</para>
2826 <title>The splitter</title>
2828 <para>The splitter is another evil Perl script
2829 (<filename>ghc/driver/split/ghc-split.lprl</filename>). It
2830 cooperates with the mangler to support object splitting.
2831 Object splitting is what happens when the
2832 <option>-split-objs</option> option is passed to GHC: the
2833 object file is split into many smaller objects. This feature
2834 is used when building libraries, so that a program statically
2835 linked against the library will pull in less of the
2838 <para>The splitter has some platform-specific stuff; take a
2839 look and tweak it for your system.</para>
2843 <title>The native code generator</title>
2845 <para>The native code generator isn't essential to getting a
2846 registerised build going, but it's a desirable thing to have
2847 because it can cut compilation times in half. The native code
2848 generator is described in some detail in the <ulink
2849 url="http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/">GHC
2850 commentary</ulink>.</para>
2856 <para>To support GHCi, you need to port the dynamic linker
2857 (<filename>fptools/ghc/rts/Linker.c</filename>). The linker
2858 currently supports the ELF and PEi386 object file formats - if
2859 your platform uses one of these then things will be
2860 significantly easier. The majority of Unix platforms use the
2861 ELF format these days. Even so, there are some
2862 machine-specific parts of the ELF linker: for example, the
2863 code for resolving particular relocation types is
2864 machine-specific, so some porting of this code to your
2865 architecture will probaly be necessary.</para>
2867 <para>If your system uses a different object file format, then
2868 you have to write a linker — good luck!</para>
2874 <sect1 id="sec-build-pitfalls">
2875 <title>Known pitfalls in building Glasgow Haskell
2877 <indexterm><primary>problems, building</primary></indexterm>
2878 <indexterm><primary>pitfalls, in building</primary></indexterm>
2879 <indexterm><primary>building pitfalls</primary></indexterm></title>
2882 WARNINGS about pitfalls and known “problems”:
2891 One difficulty that comes up from time to time is running out of space
2892 in <literal>TMPDIR</literal>. (It is impossible for the configuration stuff to
2893 compensate for the vagaries of different sysadmin approaches to temp
2895 <indexterm><primary>tmp, running out of space in</primary></indexterm>
2897 The quickest way around it is <command>setenv TMPDIR /usr/tmp</command><indexterm><primary>TMPDIR</primary></indexterm> or
2898 even <command>setenv TMPDIR .</command> (or the equivalent incantation with your shell
2901 The best way around it is to say
2903 <programlisting>export TMPDIR=<dir></programlisting>
2905 in your <filename>build.mk</filename> file.
2906 Then GHC and the other <literal>fptools</literal> programs will use the appropriate directory
2915 In compiling some support-code bits, e.g., in <filename>ghc/rts/gmp</filename> and even
2916 in <filename>ghc/lib</filename>, you may get a few C-compiler warnings. We think these
2924 When compiling via C, you'll sometimes get “warning: assignment from
2925 incompatible pointer type” out of GCC. Harmless.
2932 Similarly, <command>ar</command>chiving warning messages like the following are not
2935 <screen>ar: filename GlaIOMonad__1_2s.o truncated to GlaIOMonad_
2936 ar: filename GlaIOMonad__2_2s.o truncated to GlaIOMonad_
2945 In compiling the compiler proper (in <filename>compiler/</filename>), you <emphasis>may</emphasis>
2946 get an “Out of heap space” error message. These can vary with the
2947 vagaries of different systems, it seems. The solution is simple:
2954 If you're compiling with GHC 4.00 or later, then the
2955 <emphasis>maximum</emphasis> heap size must have been reached. This
2956 is somewhat unlikely, since the maximum is set to 64M by default.
2957 Anyway, you can raise it with the
2958 <option>-optCrts-M<size></option> flag (add this flag to
2959 <constant><module>_HC_OPTS</constant>
2960 <command>make</command> variable in the appropriate
2961 <filename>Makefile</filename>).
2968 For GHC < 4.00, add a suitable <option>-H</option> flag to the <filename>Makefile</filename>, as
2977 and try again: <command>make</command>. (see <xref linkend="sec-suffix"/> for information about
2978 <constant><module>_HC_OPTS</constant>.)
2980 Alternatively, just cut to the chase:
2982 <screen>$ cd ghc/compiler
2983 $ make EXTRA_HC_OPTS=-optCrts-M128M</screen>
2991 If you try to compile some Haskell, and you get errors from GCC about
2992 lots of things from <filename>/usr/include/math.h</filename>, then your GCC was
2993 mis-installed. <command>fixincludes</command> wasn't run when it should've been.
2995 As <command>fixincludes</command> is now automagically run as part of GCC installation,
2996 this bug also suggests that you have an old GCC.
3004 You <emphasis>may</emphasis> need to re-<command>ranlib</command><indexterm><primary>ranlib</primary></indexterm> your libraries (on Sun4s).
3007 <screen>$ cd $(libdir)/ghc-x.xx/sparc-sun-sunos4
3008 $ foreach i ( `find . -name '*.a' -print` ) # or other-shell equiv...
3010 ? # or, on some machines: ar s $i
3014 We'd be interested to know if this is still necessary.
3022 GHC's sources go through <command>cpp</command> before being compiled, and <command>cpp</command> varies
3023 a bit from one Unix to another. One particular gotcha is macro calls
3027 <programlisting>SLIT("Hello, world")</programlisting>
3030 Some <command>cpp</command>s treat the comma inside the string as separating two macro
3031 arguments, so you get
3034 <screen>:731: macro `SLIT' used with too many (2) args</screen>
3037 Alas, <command>cpp</command> doesn't tell you the offending file!
3039 Workaround: don't put weird things in string args to <command>cpp</command> macros.
3050 <sect1 id="platforms"><title>Platforms, scripts, and file names</title>
3052 GHC is designed both to be built, and to run, on both Unix and Windows. This flexibility
3053 gives rise to a good deal of brain-bending detail, which we have tried to collect in this chapter.
3056 <sect2 id="cygwin-and-mingw"><title>Windows platforms: Cygwin, MSYS, and MinGW</title>
3058 <para> The build system is built around Unix-y makefiles. Because it's not native,
3059 the Windows situation for building GHC is particularly confusing. This section
3060 tries to clarify, and to establish terminology.</para>
3062 <sect3 id="ghc-mingw"><title>MinGW</title>
3064 <para> <ulink url="http://www.mingw.org">MinGW (Minimalist GNU for Windows)</ulink>
3065 is a collection of header
3066 files and import libraries that allow one to use <command>gcc</command> and produce
3067 native Win32 programs that do not rely on any third-party DLLs. The
3068 current set of tools include GNU Compiler Collection (<command>gcc</command>), GNU Binary
3069 Utilities (Binutils), GNU debugger (Gdb), GNU make, and a assorted
3073 <para> The down-side of MinGW is that the MinGW libraries do not support anything like the full
3078 <sect3 id="ghc-cygwin"><title>Cygwin and MSYS</title>
3080 <para>You can't use the MinGW to <emphasis>build</emphasis> GHC, because MinGW doesn't have a shell,
3081 or the standard Unix commands such as <command>mv</command>, <command>rm</command>,
3082 <command>ls</command>, nor build-system stuff such as <command>make</command> and <command>darcs</command>.
3083 For that, there are two choices: <ulink url="http://www.cygwin.com">Cygwin</ulink>
3084 and <ulink url="http://www.mingw.org/msys.shtml">MSYS</ulink>:
3088 Cygwin comes with compilation tools (<command>gcc</command>, <command>ld</command> and so on), which
3089 compile code that has access to all of Posix. The price is that the executables must be
3090 dynamically linked with the Cygwin DLL, so that <emphasis>you cannot run a Cywin-compiled program on a machine
3091 that doesn't have Cygwin</emphasis>. Worse, Cygwin is a moving target. The name of the main DLL, <literal>cygwin1.dll</literal>
3092 does not change, but the implementation certainly does. Even the interfaces to functions
3093 it exports seem to change occasionally. </para>
3097 MSYS is a fork of the Cygwin tree, so they
3098 are fundamentally similar. However, MSYS is by design much smaller and simpler. Access to the file system goes
3099 through fewer layers, so MSYS is quite a bit faster too.
3102 <para>Furthermore, MSYS provides no compilation tools; it relies instead on the MinGW tools. These
3103 compile binaries that run with no DLL support, on any Win32 system.
3104 However, MSYS does come with all the make-system tools, such as <command>make</command>, <command>autoconf</command>,
3105 <command>darcs</command>, <command>ssh</command> etc. To get these, you have to download the
3106 MsysDTK (Developer Tool Kit) package, as well as the base MSYS package.
3108 <para>MSYS does have a DLL, but it's only used by MSYS commands (<command>sh</command>, <command>rm</command>,
3109 <command>ssh</command> and so on),
3110 not by programs compiled under MSYS.
3118 <sect3><title>Targeting MinGW</title>
3120 <para>We want GHC to compile programs that work on any Win32 system. Hence:
3123 GHC does invoke a C compiler, assembler, linker and so on, but we ensure that it only
3124 invokes the MinGW tools, not the Cygwin ones. That means that the programs GHC compiles
3125 will work on any system, but it also means that the programs GHC compiles do not have access
3126 to all of Posix. In particular, they cannot import the (Haskell) Posix
3127 library; they have to do
3128 their input output using standard Haskell I/O libraries, or native Win32 bindings.</para>
3129 <para> We will call a GHC that targets MinGW in this way <emphasis>GHC-mingw</emphasis>.</para>
3133 To make the GHC distribution self-contained, the GHC distribution includes the MinGW <command>gcc</command>,
3134 <command>as</command>, <command>ld</command>, and a bunch of input/output libraries.
3137 So <emphasis>GHC targets MinGW</emphasis>, not Cygwin.
3138 It is in principle possible to build a version of GHC, <emphasis>GHC-cygwin</emphasis>,
3139 that targets Cygwin instead. The up-side of GHC-cygwin is
3140 that Haskell programs compiled by GHC-cygwin can import the (Haskell) Posix library.
3141 <emphasis>We do not support GHC-cygwin, however; it is beyond our resources.</emphasis>
3144 <para>While GHC <emphasis>targets</emphasis> MinGW, that says nothing about
3145 how GHC is <emphasis>built</emphasis>. We use both MSYS and Cygwin as build environments for
3146 GHC; both work fine, though MSYS is rather lighter weight.</para>
3148 <para>In your build tree, you build a compiler called <command>ghc-inplace</command>. It
3149 uses the <command>gcc</command> that you specify using the
3150 <option>--with-gcc</option> flag when you run
3151 <command>configure</command> (see below).
3152 The makefiles are careful to use <command>ghc-inplace</command> (not <command>gcc</command>)
3153 to compile any C files, so that it will in turn invoke the correct <command>gcc</command> rather that
3154 whatever one happens to be in your path. However, the makefiles do use whatever <command>ld</command>
3155 and <command>ar</command> happen to be in your path. This is a bit naughty, but (a) they are only
3156 used to glom together .o files into a bigger .o file, or a .a file,
3157 so they don't ever get libraries (which would be bogus; they might be the wrong libraries), and (b)
3158 Cygwin and MinGW use the same .o file format. So its ok.
3162 <sect3><title> File names </title>
3164 <para>Cygwin, MSYS, and the underlying Windows file system all understand file paths of form <literal>c:/tmp/foo</literal>.
3168 MSYS programs understand <filename>/bin</filename>, <filename>/usr/bin</filename>, and map Windows's lettered drives as
3169 <filename>/c/tmp/foo</filename> etc. The exact mount table is given in the doc subdirectory of the MSYS distribution.
3171 <para> When it invokes a command, the MSYS shell sees whether the invoked binary lives in the MSYS <filename>/bin</filename>
3172 directory. If so, it just invokes it. If not, it assumes the program is no an MSYS program, and walks over the command-line
3173 arguments changing MSYS paths into native-compatible paths. It does this inside sub-arguments and inside quotes. For example,
3175 <programlisting>foogle -B/c/tmp/baz</programlisting>
3176 the MSYS shell will actually call <literal>foogle</literal> with argument <literal>-Bc:/tmp/baz</literal>.
3180 Cygwin programs have a more complicated mount table, and map the lettered drives as <filename>/cygdrive/c/tmp/foo</filename>.
3182 <para>The Cygwin shell does no argument processing when invoking non-Cygwin programs.
3188 <sect3><title>Crippled <command>ld</command></title>
3191 It turns out that on both Cygwin and MSYS, the <command>ld</command> has a
3192 limit of 32kbytes on its command line. Especially when using split object
3193 files, the make system can emit calls to <command>ld</command> with thousands
3194 of files on it. Then you may see something like this:
3196 (cd Graphics/Rendering/OpenGL/GL/QueryUtils_split && /mingw/bin/ld -r -x -o ../QueryUtils.o *.o)
3197 /bin/sh: /mingw/bin/ld: Invalid argument
3199 The solution is either to switch off object file splitting (set
3200 <option>SplitObjs</option> to <literal>NO</literal> in your
3201 <filename>build.mk</filename>),
3202 or to make the module smaller.
3206 <sect3><title>Host System vs Target System</title>
3209 In the source code you'll find various ifdefs looking like:
3210 <programlisting>#ifdef mingw32_HOST_OS
3212 #endif</programlisting>
3214 <programlisting>#ifdef mingw32_TARGET_OS
3216 #endif</programlisting>
3217 These macros are set by the configure script (via the file config.h).
3218 Which is which? The criterion is this. In the ifdefs in GHC's source code:
3221 <para>The "host" system is the one on which GHC itself will be run.</para>
3224 <para>The "target" system is the one for which the program compiled by GHC will be run.</para>
3227 For a stage-2 compiler, in which GHCi is available, the "host" and "target" systems must be the same.
3228 So then it doesn't really matter whether you use the HOST_OS or TARGET_OS cpp macros.
3235 <sect2><title>Wrapper scripts</title>
3238 Many programs, including GHC itself and hsc2hs, need to find associated binaries and libraries.
3239 For <emphasis>installed</emphasis> programs, the strategy depends on the platform. We'll use
3240 GHC itself as an example:
3243 On Unix, the command <command>ghc</command> is a shell script, generated by adding installation
3244 paths to the front of the source file <filename>ghc.sh</filename>,
3245 that invokes the real binary, passing "-B<emphasis>path</emphasis>" as an argument to tell <command>ghc</command>
3246 where to find its supporting files.
3250 On vanilla Windows, it turns out to be much harder to make reliable script to be run by the
3251 native Windows shell <command>cmd</command> (e.g. limits on the length
3252 of the command line). So instead we invoke the GHC binary directly, with no -B flag.
3253 GHC uses the Windows <literal>getExecDir</literal> function to find where the executable is,
3254 and from that figures out where the supporting files are.
3257 (You can find the layout of GHC's supporting files in the
3258 section "Layout of installed files" of Section 2 of the GHC user guide.)
3261 Things work differently for <emphasis>in-place</emphasis> execution, where you want to
3262 execute a program that has just been built in a build tree. The difference is that the
3263 layout of the supporting files is different.
3264 In this case, whether on Windows or Unix, we always use a shell script. This works OK
3265 on Windows because the script is executed by MSYS or Cygwin, which don't have the
3266 shortcomings of the native Windows <command>cmd</command> shell.
3273 <sect1 id="winbuild"><title>Instructions for building under Windows</title>
3276 This section gives detailed instructions for how to build
3277 GHC from source on your Windows machine. Similar instructions for
3278 installing and running GHC may be found in the user guide. In general,
3279 Win95/Win98 behave the same, and WinNT/Win2k behave the same.
3282 Make sure you read the preceding section on platforms (<xref linkend="platforms"/>)
3283 before reading section.
3284 You don't need Cygwin or MSYS to <emphasis>use</emphasis> GHC,
3285 but you do need one or the other to <emphasis>build</emphasis> GHC.</para>
3288 <sect2 id="msys-install"><title>Installing and configuring MSYS</title>
3291 MSYS is a lightweight alternative to Cygwin.
3292 You don't need MSYS to <emphasis>use</emphasis> GHC,
3293 but you do need it or Cygwin to <emphasis>build</emphasis> GHC.
3294 Here's how to install MSYS.
3297 Go to <ulink url="http://www.mingw.org/download.shtml">http://www.mingw.org/download.shtml</ulink> and
3298 download the following (of course, the version numbers will differ):
3300 <listitem><para>The main MSYS package (binary is sufficient): <literal>MSYS-1.0.9.exe</literal>
3302 <listitem><para>The MSYS developer's toolkit (binary is sufficient): <literal>msysDTK-1.0.1.exe</literal>.
3303 This provides <command>make</command>, <command>autoconf</command>,
3304 <command>ssh</command> and probably more besides.
3307 Run both executables (in the order given above) to install them. I put them in <literal>c:/msys</literal>
3311 Set the following environment variables
3313 <listitem><para><literal>PATH</literal>: add <literal>c:/msys/1.0/bin</literal> and
3314 <literal>c:/msys/1.0/local/bin</literal>
3315 to your path. (Of course, the version number may differ.)
3316 MSYS mounts the former as both <literal>/bin</literal> and
3317 <literal>/usr/bin</literal> and the latter as <literal>/usr/local/bin</literal>.
3320 <listitem><para><literal>HOME</literal>: set to your home directory (e.g. <literal>c:/userid</literal>).
3321 This is where, among other things, <command>ssh</command> will look for your <literal>.ssh</literal> directory.
3324 <listitem><para><literal>SHELL</literal>: set to <literal>c:/msys/1.0/bin/sh.exe</literal>
3327 <listitem><para><literal>CVS_RSH</literal>: set to <literal>c:/msys/1.0/bin/ssh.exe</literal>. Only necessary if
3331 <listitem><para><literal>MAKE_MODE</literal>: set to <literal>UNIX</literal>. (I'm not certain this is necessary for MSYS.)
3338 Check that the <literal>CYGWIN</literal> environment variable is <emphasis>not</emphasis> set. It's a bad bug
3339 that MSYS is affected by this, but if you have CYGWIN set to "ntsec ntea", which is right for Cygwin, it
3340 causes the MSYS <command>ssh</command> to bogusly fail complaining that your <filename>.ssh/identity</filename>
3341 file has too-liberal permissinos.
3346 <para>Here are some points to bear in mind when using MSYS:
3348 <listitem> <para> MSYS does some kind of special magic to binaries stored in
3349 <filename>/bin</filename> and <filename>/usr/bin</filename>, which are by default both mapped
3350 to <filename>c:/msys/1.0/bin</filename> (assuming you installed MSYS in <filename>c:/msys</filename>).
3351 Do not put any other binaries (such as GHC or Alex) in this directory or its sub-directories:
3352 they fail in mysterious ways. However, it's fine to put other binaries in <filename>/usr/local/bin</filename>,
3353 which maps to <filename>c:/msys/1.0/local/bin</filename>.</para></listitem>
3355 <listitem> <para> MSYS seems to implement symbolic links by copying, so sharing is lost.
3359 Win32 has a <command>find</command> command which is not the same as MSYS's find.
3360 You will probably discover that the Win32 <command>find</command> appears in your <constant>PATH</constant>
3361 before the MSYS one, because it's in the <emphasis>system</emphasis> <constant>PATH</constant>
3362 environment variable, whereas you have probably modified the <emphasis>user</emphasis> <constant>PATH</constant>
3363 variable. You can always invoke <command>find</command> with an absolute path, or rename it.
3367 MSYS comes with <command>bzip</command>, and MSYS's <command>tar</command>'s <literal>-j</literal>
3368 will bunzip an archive (e.g. <literal>tar xvjf foo.tar.bz2</literal>). Useful when you get a
3369 bzip'd dump.</para></listitem>
3375 <sect2 id="install-cygwin"><title>Installing and configuring Cygwin</title>
3377 <para> Install Cygwin from <ulink url="http://www.cygwin.com/">http://www.cygwin.com/</ulink>.
3378 The installation process is straightforward; we install it in
3379 <filename>c:/cygwin</filename>.</para>
3381 You must install enough Cygwin <emphasis>packages</emphasis> to support
3382 building GHC. If you miss out any of these, strange things will happen to you. There are two ways to do this:
3384 <listitem><para>The direct, but laborious way is to
3385 select all of the following packages in the installation dialogue:
3386 <command>cvs</command>,
3387 <command>openssh</command>,
3388 <command>autoconf</command>,
3389 <command>binutils</command> (includes ld and (I think) ar),
3390 <command>gcc</command>,
3391 <command>flex</command>,
3392 <command>make</command>.
3393 To see thse packages,
3394 click on the "View" button in the "Select Packages"
3395 stage of Cygwin's installation dialogue, until the view says "Full". The default view, which is
3396 "Category" isn't very helpful, and the "View" button is rather unobtrousive.
3400 <listitem><para>The clever way is to point the Cygwin installer at the
3401 <command>ghc-depends</command> package, which is kept at <ulink
3402 url="http://haskell.org/ghc/cygwin">http://haskell.org/ghc/cygwin</ulink>.
3403 When the Cygwin installer asks you to "Choose a Download Site", choose one of
3405 offered mirror sites; and then type "http://haskell.org/ghc/cygwin" into the
3406 "User URL" box and click "Add"; now two sites are selected. (The Cygwin
3407 installer remembers this for next time.)
3408 Click "Next".</para>
3409 <para>In the "Select Packages" dialogue box that follows, click the "+" sign by
3410 "Devel", scroll down to the end of the "Devel" packages, and choose
3411 <command>ghc-depends</command>.
3412 The package <command>ghc-depends</command> will not actually install anything itself,
3413 but forces additional packages to be added by the Cygwin installer.
3419 <para> Now set the following user environment variables:
3422 <listitem><para> Add <filename>c:/cygwin/bin</filename> and <filename>c:/cygwin/usr/bin</filename> to your
3423 <constant>PATH</constant></para></listitem>
3427 Set <constant>MAKE_MODE</constant> to <literal>UNIX</literal>. If you
3428 don't do this you get very weird messages when you type
3429 <command>make</command>, such as:
3430 <screen>/c: /c: No such file or directory</screen>
3434 <listitem><para> Set <constant>SHELL</constant> to
3435 <filename>c:/cygwin/bin/bash</filename>. When you invoke a shell in Emacs, this
3436 <constant>SHELL</constant> is what you get.
3439 <listitem><para> Set <constant>HOME</constant> to point to your
3440 home directory. This is where, for example,
3441 <command>bash</command> will look for your <filename>.bashrc</filename>
3442 file. Ditto <command>emacs</command> looking for <filename>.emacsrc</filename>
3447 <para>Here are some things to be aware of when using Cygwin:
3449 <listitem> <para>Cygwin doesn't deal well with filenames that include
3450 spaces. "<filename>Program Files</filename>" and "<filename>Local files</filename>" are
3454 <listitem> <para> Cygwin implements a symbolic link as a text file with some
3455 magical text in it. So other programs that don't use Cygwin's
3456 I/O libraries won't recognise such files as symlinks.
3457 In particular, programs compiled by GHC are meant to be runnable
3458 without having Cygwin, so they don't use the Cygwin library, so
3459 they don't recognise symlinks.
3463 See the notes in <xref linkend="msys-install"/> about <command>find</command> and <command>bzip</command>,
3464 which apply to Cygwin too.
3469 Some script files used in the make system start with "<command>#!/bin/perl</command>",
3470 (and similarly for <command>sh</command>). Notice the hardwired path!
3471 So you need to ensure that your <filename>/bin</filename> directory has at least
3472 <command>sh</command>, <command>perl</command>, and <command>cat</command> in it.
3473 All these come in Cygwin's <filename>bin</filename> directory, which you probably have
3474 installed as <filename>c:/cygwin/bin</filename>. By default Cygwin mounts "<filename>/</filename>" as
3475 <filename>c:/cygwin</filename>, so if you just take the defaults it'll all work ok.
3476 (You can discover where your Cygwin
3477 root directory <filename>/</filename> is by typing <command>mount</command>.)
3478 Provided <filename>/bin</filename> points to the Cygwin <filename>bin</filename>
3479 directory, there's no need to copy anything. If not, copy these binaries from the <filename>cygwin/bin</filename>
3480 directory (after fixing the <filename>sh.exe</filename> stuff mentioned in the previous bullet).
3486 By default, cygwin provides the command shell <filename>ash</filename>
3487 as <filename>sh.exe</filename>. It seems to be fine now, but in the past we
3488 saw build-system problems that turned out to be due to bugs in <filename>ash</filename>
3489 (to do with quoting and length of command lines). On the other hand <filename>bash</filename> seems
3491 If this happens to you (which it shouldn't), in <filename>cygwin/bin</filename>
3492 remove the supplied <filename>sh.exe</filename> (or rename it as <filename>ash.exe</filename>),
3493 and copy <filename>bash.exe</filename> to <filename>sh.exe</filename>.
3494 You'll need to do this in Windows Explorer or the Windows <command>cmd</command> shell, because
3495 you can't rename a running program!
3504 <sect2 id="configure-ssh"><title>Configuring SSH</title>
3506 <para><command>ssh</command> comes with both Cygwin and MSYS.
3507 (Cygwin note: you need to ask for package <command>openssh</command> (not ssh)
3508 in the Cygwin list of packages; or use the <command>ghc-depends</command>
3509 package -- see <xref linkend="install-cygwin"/>.)</para>
3511 <para>There are several strange things about <command>ssh</command> on Windows that you need to know.
3515 The programs <command>ssh-keygen1</command>, <command>ssh1</command>, and <command>cvs</command>,
3516 seem to lock up <command>bash</command> entirely if they try to get user input (e.g. if
3517 they ask for a password). To solve this, start up <filename>cmd.exe</filename>
3518 and run it as follows:
3519 <screen>c:\tmp> set CYGWIN32=tty
3520 c:\tmp> c:/user/local/bin/ssh-keygen1</screen> </para>
3523 <listitem><para> (Cygwin-only problem, I think.)
3524 <command>ssh</command> needs to access your directory <filename>.ssh</filename>, in your home directory.
3525 To determine your home directory <command>ssh</command> first looks in
3526 <filename>c:/cygwin/etc/passwd</filename> (or wherever you have Cygwin installed). If there's an entry
3527 there with your userid, it'll use that entry to determine your home directory, <emphasis>ignoring
3528 the setting of the environment variable $HOME</emphasis>. If the home directory is
3529 bogus, <command>ssh</command> fails horribly. The best way to see what is going on is to say
3530 <screen>ssh -v cvs.haskell.org</screen>
3531 which makes <command>ssh</command> print out information about its activity.
3533 <para> You can fix this problem, either by correcting the home-directory field in
3534 <filename>c:/cygwin/etc/passwd</filename>, or by simply deleting the entire entry for your userid. If
3535 you do that, <command>ssh</command> uses the $HOME environment variable instead.
3541 <para>To protect your
3542 <literal>.ssh</literal> from access by anyone else,
3543 right-click your <literal>.ssh</literal> directory, and
3544 select <literal>Properties</literal>. If you are not on
3545 the access control list, add yourself, and give yourself
3546 full permissions (the second panel). Remove everyone else
3547 from the access control list. Don't leave them there but
3548 deny them access, because 'they' may be a list that
3549 includes you!</para>
3553 <para>In fact <command>ssh</command> 3.6.1 now seems to <emphasis>require</emphasis>
3554 you to have Unix permissions 600 (read/write for owner only)
3555 on the <literal>.ssh/identity</literal> file, else it
3556 bombs out. For your local C drive, it seems that <literal>chmod 600 identity</literal> works,
3557 but on Windows NT/XP, it doesn't work on a network drive (exact dteails obscure).
3558 The solution seems to be to set the $CYGWIN environment
3559 variable to "<literal>ntsec neta</literal>". The $CYGWIN environment variable is discussed
3560 in <ulink url="http://cygwin.com/cygwin-ug-net/using-cygwinenv.html">the Cygwin User's Guide</ulink>,
3561 and there are more details in <ulink url="http://cygwin.com/faq/faq_4.html#SEC44">the Cygwin FAQ</ulink>.
3568 <sect2><title>Other things you need to install</title>
3570 <para>You have to install the following other things to build GHC, listed below.</para>
3572 <para>On Windows you often install executables in directories with spaces, such as
3573 "<filename>Program Files</filename>". However, the <literal>make</literal> system for fptools doesn't
3574 deal with this situation (it'd have to do more quoting of binaries), so you are strongly advised
3575 to put binaries for all tools in places with no spaces in their path.
3576 On both MSYS and Cygwin, it's perfectly OK to install such programs in the standard Unixy places,
3577 <filename>/usr/local/bin</filename> and <filename>/usr/local/lib</filename>. But it doesn't matter,
3578 provided they are in your path.
3582 Install an executable GHC, from <ulink url="http://www.haskell.org/ghc">http://www.haskell.org/ghc</ulink>.
3583 This is what you will use to compile GHC. Add it in your
3584 <constant>PATH</constant>: the installer tells you the path element
3585 you need to add upon completion.
3591 Install an executable Happy, from <ulink url="http://www.haskell.org/happy">http://www.haskell.org/happy</ulink>.
3592 Happy is a parser generator used to compile the Haskell grammar. Under MSYS or Cygwin you can easily
3593 build it from the source distribution using
3594 <screen>$ ./configure
3596 $ make install</screen>
3597 This should install it in <filename>/usr/local/bin</filename> (which maps to <filename>c:/msys/1.0/local/bin</filename>
3599 Make sure the installation directory is in your
3600 <constant>PATH</constant>.
3605 <para>Install an executable Alex. This can be done by building from the
3606 source distribution in the same way as Happy. Sources are
3607 available from <ulink
3608 url="http://www.haskell.org/alex">http://www.haskell.org/alex</ulink>.</para>
3612 <para>GHC uses the <emphasis>mingw</emphasis> C compiler to
3613 generate code, so you have to install that (see <xref linkend="cygwin-and-mingw"/>).
3614 Just pick up a mingw bundle at
3615 <ulink url="http://www.mingw.org/">http://www.mingw.org/</ulink>.
3616 We install it in <filename>c:/mingw</filename>.
3619 <para><emphasis>On MSYS</emphasis>, add <literal>c:/mingw/bin</literal> to your PATH. MSYS does not provide <command>gcc</command>,
3620 <command>ld</command>, <command>ar</command>, and so on, because it just uses the MinGW ones. So you need them
3624 <para><emphasis>On Cygwin, do not</emphasis> add any of the <emphasis>mingw</emphasis> binaries to your path.
3625 They are only going to get used by explicit access (via the --with-gcc flag you
3626 give to <command>configure</command> later). If you do add them to your path
3627 you are likely to get into a mess because their names overlap with Cygwin
3629 On the other hand, you <emphasis>do</emphasis> need <command>ld</command>, <command>ar</command>
3630 (and perhaps one or two other things) in your path. The Cygwin ones are fine,
3631 but you must have them; hence needing the Cygwin binutils package.
3637 <para>We use <command>emacs</command> a lot, so we install that too.
3638 When you are in <filename>fptools/ghc/compiler</filename>, you can use
3639 "<literal>make tags</literal>" to make a TAGS file for emacs. That uses the utility
3640 <filename>fptools/ghc/utils/hasktags/hasktags</filename>, so you need to make that first.
3641 The most convenient way to do this is by going <literal>make boot</literal> in <filename>fptools/ghc</filename>.
3642 The <literal>make tags</literal> command also uses <command>etags</command>, which comes with <command>emacs</command>,
3643 so you will need to add <filename>emacs/bin</filename> to your <literal>PATH</literal>.
3648 <para>You might want to install GLUT in your MSYS/Cygwin
3649 installation, otherwise the GLUT package will not be built with
3654 <para> Finally, check out a copy of GHC sources from
3655 the darcs repository, following the instructions at <ulink url="http://hackage.haskell.org/trac/ghc/wiki/GhcDarcs" />.</para>
3661 <sect2><title>Building GHC</title>
3664 Now go read the documentation above on building from source (<xref linkend="sec-building-from-source"/>);
3665 the bullets below only tell
3666 you about Windows-specific wrinkles.</para>
3670 If you used <command>autoconf</command> instead of <command>autoreconf</command>,
3671 you'll get an error when you run <filename>./configure</filename>:
3674 creating mk/config.h
3675 mk/config.h is unchanged
3677 running /bin/sh ./configure --cache-file=.././config.cache --srcdir=.
3678 ./configure: ./configure: No such file or directory
3679 configure: error: ./configure failed for ghc</screen>
3683 <listitem> <para><command>autoreconf</command> seems to create the file <filename>configure</filename>
3684 read-only. So if you need to run autoreconf again (which I sometimes do for safety's sake),
3686 <screen>/usr/bin/autoconf: cannot create configure: permission denied</screen>
3687 Solution: delete <filename>configure</filename> first.
3692 After <command>autoreconf</command> run <command>./configure</command> in
3693 <filename>fptools/</filename> thus:
3695 <screen>$ ./configure --host=i386-unknown-mingw32 --with-gcc=c:/mingw/bin/gcc</screen>
3696 This is the point at which you specify that you are building GHC-mingw
3697 (see <xref linkend="ghc-mingw"/>). </para>
3699 <para> Both these options are important! It's possible to get into
3700 trouble using the wrong C compiler!</para>
3702 Furthermore, it's <emphasis>very important</emphasis> that you specify a
3703 full MinGW path for <command>gcc</command>, not a Cygwin path, because GHC (which
3704 uses this path to invoke <command>gcc</command>) is a MinGW program and won't
3705 understand a Cygwin path. For example, if you
3706 say <literal>--with-gcc=/mingw/bin/gcc</literal>, it'll be interpreted as
3707 <filename>/cygdrive/c/mingw/bin/gcc</filename>, and GHC will fail the first
3708 time it tries to invoke it. Worse, the failure comes with
3709 no error message whatsoever. GHC simply fails silently when first invoked,
3710 typically leaving you with this:
3711 <screen>make[4]: Leaving directory `/cygdrive/e/fptools-stage1/ghc/rts/gmp'
3712 ../../ghc/compiler/ghc-inplace -optc-mno-cygwin -optc-O
3713 -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes
3714 -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
3715 -optc-Wbad-function-cast -optc-Wcast-align -optc-I../includes
3716 -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS
3717 -optc-fomit-frame-pointer -O2 -static
3718 -package-name rts -O -dcore-lint -c Adjustor.c -o Adjustor.o
3719 make[2]: *** [Adjustor.o] Error 1
3720 make[1]: *** [all] Error 1
3721 make[1]: Leaving directory `/cygdrive/e/fptools-stage1/ghc'
3722 make: *** [all] Error 1</screen>
3727 If you want to build GHC-cygwin (<xref linkend="ghc-cygwin"/>)
3728 you'll have to do something more like:
3729 <screen>$ ./configure --with-gcc=...the Cygwin gcc...</screen>
3734 If you are paranoid, delete <filename>config.cache</filename> if it exists.
3735 This file occasionally remembers out-of-date configuration information, which
3736 can be really confusing.
3740 <listitem><para> You almost certainly want to set
3741 <programlisting>SplitObjs = NO</programlisting>
3742 in your <filename>build.mk</filename> configuration file (see <xref linkend="sec-build-config"/>).
3743 This tells the build system not to split each library into a myriad of little object files, one
3744 for each function. Doing so reduces binary sizes for statically-linked binaries, but on Windows
3745 it dramatically increases the time taken to build the libraries in the first place.
3749 <listitem><para> Do not attempt to build the documentation.
3750 It needs all kinds of wierd Jade stuff that we haven't worked out for
3751 Win32.</para></listitem>
3756 <sect2><title>A Windows build log using Cygwin</title>
3758 <para>Here is a complete, from-scratch, log of all you need to build GHC using
3759 Cygwin, kindly provided by Claus Reinke. It does not discuss alternative
3760 choices, but it gives a single path that works.</para>
3761 <programlisting>- Install some editor (vim, emacs, whatever)
3763 - Install cygwin (http://www.cygwin.com)
3764 ; i used 1.5.16-1, installed in c:\cygwin
3766 Choose a Download Source:
3767 select 'download from internet';
3768 Select Root Install Directory:
3769 root dir: c:\cygwin;
3770 install for: all users;
3771 default file type: unix
3772 Select Local Package Directory
3773 choose a spare temporary home
3774 Select Your Internet Connection
3776 Choose a Download Site
3777 Choose your preferred main mirror and
3778 Add 'http://www.haskell.org/ghc/cygwin'
3780 In addition to 'Base' (default install),
3781 select 'Devel->ghc-depends'
3783 - Install mingw (http://www.mingw.org/)
3784 ; i used MinGW-3.1.0-1.exe
3785 ; installed in c:\mingw
3786 - you probably want to add GLUT
3787 ; (http://www.xmission.com/~nate/glut.html)
3788 ; i used glut-3.7.3-mingw32.tar
3790 - Get recent binary snapshot of ghc-6.4.1 for mingw
3791 ; (http://www.haskell.org/ghc/dist/stable/dist/)
3793 - add C:\ghc\ghc-6.4.1\bin to %PATH%
3794 (Start->Control Panel->System->Advanced->Environment Variables)
3796 - Get darcs version of ghc
3797 ; also, subscribe to cvs-all@haskell.org, or follow the mailing list
3798 ; archive, in case you checkout a version with problems
3799 ; http://www.haskell.org//pipermail/cvs-all/
3800 - mkdir c:/fptools; cd c:/fptools
3801 ; (or whereever you want your darcs tree to be)
3802 - darcs get http://darcs.haskell.org/ghc
3804 - chmod +x darcs-all
3807 - Build ghc, using cygwin and mingw, targetting mingw
3808 - export PATH=/cygdrive/c/ghc/ghc-6.4.1:$PATH
3809 ; for haddock, alex, happy (*)
3810 - export PATH=/cygdrive/c/mingw/bin:$PATH
3811 ; without, we pick up some cygwin tools at best!
3812 - cd c:/fptools/fptools
3813 ; (if you aren't there already)
3815 - ./configure --host=i386-unknown-mingw32 --with-gcc=C:/Mingw/bin/gcc.exe
3816 ; we use cygwin, but build for windows
3817 - cp mk/build.mk.sample mk/build.mk
3819 add line: SplitObjs = NO
3820 (MSYS seems slow when there are zillions of object files)
3821 uncomment line: BuildFlavour = perf
3822 (or BuildFlavour = devel, if you are doing development)
3823 add line: BIN_DIST=1
3824 - make 2>&1 | tee make.log
3825 ; always useful to have a log around
3827 - Package up binary distribution
3828 - make binary-dist Project=Ghc 2>&1 | tee make-bin-dist.log
3829 ; always useful to have a log around
3831 - chmod +x ../distrib/prep-bin-dist-mingw
3832 ; if you're happy with the script's contents (*)
3833 - ../distrib/prep-bin-dist-mingw
3834 ; then tar up, unpack where wanted, and enjoy</programlisting>
projects / ghc-hetmet.git / blob