|Version 36 (modified by igloo, 8 years ago) (diff)|
Video: Getting and Building, layout of the source tree, how to set up build.mk (23'43")
Getting the GHC Sources
There are two ways to get sources to GHC: download a source distribution, or get the sources directly from our repository using darcs.
A source distribution is a file like ghc-6.6-src.tar.bz2, which contains a complete snapshot of the source tree for a particular version of GHC. Source distributions for all versions of GHC are available from the download page.
Starting with GHC 6.6, we have split the source distribution in two:
- ghc-<version>-src.tar.bz2 contains GHC itself and the minimum libraries needed to bootstrap GHC.
- ghc-<version>-src-extralibs.tar.bz2 contains a selection of supplemental libraries that can be built and installed at the same time as GHC. Just unpack this on top of ghc-<version>-src.tar.bz2, and the extra libraries will be built automatically.
In addition to fixed releases of GHC, source distributions are also made each night from the current source repository, for both the HEAD and STABLE branches. To download these snapshots, head over to the download page.
Source distributions are easier to build, because we also include the output from running certain external tools like Happy, so you don't need to install these tools. See Building/Prerequisites for details.
Getting a GHC source tree using darcs
The first thing to do is install darcs.
A source tree consists of the GHC repository, with a set of library packages in the libraries directory. Each of these libraries has its own repository: see DarcsRepositories.
If you only want to download the latest sources and aren't interested in working on GHC, then you can get partial repositories:
$ darcs get --partial http://darcs.haskell.org/ghc $ cd ghc $ chmod +x darcs-all $ ./darcs-all get
The command darcs-all adds the --partial flag by default.
If you plan to modify GHC, then you must get repositories with full history rather than just partial repositories. (Why? Because darcs has some bugs that sometimes cause problems when using partial repositories for anything more than just pulling the latest patches.) However, you cannot use darcs get to get a full GHC repository, for two reasons:
- GHC has more than 16,000 patches and the darcs get will take forever.
- Darcs has a bug concerning case-sensitivity on Windows, and (apparently) MacOS X, which makes Darcs crash on Windows if you do darcs get on the full GHC repository. You get this message
Applying patch 12 of 17349... Unapplicable patch: Thu Jan 11 07:26:13 MST 1996 partain * [project @ 1996-01-11 14:06:51 by partain]
Instead, follow the following steps:
- Download a complete bundle of the required repositories first, using your browser rather than darcs. These bundles are on http://darcs.haskell.org/ usually in three files of the form
- ghc-HEAD-2007-08-29-ghc-corelibs-testsuite.tar.bz2 (100Mbytes)
- ghc-HEAD-2007-08-29-ghc-corelibs.tar.bz2 (90 Mbytes)
- ghc-HEAD-2007-08-29-ghc.tar.bz2 (60 Mbytes)
Each of these is a subset of the previous one; pick the smallest one that has what you need. Note that you need the corelibs to build GHC; the only reason not to get a tarball that includes them is if you want to do --partial gets of them to save a little disk space. Of course, the dates may vary.
- Unpack the bundle, which will create a directory called ghc. You can rename this directory freely.
- Change into the new directory, and pull patches from the main GHC repository:
$ cd ghc $ darcs pull -aWe've had reports of Darcs crashing on Mac OS X in this step. If this happens, see the section on troubleshooting.
- Some core libraries might have been added to HEAD which were not in the last tarball. This means that after doing the last pull (which updates the list of core libraries) we need to do this to get any new libraries:
$ chmod +x darcs-all $ ./darcs-all get
- Now use the darcs-all script to pull patches from all the library repositories that came in the tarball, and the testsuite repository:
$ ./darcs-all pull -aThe command darcs-all automates the fetching of the repositories for the libraries.
If you omit step (3), then darcs-all will pull patches into the GHC repository too. If one of those patches modifies the darcs-all script itself, then bizarre things can happen (or at least: in the past, they could happen.) The safe thing to do is to get your main ghc repo up to date (step 3) and then run the script.
Getting more packages
The above will grab the "core" set of packages and the testsuite. This is the minimal set of packages required to bootstrap GHC. If you want to get a more comprehensive set of packages and include them in your GHC build, then you can say:
$ ./darcs-all --extra get
This isn't usually necessary: extra packages can be compiled and installed separately using Cabal, after you have built and installed GHC itself with its core packages. The "core" and "extra" packages are listed in DarcsRepositories.
If you want only one of the extra libraries, you can also use darcs to manually add it to the tree. Suppose you have downloaded a GHC source tree as advised above. Look up the directory name (i.e. the package name) of the library which you want to add. Descend into libraries and issue a darcs get <repo> (where <repo> is the repository of the package you want to get, ending in the package <name>). A later ./darcs-all pull now pulls updates not only for ghc and the core libraries, but also for any library you have added in this way.
$ cd libraries $ darcs get http://darcs.haskell.org/packages/<name> $ cd ..
Optionally, you might want to grab the testsuite (if you have not already got it) and nofib benchmark suite too, which also become sub-directories of ghc:
$ ./darcs-all --testsuite get $ ./darcs-all --nofib get
The full list of darcs repositories relating to GHC is at DarcsRepositories.
Getting a GHC source tree using git
NOTE: This is not yet supported. We currently recommend you use darcs to get a source tree.
git clone http://darcs.haskell.org/ghc.git ghc cd ghc ./sync-all --complete get sh boot ./configure && make
Note, on Windows you may have to change git's line-ending behaviour first:
git config --global core.autocrlf false
since this is a global setting, you probably want to change it back after cloning ghc, and then set it locally for the GHC repo(s).
Getting a branch
The above instructions will get the HEAD - the main trunk of GHC development. There are also branches, from which stable releases are made. The active branches are listed on DarcsRepositories.
To get a branch, add the branch name after http://darcs.haskell.org/. For example, to get the ghc-6.6 branch, you would first say
$ darcs get --partial http://darcs.haskell.org/ghc-6.6/ghc
and then use darcs-all as above to get the rest of the respositories.
Pulling new patches
To update your tree from the master repositories, the quickest way is to use the darcs-all script:
$ ./darcs-all pull -a
See Building/Rebuilding for how to update your build after pulling patches.
Mac OS X
getCurrentDirectory: resource exhausted (Too many open files)
By default, Mac OS X limits the number of open files to 256. This may cause problems when applying patches in step 3 of Getting a GHC source tree using darcs with darcs 1.0.9.
$ darcs pull -a Pulling from "http://darcs.haskell.org/ghc"... This is the GHC darcs repository (HEAD branch) For more information, visit the GHC developer wiki at http://hackage.haskell.org/trac/ghc ********************** darcs: getCurrentDirectory: resource exhausted (Too many open files)
If this happens, try increasing the number of open files allowed by typing in $ ulimit -n unlimited and try pulling again. If this fails, close all terminal windows, restart Terminal.app, and try again.
If this still doesn't work, try pulling 100 patches at a time using the darcs pull command (notice the lack of the -a flag). Hold down 'y' until 100 or so patches are accepted, then hit 'd' to skip the rest; repeat until all patches are applied. If this fails, try with less than 100 patches at a time (e.g., 50).
This issue has been reported as issue 560 in the darcs bug tracking system.
The default Mac OS X files systems (HFS+) is case-insensitive and darcs is case sensitive. While this ususally doesn't cause any problems, occassionally a Unapplicable patch error can occur. It's possible to work around this by using Disk Utility to create a case sensitive file system and apply the patches inside of it. To do this:
- Open /Applications/Utilities/Disk Utility.
- Make sure that none of the images/disks on the left are highlighted/selected. If any are, <Cmd>+Click them to unselect them.
- Click the "New Image" button.
- Set the "Volume Format" to "Mac OS X Extended (Case Sensitive)".
- Set "Encryption" to "None".
- Set "Partitions" to "Single Partition - Apple Partition Map"
- Set "Image Format" to "sparse disk image".
- Set "Volume Size" to "Custom..." and select an appropriately large size. Sparse images only take up as much space is as needed, plus a little overhead, so it's better to overestimate than underestimate. A 30 GB sparse image with no data in it takes up ~50 MB.
- Set "Volume Name" to something appropriate (e.g., "GHC").
- Set "Save As" to something appropriate (e.g., "GHC Disk").
- Click the "Create" button.
This creates a file with a .sparseimage extension (e.g., GHC Disk.sparseimage) at the location that was set in step 10 and automatically mounts it. The partition can be accessed through the /Volumes folder (e.g., /Volumes/GHC). This partition behaves exactly like any other Apple partition except that it's case sensitive and darcs can apply the patches it couldn't on the case insensitive file system. After the patches have been applied, the repository can be copied to the normal file system, the partition can be unmounted, and the sparse image can be deleted.
dash vs bash
In Ubuntu 6.10 the default system shell /bin/sh was changed to dash (The Debian Almquist Shell) instead of bash, see DashAsBinSh. This has been reported to break the GHC build. Until the GHC scripts are updated, the easiest way to fix this problem is to (as root) change the /bin/sh link back to /bin/bash. There should be minimal effect on the rest of the system, bar a small speed penalty for script heavy processes due to bash slowness.