wiki:Repositories

Version 47 (modified by jstolarek, 16 months ago) (diff)

Fixed a typo

GHC Repositories

This page lists the active repositories relating to GHC. For instructions on actually getting a GHC source tree, see Getting The Sources.

For read-only browsing, you can use the:

GHC's repos use git; see Git Working Conventions. For darcs-related stuff see Darcs To Git and Git For Darcs Users.

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" is 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. All others are installed with GHC. See the libraries page for more info.
  • GHC repo: in every case there is a repo on http://darcs.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)
Location in tree Upstream repo? Reqd to build? Installed? GHC repo http://darcs.haskell.org/...
. (ghc itself) ghc.git/
ghc-tarballs no ghc-tarballs.git/
utils/hsc2hs utils/hsc2hs.git/
utils/haddock haddock.git
testsuite testsuite.git
nofib nofib.git
libraries/array packages/array.git/
libraries/base packages/base.git/
libraries/binary yes packages/.git/
libraries/bytestring yes packages/bytestring.git/
libraries/Cabal yes packages/Cabal.git/
libraries/containers yes packages/containers.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/mtl yes no no packages/mtl.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/random yes packages/random.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 packages/xhtml.git/
libraries/primitive yes packages/primitive.git/
libraries/vector yes packages/vector.git/
libraries/dph packages/dph.git/
libraries/deepseq no no packages/deepseq.git/
libraries/parallel no no packages/parallel.git/
libraries/stm no no 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:

  • "-": boot libraries, necessary to build GHC
  • "testsuite": GHC's regression tests, not necessary for a build, but is necessary if you're working on GHC
  • "nofib": GHC's nofib benchmark suite
  • "dph": packages for Data Parallel Haskell, which is not shipped with GHC but we test all changes to GHC against these repositories so they are usually included in a checked-out source tree.
  • "extra": extra packages you might want to include in a build (the parallel package, for example), but aren't necessary to get a working GHC.

See the Commentary/Libraries page for more information about GHC's libraries.

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.

Branches

For how we manage release branches, see WorkingConventions/Releases.

The following branches are active:

7.4 Branch
To switch to this branch run:
$ ./sync-all checkout ghc-7.4