Currently in order to support submodules all the directories are included (but not all files) when building the whitelist. This is done because we need the `.git` files (or directories) the contain to be present when we run `git ls-files --recurse-submodules`.
Including every directory causes two performance issues:
* Creating a directory in your repo (even empty one not added to git at all) will require the whitelist to be recalculated.
* Recalculation of the whiltelist may be slowed down if there are a large number of directories. In particular `lstat` is called on every file (probably to get the right `type` to pass to the filter function).
The fix is to use `git submodule status --recursive` to get a list of all the submodule directories. Then the `.git` files (or directories) in them can be included. This has to be repeated until all the submodules are known (as `--recursive` will not see the submodules until the parent module is included).
It looks like `callCabalProjectToNix` can fail in its `cabal` call with the following error:
```
open: permission denied (Permission denied)
```
Then running the same derivation locally works. If the error is deferred there is no easy way on hydra to retry.
This change makes it so only solvers errors (which should hopefully be deterministic) are deferred. All other errors will go back to being eval time errors meaning they should be automatically retried at the next hydra eval.
* Use emscripten branch of GHCJS for 8.6
* Adds release-linux-only.nix (for hydra with no mac builders)
* Sets HOME to a temp dir once per derivation to help performance of emcc
* Updates materialization
* Uses symlinks to reduce ghc derivation size for wrapped ghcjs
* Removes compiler-nix-name test
This test checked that the default compiler was overridden by the
compiler-nix-name arg. There is no default any more.
The GHCJS branches used include fixes for:
* hs$ret_1 typo (should be hs$ret1)
* A bignum issue
* Delays cabal configure errors until after evaluation when possible.
* Avoids rerunning long `cabal configure` if we already know it will fail.
* Provides a way to get a component from a package or project using a `cabal` like reference.
Code using the `tool` functions will automatically use `getComponent`.
For `(hackage-package {...}).components.library` is also ok.
```
# Consider changing hackage-package use:
(pkgs.haskell-nix.hackage-package {...}).components.exes.something
(pkgs.haskell-nix.hackage-package {...}).getComponent "exe:something"
# For any cabal project:
project.hsPkgs.somepackage.components.exes.something
project.getComponent "somepackage:exe:something"
# or do it in two steps
(project.getPackage "somepackage").getComponent "exe:something"
```
The reason for the new function is that we cannot provide the attribute interface without knowing that packages are in the project first.
Here is how the `cabal configure` error output is handled:
* The `plan-nix` derivation builds even if `cabal configure` fails.
* When it fails, it copies `failed-cabal-configure.nix` to the `$out/default.nix` along with a copy of the `cabal configure` output.
* When `failed-cabal-configure.nix` is imported and used in any way it writes the `cabal configure` output with `__trace` so it will always be visible.
* Instead of a `plan` the imported nix contains a `configurationError` pointing the `cabal configure` output.
* The intermediate functions `configurationError` and bubble it up to where it is needed.
* `getPackage` returns a mostly empty proxy for a real package when there is a `configurationError`
* The `getComponent` function always returns a derivation, but the version in the proxy writes the `cabal configure` output to stdout and calls `exit 1` (so that it will never build).
Issues with `cabal.project.freeze` files can be tricky to debug.
While it is possible to run without a freeze file and look
at the `plan-nix` or `plan-nix.json` (the `plan.json`) created when
haskell.nix configured the project, it would be nice to
also have the output of `cabal freeze` as it will be in the
correct format and contains a different subset of `plan.json`
than the `plan-nix`.
This might also be useful for automating updating of `.freeze`
files.
This combined with setting the `use-pkg-config` flag on `postgresql-libpq` should get it compiling. There is still a problem with `openssl` that requires a `module` to fix the linking of executables.
Add the following to the `cabal.project` file or to `cabalProjectLocal`:
```
package postgresql-libpq
flags: +use-pkg-config
```
Include a module like this one to include `openssl` in the linker arguments:
```nix
{
modules = [(
{pkgs, ...}: final.lib.mkIf pkgs.stdenv.hostPlatform.isMusl {
# The order of -lssl and -lcrypto is important here
packages.postgrest.configureFlags = [
"--ghc-option=-optl=-lssl"
"--ghc-option=-optl=-lcrypto"
"--ghc-option=-optl=-L${pkgs.openssl.out}/lib"
];
})];
}
```
This PR also adds a "hackage quirk" for `postgrest` to that makes these changes for `postgrest` automatically when built it as a `tool` or with `hackage-package`.
Unfortunately we do not have a good way to avoid the need make these changes.
This PR adds a `flake` function to haskell.nix projects. It can
be used to transform the outputs of project into a flattened structure
that can be used to make a `flake.nix` file for your project.
Because the nix code and commands used are different a lot of stuff in
the getting-started.md will not work with a `flake.nix`. So instead
of trying to add a flake section to that guide this PR adds a new
version for Nix Flake users.
As of d014079 (#953), haskell.nix internals (such as unapplied
./overlays, sources, etc) are not exported in flake.nix. This makes
it harder to override things when using haskell.nix as a flake.
The use-case I have in mind is to pin haskell.nix itself to prevent
unnecessary GHC rebuilds/redownloads and update only
hackage&stackage. This could be done with a following overlay:
(haskell-nix.overlays {
sourcesOverride = haskell-nix.sources // {
inherit hackage stackage;
};
}).combined-eval-on-build
However, this is not the case as of the aforementioned commit. Now, to
do this one has to import ./nix/sources.json, reimplementing what's
already done in haskell.nix, and also import ./overlays. With this
commit, previous snippet turns into the following:
(haskell-nix.internal.overlaysOverrideable {
sourcesOverride = haskell-nix.internal.sources // {
inherit hackage stackage;
};
}).combined-eval-on-build
`nix flake check` will now warn us of "unknown flake output
'internal'", but I think it is fine (e.g. nixpkgs has an unknown flake
output as well)
* Add `.debug` to build any component with DWARF dugug info on linux
(ghc >=8.10.2).
* Pass `enableDWARF` to `shellFor` for to get a shell where all the
components are the `.debug` ones.
`ghcOptions` has been moved from package and is now a list of strings.
old: packages.x.package.ghcOptions = "someGHCoption";
new: packages.x.ghcOptions = ["someGHCoption"];
To specify ghcOptions for all packages:
ghcOptions = ["someGHCoption"];
For a single component:
packages.x.compoents.library.ghcOptions = ["someGHCoption"];
