GHC Repositories

This page lists the active repositories relating to GHC. These are Git repositories, so you should learn about Git first. For instructions on actually getting a GHC source tree, see Getting The Sources. For information on using these repositories (via submodules), see the Submodules page.

gitlab.haskell.org

Many GHC repositories and its core packages can be found at gitlab.haskell.org, which can be accessed via,

• https://gitlab.haskell.org
• git://gitlab.haskell.org
• git@gitlab.haskell.org (for those with commit access)

The SSH host keys of gitlab.haskell.org are,

• ecdsa: 91:4e:95:fa:2e:34:6c:ba:68:af:71:29:ba:66:12:b0
• rsa: 08:63:b5:86:3e:ae:e2:3c:b1:ea:c6:05:2d:71:db:5a
• 4096 MD5:1f:cf:c1:2b:ec:8f:6f:b2:8a:75:43:6a:af:1e:50:aa gitlab.haskell.org (RSA)
• 256 MD5:51:94:9e:ef:c4:b8:59:d0:f4:a2:8f:4e:c0:30:fe:5e gitlab.haskell.org (ED25519)

as reported by ssh-keyscan and ssh-keygen -l -E md5.

These are also mirrored to GitHub under the ghc organization. Note that we do not use GitHub as the primary upstream since GitHub does not allow us to use Git hooks. These hooks are invaluable for verifying consistency between submodules (e.g. that the ghc repository refers only to submodule commits which are available upstream, see #8251 (closed)).

Repository listing

The GHC source code uses many related sub-repositories, which are needed for external dependencies during the build, or tools that are included in the build. Every single upstream repository we track is tracked with a git submodule, so that for any particular GHC commit, Git's submodule mechanism makes it possible to check out exactly the right version of each sub-repository.

Some submodules are maintained by GHC HQ, and some by their parties. You can find out by looking at the .cabal file.

Here is the setup in more detail:

• Upstream repo.

  • Each submodule has an upstream, or master, repository.
  • Patches to the submodule must be pushed to the upstream repo.
  • The authoritative info for the upstream URL is in the file packages in the root directory of the main GHC repo.
  • If the packages file gives an upstream URL of "-", authoritative info is in the file .gitmodules.

• Mirror repo.

  • If the upstream repo is not at gitlab.haskell.org, then we maintain a mirror repo at gitlab.haskell.org.
  • Pulling and cloning happens from the mirror repo, so that we can build GHC without relying on lots of other machines being up.
  • The mirror should be updated from the upstream repo at least every minute or so.
  • The authoritative info for the mirror URL is in the file .gitmodules in the root directory of the main GHC repo.

• Upstream GHC branch (see table below).

  • As GHC's HEAD moves on between releases, there is often a need to update a library in sync. Each library has a named branch, the upstream GHC branch to which patches can be pushed.
  • If the library author is actively developing the library, he or she will typically do so on a different branch from the upstream GHC branch, to avoid discombobulating GHC HEAD.

• Updating sub-repos. If you want to update a library to track some change in GHC HEAD, the sequence typically looks like this:

  • cd libraries/parallel
  • git checkout master, or whatever the "upstream GHC branch" is called. Previously the submodule would be in a detached-head state.
  • Make modifications to the library
  • git push: push the patch to the upstream repo (may need to ask the maintainer to do this)
  • cd ../..: back into the GHC directory
  • git add libraries/parallel: record the new library commit in the main GHC repo.
  • git push, with a commit message mentioning the word "submodule"

  More details in the Submodules page

Here are the submodules we use, and where their upstreams point:

(NB this table is out of date but see the note below about the packages file for more information)

• [1] These libraries are not installed in the resulting compiler when you do make install

• [2] These libraries are not required to build the compiler, but may be used for tests or other libraries. Right now, most of these are based on whether you build DPH. At the moment, DPH is turned off. To build these libraries, set BUILD_DPH=YES in mk/build.mk. You can skip haddock by setting HADDOCK_DOCS=NO in mk/build.mk. TODO Explain how to skip deepseq, since it seems to only be used for tests.

The table above is maintained manually and can sometimes get out of sync. If in doubt, the primary data source is the packages file in the top-level ghc.git repo folder.

transformers

The transformers library's upstream uses darcs. In order to track this library, we maintain a git mirror (http://gitlab.haskell.org/darcs-mirrors/transformers.git) generated using darcs export mirror which is periodically updated by gitlab.haskell.org. However, due to the tendency for the import mechanism to produce non-fast-forward branches, the commits in this mirror need to be manually pulled into the submodule used by GHC, git@gitlab.haskell.org:packages/transformers.

Infrastructure

There are a also a variety of repositories which contain infrastructure-related bits. These include,

• https://github.com/haskell-infra/phabricator: This is the current state of the tree running our Phabricator instance.
• https://github.com/haskell-infra/ghc-homepage: This contains the sources for https://www.haskell.org/ghc/
• https://github.com/haskell-infra/libphutil-haskell: This is a small libphutil extension providing GHC-specific functionality to Phabricator
• https://github.com/haskell-infra/trac: This is the slightly patched Trac version which drives GHC's Trac.