X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=docs%2Fbuilding%2Fbuilding.sgml;h=8d3f73b2a13c35522689ff9b2cc19207a4d7612a;hb=5ca4a0134475bbc790af6ce7d7517a97e877bff6;hp=d85c4260533f04c61547624a339bbb2058129530;hpb=f4f66fdacc1145f3ab7b2b2cb2ed1759b1d1202b;p=ghc-hetmet.git diff --git a/docs/building/building.sgml b/docs/building/building.sgml index d85c426..8d3f73b 100644 --- a/docs/building/building.sgml +++ b/docs/building/building.sgml @@ -7,43 +7,41 @@ Building the Glasgow Functional Programming Tools Suite The GHC Team
glasgow-haskell-{users,bugs}@haskell.org
-January 2000 +November 2001 - + + The Glasgow fptools suite is a collection of Functional + Programming related tools, including the Glasgow Haskell + Compiler (GHC). The source code for the whole suite is kept in + a single CVS repository and shares a common build and + installation system. - -This guide is intended for people who want to build or modify -programs from the Glasgow fptools suite (as distinct from those -who merely want to run them). Installation instructions are now provided in the user guide. - + This guide is intended for people who want to build or + modify programs from the Glasgow fptools + suite (as distinct from those who merely want to + run them). Installation instructions are + now provided in the user guide. - -The bulk of this guide applies to building on Unix systems; see for Windows notes. - + The bulk of this guide applies to building on Unix + systems; see for Windows notes. + - + - + + Getting the Glasgow <Literal>fptools</Literal> suite - -Getting the Glasgow <Literal>fptools</Literal> suite - + Building the Glasgow tools can be + complicated, mostly because there are so many permutations of + what/why/how, e.g., ``Build Happy with HBC, everything else with + GHC, leave out profiling, and test it all on the `real' NoFib + programs.'' Yeeps! - -Building the Glasgow tools can be complicated, mostly because -there are so many permutations of what/why/how, e.g., ``Build Happy -with HBC, everything else with GHC, leave out profiling, and test it -all on the `real' NoFib programs.'' Yeeps! - + Happily, such complications don't apply to most people. A + few common ``strategies'' serve most purposes. Pick one and + proceed as suggested: - -Happily, such complications don't apply to most people. A few common -``strategies'' serve most purposes. Pick one and proceed -as suggested: - - - @@ -99,132 +97,792 @@ machine in order to compile (most of) the sources, however. - -Build GHC from intermediate C .hc fileshc files: - - -You -need a working GHC to use a source distribution. What if you don't -have a working GHC? Then you have no choice but to ``bootstrap'' up -from the intermediate C (.hc) files that we provide. Building GHC -on an unsupported platform falls into this category. Please see -. - - - -Once you have built GHC, you can build the other Glasgow tools with -it. - - - -In theory, you can (could?) build GHC with another Haskell compiler -(e.g., HBC). We haven't tried to do this for ages and it almost -certainly doesn't work any more (for tedious reasons). - - - -The CVS repository. - - -We make releases infrequently. If you want more up-to-the minute (but -less tested) source code then you need to get access to our CVS -repository. - - -All the fptools source code is held in a CVS -repository. CVS is a pretty good source-code control system, and best -of all it works over the network. - -The repository holds source code only. It holds no mechanically -generated files at all. So if you check out a source tree from CVS -you will need to install every utility so that you can build all the -derived files from scratch. - -More information about our CVS repository is available in the -fptools -CVS Cheat Sheet. - - - - - -If you are going to do any building from sources (either from a -source distribution or the CVS repository) then you need to read all -of this manual in detail. - - - - -Things to check before you start - - -Here's a list of things to check before you get started. - - - - - -Disk space needed -Disk space needed: About 40MB (one tenth of one hamburger's worth) of disk -space for the most basic binary distribution of GHC; more for some -platforms, e.g., Alphas. An extra ``bundle'' (e.g., concurrent Haskell -libraries) might take you to up to one fifth of a hamburger. You'll need -over 100MB (say, one fifth a hamburger's worth) if you need to build the -basic stuff from scratch. All of the above are -estimates of disk-space needs. (Note: our benchmark hamburger is a standard Double Whopper with Cheese, with an RRP of UKP2.99.) - - - - - -Use an appropriate machine, compilers, and things. SPARC boxes, and -PCs running Linux, BSD (any variant), or Solaris are all fully -supported. Win32 and HP boxes are in pretty good shape. DEC Alphas -running OSF/1, Linux or some BSD variant, MIPS and AIX boxes will need -some minimal porting effort before they work (as of 4.06). gives the full run-down on ports or lack -thereof. - - - - - - Be sure that the ``pre-supposed'' utilities are installed. - elaborates. - - - - - - - If you have any problem when building or installing the Glasgow -tools, please check the ``known pitfalls'' (). Also check the FAQ for the version -you're building, which should be available from the relevant download -page on the GHC web -site. -known bugs -bugs, known - -If you feel there is still some shortcoming in our procedure or -instructions, please report it. - -For GHC, please see the bug-reporting section of the GHC Users' Guide -(separate document), to maximise the usefulness of your report. -bugs, reporting - -If in doubt, please send a message to -glasgow-haskell-bugs@haskell.org. -bugs, mailing list - - - - - - - - + + The CVS repository. + CVS repository + + + We make releases infrequently. If you want more + up-to-the minute (but less tested) source code then you need + to get access to our CVS repository. + + All the fptools source code is held + in a CVS repository. CVS is a pretty good source-code + control system, and best of all it works over the + network. + + The repository holds source code only. It holds no + mechanically generated files at all. So if you check out a + source tree from CVS you will need to install every utility + so that you can build all the derived files from + scratch. + + More information about our CVS repository can be found + in . + + + + + + Build GHC from intermediate C .hc fileshc files: + + You need a working GHC to use a source distribution. + What if you don't have a working GHC? Then you may be able + to bootstrap up from the intermediate C + (.hc) files that we provide. Building + GHC on an unsupported platform falls into this category. + Beware: this route is not for the faint hearted! Please see + . + + Once you have built GHC, you can build the other + Glasgow tools with it. + + In theory, you can (could?) build GHC with another + Haskell compiler (e.g., HBC). We haven't tried to do this + for ages and it almost certainly doesn't work any more (for + tedious reasons). + + + + + If you are going to do any building from sources (either + from a source distribution or the CVS repository) then you need to + read all of this manual in detail. + + + + Using the CVS repository + + We use CVS (Concurrent Version System) to keep track of our + sources for various software projects. CVS lets several people + work on the same software at the same time, allowing changes to be + checked in incrementally. + + This section is a set of guidelines for how to use our CVS + repository, and will probably evolve in time. The main thing to + remember is that most mistakes can be undone, but if there's + anything you're not sure about feel free to bug the local CVS + meister (namely Jeff Lewis + jlewis@galconn.com). + + + Getting access to the CVS Repository + + You can access the repository in one of two ways: + read-only (), or read-write (). + + + Remote Read-only CVS Access + + Read-only access is available to anyone - there's no + need to ask us first. With read-only CVS access you can do + anything except commit changes to the repository. You can + make changes to your local tree, and still use CVS's merge + facility to keep your tree up to date, and you can generate + patches using 'cvs diff' in order to send to us for + inclusion. + + To get read-only access to the repository: + + + + Make sure that cvs is + installed on your machine. + + + Set your $CVSROOT environment variable to + :pserver:anoncvs@glass.cse.ogi.edu:/cvs + + + Run the command + + $ cvs login + + The password is simply cvs. This + sets up a file in your home directory called + .cvspass, which squirrels away the + dummy password, so you only need to do this step once. + + + + Now go to . + + + + + + Remote Read-Write CVS Access + + We generally supply read-write access to folk doing + serious development on some part of the source tree, when + going through us would be a pain. If you're developing some + feature, or think you have the time and inclination to fix + bugs in our sources, feel free to ask for read-write + access. There is a certain amount of responsibility that goes + with commit privileges; we are more likely to grant you access + if you've demonstrated your competence by sending us patches + via mail in the past. + + To get remote read-write CVS access, you need to do the + following steps. + + + + Make sure that cvs and + ssh are both installed on your + machine. + + + + Generate a DSA private-key/public-key pair, thus: + + $ ssh-keygen -d + + (ssh-keygen comes with + ssh.) Running ssh-keygen + -d creates the private and public keys in + $HOME/.ssh/id_dsa and + $HOME/.ssh/id_dsa.pub respectively + (assuming you accept the standard defaults). + + ssh-keygen -d will only work if + you have Version 2 ssh installed; it + will fail harmlessly otherwise. If you only have Version + 1 you can instead generate an RSA key pair using plain + + $ ssh-keygen + + + Doing so creates the private and public RSA keys in + $HOME/.ssh/identity and + $HOME/.ssh/identity.pub + respectively. + + [Deprecated.] Incidentally, you can force a Version + 2 ssh to use the Version 1 protocol by + creating $HOME/config with the + following in it: + + BatchMode Yes + + Host cvs.haskell.org + Protocol 1 + + + In both cases, ssh-keygen will + ask for a passphrase. The + passphrase is a password that protects your private key. + In response to the 'Enter passphrase' question, you can + either: + + + [Recommended.] Enter a passphrase, which you + will quote each time you use CVS. + ssh-agent makes this entirely + un-tiresome. + + + [Deprecated.] Just hit return (i.e. use an empty + passphrase); then you won't need to quote the + passphrase when using CVS. The downside is that + anyone who can see into your .ssh + directory, and thereby get your private key, can mess + up the repository. So you must keep the + .ssh directory with draconian + no-access permissions. + + + + [Windows users. To protect your + .ssh from access by anyone else, + right-click your .ssh directory, and + select Properties. If you are not on + the access control list, add yourself, and give yourself + full permissions (the second panel). Remove everyone else + from the access control list. Don't leave them there but + deny them access, because 'they' may be a list that + includes you!] + + + + Send a message to to the CVS repository + administrator (currently Jeff Lewis + jeff@galconn.com), containing: + + + Your desired user-name. + + + Your .ssh/id_dsa.pub (or + .ssh/identity.pub). + + + He will set up your account. + + + + Set the following environment variables: + + + $CVS_RSH to + ssh + + + $CVSROOT to + :ext:your-username@cvs.haskell.org:/home/cvs/root + + + + + + + The CVSROOT environment variable will + be recorded in the checked-out tree, so you don't need to set + this every time either. Ignore the instructions for setting + CVSROOT below. + + Caveats: + + + + Setting your CVS_RSH to + ssh assumes that your CVS client + understands how to execute shell script + ("#!"s,really), which is what + ssh is. This may not be the case on + some platforms (read: Win32), so in that case set + CVS_RSH to + ssh1. + + + + [Experts.] Once your account is set up, you can get + access from other machines without bothering Jeff, thus: + + + Generate a public/private key pair on the new + machine. + + + Use ssh to log in to + cvs.haskell.org, from your old + machine. + + + Add the public key for the new machine to the file + $HOME/ssh/authorized_keys on + cvs.haskell.org. + (authorized_keys2, I think, for Version + 2 protocol.) + + + Make sure that the new version of + authorized_keys still has 600 file + permissions. + + + + + + + Checking Out a Source Tree + + + + Make sure you set your CVSROOT + environment variable according to either of the remote + methods above. The Approved Way to check out a source tree + is as follows: + + + $ cvs checkout fpconfig + + + At this point you have a new directory called + fptools which contains the basic stuff + for the fptools suite, including the configuration files and + some other junk. + + + $ mv fptools directory + + + You can call the fptools directory whatever you like, + CVS won't mind. + + NB: after you've read the CVS manual you might be + tempted to try + + $ cvs checkout -d directory fpconfig + + + instead of checking out fpconfig + and then renaming it. But this doesn't work, and will + result in checking out the entire repository instead of just + the fpconfig bit. + + $ cd directory + $ cvs checkout ghc hslibs + + + The second command here checks out the relevant + modules you want to work on. For a GHC build, for instance, + you need at least the ghc and + hslibs modules (for a full list of the + projects available, see ). + + + + + + Committing Changes + + This is only if you have read-write access to the + repository. For anoncvs users, CVS will issue a "read-only + repository" error if you try to commit changes. + + + + Build the software, if necessary. Unless you're just + working on documentation, you'll probably want to build the + software in order to test any changes you make. + + + + Make changes. Preferably small ones first. + + + + Test them. You can see exactly what changes you've + made by using the cvs diff command: + +$ cvs diff + + lists all the changes (using the + diff command) in and below the current + directory. In emacs, C-c C-v = runs + cvs diff on the current buffer and shows + you the results. + + + + Before checking in a change, you need to update your + source tree: + + +$ cd fptools +$ cvs update + + This pulls in any changes that other people have made, + and merges them with yours. If there are any conflicts, CVS + will tell you, and you'll have to resolve them before you + can check your changes in. The documentation describes what + to do in the event of a conflict. + + It's not always necessary to do a full cvs update + before checking in a change, since CVS will always tell you + if you try to check in a file that someone else has changed. + However, you should still update at regular intervals to + avoid making changes that don't work in conjuction with + changes that someone else made. Keeping an eye on what goes + by on the mailing list can help here. + + + + When you're happy that your change isn't going to + break anything, check it in. For a one-file change: + + +$ cvs commit filename + + + CVS will then pop up an editor for you to enter a + "commit message", this is just a short description + of what your change does, and will be kept in the history of + the file. + + If you're using emacs, simply load up the file into a + buffer and type C-x C-q, and emacs will + prompt for a commit message and then check in the file for + you. + + For a multiple-file change, things are a bit + trickier. There are several ways to do this, but this is the + way I find easiest. First type the commit message into a + temporary file. Then either + + +$ cvs commit -F commit-message file_1 .... file_n + + + or, if nothing else has changed in this part of the + source tree, + + +$ cvs commit -F commit-message directory + + + where directory is a common + parent directory for all your changes, and + commit-message is the name of the + file containing the commit message. + + Shortly afterwards, you'll get some mail from the + relevant mailing list saying which files changed, and giving + the commit message. For a multiple-file change, you should + still get only one message. + + + + + + Updating Your Source Tree + + It can be tempting to cvs update just part of a source + tree to bring in some changes that someone else has made, or + before committing your own changes. This is NOT RECOMMENDED! + Quite often changes in one part of the tree are dependent on + changes in another part of the tree (the + mk/*.mk files are a good example where + problems crop up quite often). Having an inconsistent tree is a + major cause of headaches. + + So, to avoid a lot of hassle, follow this recipe for + updating your tree: + + +$ cd fptools +$ cvs update -Pd 2>&1 | tee log + + Look at the log file, and fix any conflicts (denoted by a + C in the first column). If you're using multiple + build trees, then for every build tree you have pointing at this + source tree, you need to update the links in case any new files + have appeared: + + +$ cd build-tree +$ lndir source-tree + + + Some files might have been removed, so you need to remove + the links pointing to these non-existent files: + + +$ find . -xtype l -exec rm '{}' \; + + + To be really safe, you should do + + +$ gmake all + + from the top-level, to update the dependencies and build + any changed files. + + + + GHC Tag Policy + + If you want to check out a particular version of GHC, + you'll need to know how we tag versions in the repository. The + policy (as of 4.04) is: + + + + The tree is branched before every major release. The + branch tag is ghc-x-xx-branch, where + x-xx is the version number of the release + with the '.' replaced by a + '-'. For example, the 4.04 release lives + on ghc-4-04-branch. + + + + The release itself is tagged with + ghc-x-xx (on the branch). eg. 4.06 is + called ghc-4-06. + + + + We didn't always follow these guidelines, so to see + what tags there are for previous versions, do cvs + log on a file that's been around for a while (like + fptools/ghc/README). + + + + So, to check out a fresh GHC 4.06 tree you would + do: + + + $ cvs co -r ghc-4-06 fpconfig + $ cd fptools + $ cvs co -r ghc-4-06 ghc hslibs + + + + + General Hints + + + + As a general rule: commit changes in small units, + preferably addressing one issue or implementing a single + feature. Provide a descriptive log message so that the + repository records exactly which changes were required to + implement a given feature/fix a bug. I've found this + very useful in the past for finding out + when a particular bug was introduced: you can just wind back + the CVS tree until the bug disappears. + + + + Keep the sources at least *buildable* at any given + time. No doubt bugs will creep in, but it's quite easy to + ensure that any change made at least leaves the tree in a + buildable state. We do nightly builds of GHC to keep an eye + on what things work/don't work each day and how we're doing + in relation to previous verions. This idea is truely wrecked + if the compiler won't build in the first place! + + + + To check out extra bits into an already-checked-out + tree, use the following procedure. Suppose you have a + checked-out fptools tree containing just ghc, and you want + to add nofib to it: + + +$ cd fptools +$ cvs checkout nofib + + + or: + + +$ cd fptools +$ cvs update -d nofib + + + (the -d flag tells update to create a new + directory). If you just want part of the nofib suite, you + can do + + +$ cd fptools +$ cvs checkout nofib/spectral + + + This works because nofib is a + module in its own right, and spectral is a subdirectory of + the nofib module. The path argument to checkout must always + start with a module name. There's no equivalent form of this + command using update. + + + + + + + What projects are there? + + The fptools suite consists of several + projects, most of which can be downloaded, + built and installed individually. Each project corresponds to a + subdirectory in the source tree, and if checking out from CVS then + each project can be checked out individually by sitting in the top + level of your source tree and typing cvs checkout + project. + + Here is a list of the projects currently available: + + + + ghc + ghc + project + + The Glasgow + Haskell Compiler (minus libraries). Absolutely + required for building GHC. + + + + + glafp-utils + glafp-utilsproject + + Utility programs, some of which are used by the + build/installation system. Required for pretty much + everything. + + + + + green-card + green-cardproject + + The Green Card + system for generating Haskell foreign function + interfaces. + + + + + haggis + haggisproject + + The Haggis + Haskell GUI framework. + + + + + happy + happyproject + + The Happy Parser + generator. + + + + + hdirect + hdirectproject + + The H/Direct + Haskell interoperability tool. + + + + + hood + hoodproject + + The Haskell + Object Observation Debugger. + + + + + hslibs + hslibsproject + + GHC's libraries. Required for building GHC. + + + + + libraries + project + + Hierarchical Haskell library suite + (experimental). + + + + + mhms + project + + The Modular Haskell Metric System. + + + + + nofib + nofibproject + + The NoFib suite: A collection of Haskell programs used + primarily for benchmarking. + + + + + testsuite + testsuiteproject + + A testing framework, including GHC's regression test + suite. + + + + + So, to build GHC you need at least the + ghc and hslibs projects (a + GHC source distribution will already include the bits you + need). + + + + Things to check before you start + + Here's a list of things to check before you get + started. + + + + + Disk space needed + Disk space needed: from about 100Mb for a basic GHC + build, up to probably 500Mb for a GHC build with everything + included (libraries built several different ways, + etc.). + + + + Use an appropriate machine, compilers, and things. + SPARC boxes, PCs running Linux or FreeBSD, and Alphas running + OSF/1 are all fully supported. Win32 and HP boxes are in + pretty good shape. PCs running Solaris, DEC Alphas running + Linux or some BSD variant, MIPS and AIX boxes will need some + minimal porting effort before they work (as of 4.06). gives the full run-down on ports or + lack thereof. + + + + Be sure that the ``pre-supposed'' utilities are + installed. + elaborates. + + + + If you have any problem when building or installing the + Glasgow tools, please check the ``known pitfalls'' (). Also check the FAQ for the + version you're building, which should be available from the + relevant download page on the GHC web + site. + + known bugs + bugs, known + + If you feel there is still some shortcoming in our + procedure or instructions, please report it. + + For GHC, please see the bug-reporting section of the GHC + Users' Guide (separate document), to maximise the usefulness + of your report. + + bugsseporting + + If in doubt, please send a message to +glasgow-haskell-bugs@haskell.org. +bugsmailing +list + + + + What machines the Glasgow tools run on @@ -283,146 +941,145 @@ Here's everything that's known about GHC ports. We identify platforms by their ``canonical'' CPU/Manufacturer/OS triple. </para> -<para> -<VariableList> - -<VarListEntry> -<Term>alpha-dec-{osf,linux,freebsd,openbsd,netbsd}:</Term> -<IndexTerm><Primary>alpha-dec-osf</Primary></IndexTerm> -<IndexTerm><Primary>alpha-dec-linux</Primary></IndexTerm> -<IndexTerm><Primary>alpha-dec-freebsd</Primary></IndexTerm> -<IndexTerm><Primary>alpha-dec-openbsd</Primary></IndexTerm> -<IndexTerm><Primary>alpha-dec-netbsd</Primary></IndexTerm> -<ListItem> - -<para> -Currently non-working. The last working version (osf[1-3]) is GHC -3.02. A small amount of porting effort will be required to get Alpha -support into GHC 4.xx, but we don't have easy access to machines right -now, and there hasn't been a massive demand for support, so Alphas -remain unsupported for the time being. Please get in touch if you -either need Alpha support and/or can provide access to boxes. -</para> - -</ListItem></VarListEntry> -<VarListEntry> -<Term>sparc-sun-sunos4:</Term> -<IndexTerm><Primary>sparc-sun-sunos4</Primary></IndexTerm> -<ListItem> - -<para> -Probably works with minor tweaks, hasn't been tested for a while. -</para> - -</ListItem></VarListEntry> -<VarListEntry> -<Term>sparc-sun-solaris2:</Term> -<IndexTerm><Primary>sparc-sun-solaris2</Primary></IndexTerm> -<ListItem> - -<para> -Fully supported, including native-code generator. -</para> - -</ListItem></VarListEntry> -<VarListEntry> -<Term>hppa1.1-hp-hpux (HP-PA boxes running HPUX 9.x)</Term> -<IndexTerm><Primary>hppa1.1-hp-hpux</Primary></IndexTerm> -<ListItem> - -<para> -Works registerised. No native-code generator. -</para> - -</ListItem></VarListEntry> -<VarListEntry> -<Term>i386-unknown-linux (PCs running Linux—ELF binary format):</Term> -<IndexTerm><Primary>i386-*-linux</Primary></IndexTerm> -<ListItem> - -<para>GHC works registerised and has a native code generator. You -<Emphasis>must</Emphasis> have GCC 2.7.x or later. NOTE about -<literal>glibc</literal> versions: GHC binaries built on a system -running <literal>glibc 2.0</literal> won't work on a system running -<literal>glibc 2.1</literal>, and vice versa. In general, don't -expect compatibility between <literal>glibc</literal> versions, even -if the shared library version hasn't changed. -</para> - -</ListItem></VarListEntry> -<VarListEntry> -<Term>i386-unknown-{freebsd,netbsd,openbsd) (PCs running FreeBSD 2.2 -or higher, NetBSD, and possibly OpenBSD):</Term> -<IndexTerm><Primary>i386-unknown-freebsd</Primary></IndexTerm> -<IndexTerm><Primary>i386-unknown-netbsd</Primary></IndexTerm> -<IndexTerm><Primary>i386-unknown-openbsd</Primary></IndexTerm> -<ListItem> - -<para> -GHC works registerised. These systems provide ready-built packages of -GHC, so if you just need binaries you're better off just installing -the package. -</para> - -</ListItem></VarListEntry> -<VarListEntry> -<Term>i386-unknown-cygwin32:</Term> -<IndexTerm><Primary>i386-unknown-cygwin32</Primary></IndexTerm> -<ListItem> - -<para> -Fully supported under Win9x/NT, including a native code -generator. Requires the <Literal>cygwin32</Literal> compatibility -library and a healthy collection of GNU tools (i.e., gcc, GNU ld, bash -etc.). -</para> - -</ListItem></VarListEntry> -<VarListEntry> -<Term>mips-sgi-irix5:</Term> -<IndexTerm><Primary>mips-sgi-irix[5-6]</Primary></IndexTerm> -<ListItem> - -<para> -Port currently doesn't work, needs some minimal porting effort. As -usual, we don't have access to machines and there hasn't been an -overwhelming demand for this port, but feel free to get in touch. -</para> -</ListItem></VarListEntry> - -<VarListEntry> -<Term>powerpc-ibm-aix:</Term> -<ListItem> -<para> -<IndexTerm><Primary>powerpc-ibm-aix</Primary></IndexTerm> -Port currently doesn't work, needs some minimal porting effort. As -usual, we don't have access to machines and there hasn't been an -overwhelming demand for this port, but feel free to get in touch. -</para> -</ListItem></VarListEntry> - -</VariableList> -</para> - -<para> -Various other systems have had GHC ported to them in the distant past, -including various Motorola 68k boxes. The 68k support still remains, -but porting to one of these systems will certainly be a non-trivial -task. -</para> - -</Sect2> - -<Sect2> -<Title>What machines the other tools run on - - -Unless you hear otherwise, the other tools work if GHC works. - - - - - + + + + alpha-dec-{osf,linux,freebsd,openbsd,netbsd}: + alpha-dec-osf + alpha-dec-linux + alpha-dec-freebsd + alpha-dec-openbsd + alpha-dec-netbsd + + + The OSF port is currently working (as of GHC version + 5.02.1) and well supported. The native code generator is + currently non-working. Other operating systems will + require some minor porting. + + + + + sparc-sun-sunos4 + sparc-sun-sunos4 + + Probably works with minor tweaks, hasn't been tested + for a while. + + + + + sparc-sun-solaris2 + sparc-sun-solaris2 + + Fully supported, including native-code + generator. + + + + + hppa1.1-hp-hpux (HP-PA boxes running HPUX 9.x) + hppa1.1-hp-hpux + + Works registerised. No native-code + generator. + + + + + i386-unknown-linux (PCs running Linux, ELF binary format) + i386-*-linux + + GHC works registerised and has a native code + generator. You must have GCC 2.7.x + or later. NOTE about glibc versions: + GHC binaries built on a system running glibc + 2.0 won't work on a system running + glibc 2.1, and vice versa. In general, + don't expect compatibility between + glibc versions, even if the shared + library version hasn't changed. + + + + + i386-unknown-freebsd (PCs running FreeBSD 2.2 +or higher) + i386-unknown-freebsd + + GHC works registerised. Pre-built packages are + available in the native package format, so if you just + need binaries you're better off just installing the + package. + + + + + i386-unknown-{netbsd,openbsd) (PCs running NetBSD + and OpenBSD) + i386-unknown-netbsd + i386-unknown-openbsd + + Will require some minor porting effort, but should + work registerised. + + + + + i386-unknown-cygwin32: + i386-unknown-cygwin32 + + Fully supported under Win9x/NT, including a native + code generator. Requires the cygwin32 + compatibility library and a healthy collection of GNU + tools (i.e., gcc, GNU ld, bash etc.). + + + + + mips-sgi-irix5 + mips-sgi-irix[5-6] + + Port currently doesn't work, needs some minimal + porting effort. As usual, we don't have access to + machines and there hasn't been an overwhelming demand for + this port, but feel free to get in touch. + + + + + powerpc-ibm-aix + powerpc-ibm-aix + + Port currently doesn't work, needs some minimal + porting effort. As usual, we don't have access to + machines and there hasn't been an overwhelming demand for + this port, but feel free to get in touch. + + + + + powerpc-apple-darwin + powerpc-apple-darwin + + Works, unregisterised only at the moment. + + + + + Various other systems have had GHC ported to them in the + distant past, including various Motorola 68k boxes. The 68k + support still remains, but porting to one of these systems will + certainly be a non-trivial task. + + + + What machines the other tools run on + + Unless you hear otherwise, the other tools work if GHC + works. + + @@ -634,6 +1291,15 @@ everything you need. + + In order to actually build any documentation, you need to set + SGMLDocWays in your + build.mk. Valid values to add to this + list are: dvi, ps, + pdf, html, and + rtf. + + @@ -1103,107 +1769,105 @@ YACC = myyacc - -The story so far - - -Let's summarise the steps you need to carry to get yourself -a fully-configured build tree from scratch. - - - - - - - - - Get your source tree from somewhere (CVS repository or source -distribution). Say you call the root directory myfptools (it -does not have to be called fptools). Make sure that you have -the essential files (see ). - - - - - - - Use lndir or mkshadowdir to create a build tree. - - -cd myfptools -mkshadowdir . /scratch/joe-bloggs/myfptools-sun4 - - -(N.B. mkshadowdir's first argument is taken relative to its second.) You probably want to give the build tree a name that -suggests its main defining characteristic (in your mind at least), -in case you later add others. - - - - - - - Change directory to the build tree. Everything is going -to happen there now. - - -cd /scratch/joe-bloggs/myfptools-sun4 - - - - - - - - Prepare for system configuration: - - -autoconf - - -(You can skip this step if you are starting from a source distribution, -and you already have configure and mk/config.h.in.) - - - - - - - Do system configuration: - - -./configure - - - - - - - - - Create the file mk/build.mk, -adding definitions for your desired configuration options. - - -emacs mk/build.mk - - - - - - - -You can make subsequent changes to mk/build.mk as often -as you like. You do not have to run any further configuration programs to -make these changes take effect. In theory you should, however, say -gmake clean, gmake all, because -configuration option changes could affect anything—but in practice you -are likely to know what's affected. - - - - - + + The story so far + + Let's summarise the steps you need to carry to get + yourself a fully-configured build tree from scratch. + + + + Get your source tree from somewhere (CVS repository + or source distribution). Say you call the root directory + myfptools (it does not have to be + called fptools). Make sure that you + have the essential files (see ). + + + + + (Optional) Use lndir or + mkshadowdir to create a build tree. + + +$ cd myfptools +$ mkshadowdir . /scratch/joe-bloggs/myfptools-sun4 + + + (N.B. mkshadowdir's first argument + is taken relative to its second.) You probably want to give + the build tree a name that suggests its main defining + characteristic (in your mind at least), in case you later + add others. + + + + Change directory to the build tree. Everything is + going to happen there now. + + +$ cd /scratch/joe-bloggs/myfptools-sun4 + + + + + + Prepare for system configuration: + + +$ autoconf + + + (You can skip this step if you are starting from a + source distribution, and you already have + configure and + mk/config.h.in.) + + Some projects, including GHC itself, have their own + configure scripts, so it is necessary to run autoconf again + in the appropriate subdirectories. eg: + + +$ (cd ghc; autoconf) + + + + + Do system configuration: + + +$ ./configure + + + Don't forget to check whether you need to add any + arguments to configure; for example, a + common requirement is to specify which GHC to use with + . + + + + Create the file mk/build.mk, + adding definitions for your desired configuration + options. + + +$ emacs mk/build.mk + + + + + You can make subsequent changes to + mk/build.mk as often as you like. You do + not have to run any further configuration programs to make these + changes take effect. In theory you should, however, say + gmake clean, gmake all, + because configuration option changes could affect + anything—but in practice you are likely to know what's + affected. + + + Making things At this point you have made yourself a fully-configured @@ -1269,7 +1933,7 @@ file. Typing gmake alone is generally the same as typing install: -installs the things built by all. Where does it +installs the things built by all (except for the documentation). Where does it install them? That is specified by mk/config.mk.in; you can override it in mk/build.mk, or by running @@ -1279,6 +1943,13 @@ install them? That is specified by +install-docs: + + +installs the documentation. Otherwise behaves just like install. + + + uninstall: @@ -2722,7 +3393,7 @@ c:\tmp> c:/user/local/bin/ssh-keygen1 If you don't have an account on cvs.haskell.org, send your .ssh/identity.pub to the CVS repository administrator - (currently Jeff Lewis jlewis@cse.ogi.edu). He will set up + (currently Jeff Lewis jlewis@galconn.com). He will set up your account. @@ -2873,20 +3544,22 @@ I have not tried it yet. -Building GHC - - + Building GHC + + - - -In the ./configure output, ignore -" -checking whether #! works in shell scripts... -./configure: ./conftest: No such file or directory", -and "not updating unwritable cache ./config.cache". -Nobody knows why these happen, but they seem to be harmless. - - + + + You should give the option + to + autoconf, so that it doesn't try to + build for Cygwin (unless that's what you really + want). Since it's possible to get into trouble using the + wrong C compiler, it's wise either to avoid installing + Cygwin gcc, or to explicitly specify + . + + @@ -2909,11 +3582,8 @@ configure: error: ./configure failed for ghc You need ghc to be in your PATH before you run -configure. The default GHC InstallShield creates only -ghc-4.08, so you may need to duplicate this file as ghc -in the same directory, in order that configure will see it (or -just rename ghc-4.08 to ghc. -And make sure that the directory is in your path. +configure. The InstallShield tells you the path +when you install it. @@ -2921,6 +3591,79 @@ And make sure that the directory is in your path. + + Building the Windows InstallShield® Installer + + + This section is intended for GHC developers only; no-one else + should need to build an InstallShield. + + + + Having built a second-stage tree and done make + install on it, open the InstallShield + (.ism) file. Open the Project screen, and + then the Project subfolder of the Path variables folder, and + set SourceFiles to the top of your + tree. You might also need to set GHCBITS to + point to the tree of various external bits that are added into + the IS mix. You should then be able to build an InstallShield. + + + + Extra features of the InstallShield + + + The InstallShield has some IS-specific twiddles: + + + + + Two registry entries are set under + HKEY_LOCAL_MACHINE\SOFTWARE\GHC: + Path and + Version, which record respectively + the directory in which GHC was installed, and the + version number. + + + + + The InstallShield adds some entries to the Program + menu, for GHCi and for the documentation. See under + Setup Design and the individual components (each + component can add entries to the menu). + + + + + + + + External add-ins + + + The external add-ins consist of Mingwin gcc and Mingwin + Perl. The layout of the add-ins tree is as follows: + + +extra-bin/ + gcc.exe + perl.exe (Mingwin perl) + perl56.dll +gcc-lib/ + Mingwin gcc binaries, libraries and headers +imports/ + com/ + imports for HDirect's com library +include/ + Mingwin includes + + + + + +