Overview

A GHC source tree is made of a collection of repositories. The script sync-all knows how to apply git commands to the whole collection of repositories at once, for example to pull changes from the upstream repositories.

Here is a list of the repositories that GHC uses. The columns have the following meaning

Location in tree: where in the source tree this repository sits.

Upstream repo?: if "yes", this library is maintained by someone else,
and its master repo is somewhere else. See Repositories/Upstream.

Reqd to build?: is "no" if this library is not required to build GHC. We have a few of these because we use them for tests and suchlike.

Installed?: is "no" if the library is not installed in a GHC installation, and "extra" if it is only installed if InstallExtraPackages is YES. All others are installed with GHC. See the libraries page for more info.

GHC repo: in every case there is a repo on http://git.haskell.org/, which contains the bits we use for building GHC every night. For libraries with upstream repos, this is just a lagging mirror of the master (see Repositories/Upstream). The read-only HTTP URL for the repo is http://git.haskell.org/<table-entry>. To get a read/write URL, replace HTTP prefix http://git.haskell.org with the SSH prefix ssh://[email protected].

Note: http://darcs.haskell.org/libraries is actually a ​symlink to http://darcs.haskell.org/packages, therefore they are just synonyms. (For historical reasons.). Moreover, the Git repositories hosted on ​http://git.haskell.org have an 301-redirect installed on their old ​http://darcs.haskell.org locations.

Location in tree

Upstream repo?

Reqd to build?

Installed?

GHC repo http://git.haskell.org/...

. (ghc itself)

ghc.git

ghc-tarballs

N/A

ghc-tarballs.git

utils/hsc2hs

hsc2hs.git

utils/haddock

haddock.git

testsuite

N/A

testsuite.git

nofib

N/A

nofib.git

libraries/array

packages/array.git

libraries/base

packages/base.git

libraries/binary

yes

packages/binary.git

libraries/bytestring

yes

packages/bytestring.git

libraries/Cabal

yes

packages/Cabal.git

libraries/containers

yes

packages/containers.git

libraries/deepseq

packages/deepseq.git

libraries/directory

packages/directory.git

libraries/extensible-exceptions

packages/extensible-exceptions.git

libraries/filepath

packages/filepath.git

libraries/ghc-prim

packages/ghc-prim.git

libraries/haskeline

yes

no

packages/haskeline.git

libraries/haskell98

packages/haskell98.git

libraries/haskell2010

packages/haskell2010.git

libraries/hoopl

packages/hoopl.git

libraries/hpc

packages/hpc.git

libraries/integer-gmp

packages/integer-gmp.git

libraries/integer-simple

packages/integer-simple.git

libraries/old-locale

packages/old-locale.git

libraries/old-time

packages/old-time.git

libraries/pretty

yes

packages/pretty.git

libraries/process

packages/process.git

libraries/template-haskell

packages/template-haskell.git

libraries/terminfo

yes

no

packages/terminfo.git

libraries/time

yes

packages/time.git

libraries/transformers

yes

packages/transformers.git

libraries/unix

packages/unix.git

libraries/utf8-string

yes

packages/utf8-string.git

libraries/Win32

yes

packages/Win32.git

libraries/xhtml

yes

no

packages/xhtml.git

libraries/random

yes

extra

packages/random.git

libraries/primitive

yes

extra

packages/primitive.git

libraries/vector

yes

extra

packages/vector.git

libraries/dph

extra

packages/dph.git

libraries/parallel

no

extra

packages/parallel.git

libraries/stm

no

extra

packages/stm.git

The 'packages' file

The master list of repositories is in the file packages, and this is where the sync-all script finds out about which repositories make up the complete tree. It duplicates the information in the above table; indeed, it is really the authoritative version (so complain if the table and file differ!).

The "tag" in the master table in packages has the following significance:

Modifying local packages

For libraries for which there is no upstream repo, you can modify the GHC repo above directly.

When making a change to a library, you must also update the version
number if appropriate. Version number in the repositories should be
maintained such that, if the library were to be release as-is, then
they would have the correct version number. For example, if the last
release of a library was 1.2.0.3 and you remove a function from it
then, as per the
​Package versioning policy,
the version number should be bumped to 1.3.0.0. If it is already
1.3.0.0 or higher then no further change is necessary. In order to
make this easier, the version line in the .cabal file should be
followed by a comment such as

-- GHC 7.6.1 released with 1.2.0.3

Mirroring new packages to GitHub

Currently, all our repositories are being mirrored to GitHub by GitHub themselves. If you wish to add/remove a repository you need to email GitHub support at support@… and ask them to do it. Currently there is no way to administer this ourselves.