When trying to build haskell packages from local source using nix (
source code you have used `git clone` to retrieve and have modified)
it is often annoying that small changes can trigger a lot of components
to be built unnecessarily. For instance if you change the code for
a test in a package it will often trigger builds of the library and
all its dependencies.
To avoid this problem we could manually set up `cleanSourceWith` calls
in nix to filter out files that are not need, but to do this every
component would be difficult and error prone.
This change automates this process using the information in the
packages `.cabal` file to filter the source of each component
automatically when using `callCabalPlanToNix` (we should be able to
add it to `callStackToNix` too).
## How does it work?
* A new version on `cleanSourceWith` is used that adds a `subDir`
argument. It allows descending into a subdirectory to compose with
cleaning the source.
* A new `--full` argument is passed to `plan-to-nix` by
`callCabalPlanToNix` telling it to output extra information about
the cabal packages in the plan (directories and filenames).
* `callCabalProjectToNix` uses the new `subDir` argument of
`cleanSourceWith` when setting the packageSrc.
* `comp-builder.nix` and `setup-builder.nix` use a new
`cleanCabalComponent` function to further clean the packageSrc
using the new information in the `package` and `component`.
## hpack wildcards
`package.yaml` files can include wild cards and these are not handled
yet (they do not map to anything in the `.cabal` file and so are lost).
They will need to be added manually to the appropriate field
(eg. `packages.xyz.package.dataFiles`)
If your hpack file does not contain wildcards or if you are willing to
add the wildcards entries manually in nix it is still useful to
enable cleaning on hpack.
For example:
```
packages.ghc-toolkit.package.cleanHpack = true;
packages.ghc-toolkit.components.library.extraSrcFiles = [
"genapply/**/**"
"boot-libs/**/**"
"ghc-libdir/**/**"
];
```
* Better defaults (doExactConfig = true; non-reinstallable lib:ghc)
Disabling haddocks by default has unintended consequences, as such we'll wait for the `.doc` derivation to solve this.
Fixes#201, #191
* Add a custom error message for a missing stack resolver
* Make mkCabalProjectPkgSet robust to missing Hackage patches
* Add error for component prefix lookup
* Add a custom error for a missing GHC
When using stackage as a baseline via stack-to-nix, we usually
assume stackage to be the base, and some augemnetation via
extra-dependencies and packages in the `stack.yaml` file.
To achive this we extend the package-set builder by allowing
a list of additional sets of package to speicied. These are then
folded onto the base package set.
As stackage seems to define the `rts` package as well, we force
`rts-1.0` to be null ontop of our hackage database. As of
today (November 7th, 2018) there is no way of building the rts outside
of GHC; and as such no way to ever get the rts package onto hackage.
Once this package is *on* hackage, we can drop the hack.