@@ -74,6 +74,50 @@ To speed up testing of your modified GHC, you may want to add these options to `
-`build test` lets you run the testsuite; see [`hadrian/doc/testsuite.md`](https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/testsuite.md) for detailed explanations about the `test` rule and the options it supports.
- Hadrian supports `build docs`, `build source-dist`, `build binary-dist`, `build stage<N>:lib:<library name>`, `build stage<N>:exe:<executable name>`, `build clean`, `build nofib` and more. See `build --help` for a more detailed listing, as well as all the aforementioned documents for detailed explanations about the build rules and command line options supported by Hadrian.
## Making efficient use of time
Below are general tips for making efficient use of your time while working on GHC from [Ben](mailto:firstname.lastname@example.org>:
* Be careful about pulling/rebase. I generally pick a base commit to build
off of and rebase fairly sparingly: Having to stop what I'm doing
to wait for full rebuild is an easy way to lose momentum.
* Avoid switching branches; I generally have a GHC tree per on-going
* Similarly, be careful about doing things that would incur
significant amounts of rebuilding. This includes:
* After modifying, e.g., `compiler/ghc.cabal.in` (e.g. to add a new
module to GHC), modify `compiler/ghc.cabal` manually instead of
* Take advantage of Hadrian's `--freeze1` flag
* Use `hadrian/ghci` to typecheck changes
* Use the stage1 compiler instead of stage2 to smoke-test changes when
possible. (specifically, using the script generated by Hadrian's
* Use the right build flavour for the task at hand: If I don't need a
performant compiler and am confident that I can get by without
testsuite validation, use `quick`. Otherwise, plan ahead for what you
* Run the fraction of the testsuite that is relevant to your change.
Hadrian's `--test-way` and `--only` flags are your friends.
* Take advantage of CI. At the moment we have a fair amount of CI
capacity. If you think that your change is close to working, you can
open an MR and start a build locally. If it fails, iterate on just the
failing testcases locally.
* Task-level parallelism. Admittedly, this is harder when you are
working as a hobby, but I often have two or three projects on-going
at one time. While one tree is building I try to make progress on
As described in [`hadrian/doc/user-settings.md`](https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/user-settings.md) the configuration of the build can be modified via `_build/hadrian.settings`. Here are a few useful snippets to accomplish common tasks: