... | @@ -26,6 +26,8 @@ Travis CI is a free-for-open-source continuous integration service. When your pa |
... | @@ -26,6 +26,8 @@ Travis CI is a free-for-open-source continuous integration service. When your pa |
|
|
|
|
|
### Locally
|
|
### Locally
|
|
|
|
|
|
|
|
The following commands will make a clean build of GHC and its libraries using Hadrian, package them up in a binary distribution that is then installed, and run the testsuite against the installed bindist.
|
|
|
|
|
|
- Get a repository containing the latest HEAD, the patches you want to push, and no other patches or unrecorded changes.
|
|
- Get a repository containing the latest HEAD, the patches you want to push, and no other patches or unrecorded changes.
|
|
|
|
|
|
- (Optional) Create a git worktree and cd there, so that your future non-validation builds are not affected and don't need to run from scratch:
|
|
- (Optional) Create a git worktree and cd there, so that your future non-validation builds are not affected and don't need to run from scratch:
|
... | @@ -45,7 +47,7 @@ Travis CI is a free-for-open-source continuous integration service. When your pa |
... | @@ -45,7 +47,7 @@ Travis CI is a free-for-open-source continuous integration service. When your pa |
|
- Depending on the nature of the changes, more testing might be sensible. e.g. if possible, build system changes should be tested on Linux, Mac OS X and Windows machines. Look at the full documentation for the [test suite](building/running-tests).
|
|
- Depending on the nature of the changes, more testing might be sensible. e.g. if possible, build system changes should be tested on Linux, Mac OS X and Windows machines. Look at the full documentation for the [test suite](building/running-tests).
|
|
|
|
|
|
|
|
|
|
validate runs `make -j$THREADS`, where by default `THREADS` is the number of
|
|
validate runs `hadrian -j$THREADS`, where by default `THREADS` is the number of
|
|
cpus your computer has +1. You can set the environment variable `THREADS` to
|
|
cpus your computer has +1. You can set the environment variable `THREADS` to
|
|
override this. For a sequential build (and also test run) you would for example use
|
|
override this. For a sequential build (and also test run) you would for example use
|
|
|
|
|
... | @@ -53,17 +55,17 @@ override this. For a sequential build (and also test run) you would for example |
... | @@ -53,17 +55,17 @@ override this. For a sequential build (and also test run) you would for example |
|
THREADS=1 ./validate
|
|
THREADS=1 ./validate
|
|
```
|
|
```
|
|
|
|
|
|
|
|
If you hit a hadrian bug or want to specifically use the make build system to build and package up GHC for some other reason, you can pass `--legacy` to the `validate` script.
|
|
|
|
|
|
## More details on the validate script
|
|
## More details on the validate script
|
|
|
|
|
|
### Configuration files
|
|
### Make mode (`--legacy`) configuration
|
|
|
|
|
|
`validate` usually starts by `make maintainer-clean` to make sure that everything builds from scratch. Furthermore, it ignores the build settings you have put in `mk/build.mk`, and instead uses those in `mk/flavours/validate.mk`.
|
|
`validate` usually starts by `make maintainer-clean` to make sure that everything builds from scratch. Furthermore, it ignores the build settings you have put in `mk/build.mk`, and instead uses those in `mk/flavours/validate.mk`.
|
|
|
|
|
|
|
|
|
|
You may want to validate a different configuration, e.g. with `GhcLibWays = p`. To do that, create a new file `mk/validate.mk` and put those settings in there. Settings in `mk/validate.mk` override those from `mk/flavours/validate.mk` (which in turn override those from `mk/config.mk`).
|
|
You may want to validate a different configuration, e.g. with `GhcLibWays = p`. To do that, create a new file `mk/validate.mk` and put those settings in there. Settings in `mk/validate.mk` override those from `mk/flavours/validate.mk` (which in turn override those from `mk/config.mk`).
|
|
|
|
|
|
|
|
After you run `validate --legacy` your tree will continue to use the same settings. The way to get back to using your own `build.mk` is to run `make distclean`. Less brutally, simply remove the file `mk/are-validating.mk`.
|
|
After you run `validate` your tree will continue to use the same settings. The way to get back to using your own `build.mk` is to run `make distclean`. Less brutally, simply remove the file `mk/are-validating.mk`.
|
|
|
|
|
|
|
|
### Flags
|
|
### Flags
|
|
|
|
|
... | @@ -79,6 +81,7 @@ In order to save time while debugging problems revealed by validate, the validat |
... | @@ -79,6 +81,7 @@ In order to save time while debugging problems revealed by validate, the validat |
|
- **`--quiet`**: show less output. By default all shell commands are shown so you can copy/paste and rerun them on failures.
|
|
- **`--quiet`**: show less output. By default all shell commands are shown so you can copy/paste and rerun them on failures.
|
|
- **`--help`**: show help.
|
|
- **`--help`**: show help.
|
|
|
|
|
|
|
|
|
|
### Validate has failing tests without any local patches; what do I do?
|
|
### Validate has failing tests without any local patches; what do I do?
|
|
|
|
|
|
|
|
|
... | | ... | |