| ... | ... | @@ -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:ben@well-typed.com>:
|
|
|
|
|
|
|
|
* 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
|
|
|
|
project.
|
|
|
|
|
|
|
|
* 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
|
|
|
|
rerunning `configure`.
|
|
|
|
|
|
|
|
* 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
|
|
|
|
`_build/ghc-stage1` target)
|
|
|
|
|
|
|
|
* 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
|
|
|
|
need.
|
|
|
|
|
|
|
|
* 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
|
|
|
|
another.
|
|
|
|
|
|
|
|
## Hadrian.settings
|
|
|
|
|
|
|
|
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:
|
| ... | ... | @@ -87,7 +131,7 @@ stage1.*.ghc.hs.opts += -g3 |
|
|
|
stage1.*.cabal.configure.opts += --disable-library-stripping --disable-executable-stripping
|
|
|
|
```
|
|
|
|
|
|
|
|
### Building RTS with debug symbols
|
|
|
|
### Building the RTS with debug symbols
|
|
|
|
|
|
|
|
Typically the `-debug` RTS is built with debug symbols enabled. However, it also includes
|
|
|
|
```
|
| ... | ... | |
