When not on Windows, the `configureFlags` attr of `libmpc` is set to
`(drv.configureFlags or [])`. Since `drv.configureFlags` seems to be equal to
`["--enable-static" "--disable-shared"]` (at least on my machine),
`configureFlags` appears to be merged with itself and in the end, it is equal
to:
`["--enable-static" "--disable-shared" "--enable-static" "--disable-shared"]`.
You can verify this by comparing the derivations of `libmpc` with and without
this patch.
This changes the derivation of `libmpc` as well the derivation of all dependent
packages, like `gcc`, causing cache misses from https://cache.nixos.org/.
Because these packages are built and stored in the IOHK cache, users don't
notice this, until they use a different version of `nixpkgs` than the one pinned
by `haskell.nix`, e.g., one with a different version of `glibc` so that the IOHK
cache cannot be used. This results in `gcc` and other packages being built from
scratch instead of being downloaded from https://cache.nixos.org/.
Fix this by hoisting the conditional one level higher so that `overrideAttrs`
isn't even called on non-Windows OSes. Do the same for `mpfr` for consistency.
I haven't tested this on Windows. I'm not sure whether I have hoisted the
conditional too high, see the first comment in the file.
We include the /bin directory of `component.libs` in `extra-lib-dirs` on windows, but not `components.pkgconfig`. This causes confusing differences between the behavior depending on how a dependency was specified in the `.cabal` file or added in a module. If it wounds up in `components.libs` the need for DLLs would propagate correctly, but if it was only in `componets.pkgconfig` DLLs would not be included when building TH code and did not get symlinked to `exe` component output /bin dirs.
* Downgrades the error to a warning.
* Adds `filterPath` as a way to disable filtering to have caching work between Nix <2.4 and >=2.4.
* Disables filtering on `haskell-nix.hackage-project` based functions (should make all the GHC derivations the same).
I think it would also be possible to make a `filterPath` implementation that recursively used `builtins.readDir` and called the `filter` function to implement filtering on Nix <2.4, but I am not sure if it is worth it.
Anyone that needs the old behaviour for project packages (consistent filtering between <2.4 and >=2.4, but not between store and local) replace:
```
project = pkgs.haskell-nix.cabalProject {
src = pkgs.haskell-nix.haskellLib.cleanGit {
src = ./.;
};
};
```
```
project = pkgs.haskell-nix.cabalProject {
src = pkgs.haskell-nix.haskellLib.cleanGit {
src = {
outPath = ./.;
filterPath = { path, ... }@args:
if builtins.hasContext (toString path) then path else builtins.path args;
};
};
};
```
This is a better fix to the problem of making DLLs available to the process running in wine that is used to evaluate TH code when cross compiling for Windows.
Also fixes macOS loadArchive in TH for ghc 9
Co-authored-by: Michael Peyton Jones <michael.peyton-jones@iohk.io>
In recent nix, builtins.path works in restricted eval mode.
Therefore canCleanSource is not required anymore.
follow up on #1403
* add comment on hydra overlay
* throw error on outdated nix version
Currently we often get confusing errors (infinite loops looking for impossible materialization or GHC build errors) when trying to build a GHC version that is never going to work on the platform we are building for. In particular it is common to on M1 Macs to forget to include `--system x86_64-darwin` and wind up with a confusing error.
With this change the error is more clear:
```
hamish@Hamishs-MBP haskell.nix % nix-build -A pkgs-unstable.haskell-nix.compiler.ghc8105
error: Desired GHC (8.10.5) is older than the bootstrap GHC (8.10.7) for this platform (aarch64-apple-darwin).
```
`nix.binaryCachePublicKeys` and `nix.binaryCaches` are now deprecated in NixOS: the current names for these settings are `nix.settings.trusted-public-keys` and `nix.settings.substituters`, respectively