Building the Glasgow Functional Programming Tools SuiteThe GHC Teamglasgow-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 fptools suite
-
-Getting the Glasgow fptools 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-messagefile_1 .... file_n
+
+
+ or, if nothing else has changed in this part of the
+ source tree,
+
+
+$ cvs commit -F commit-messagedirectory
+
+
+ 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.
-
-
-
-
-alpha-dec-{osf,linux,freebsd,openbsd,netbsd}:
-alpha-dec-osf
-alpha-dec-linux
-alpha-dec-freebsd
-alpha-dec-openbsd
-alpha-dec-netbsd
-
-
-
-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.
-
-
-
-
-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,netbsd,openbsd) (PCs running FreeBSD 2.2
-or higher, NetBSD, and possibly OpenBSD):
-i386-unknown-freebsd
-i386-unknown-netbsd
-i386-unknown-openbsd
-
-
-
-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.
-
-
-
-
-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.
-
-
-
-
-
-
-
-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.
-
-
-
-
-
+
+
+
+ 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 thingsAt 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
+
+
+
+
+
+