We have been disabling terminfo in our GHC builds for cross compilers (windows and musl). This leads to an interesting problem when we `cabal configure` a project that needs `ghc`. The resulting `plan.json` might suggest that we should use the preexisting `ghc`. When it does though it does not include the `flags` needed to build it.
One fix would be to default the the `ghc` `terminfo` flag to `false` for cross compilers.
It turns out though that the reason we could not get the `terminfo` package to work with our cross compilers was that we were providing the `hostPlatform` `ncursers` when we needed the `targetPlatform` `ncursers`. Fixing that makes the cross compilers more like the native ones.
Also stops pinning wine to 5.4 on macOS (pinned version does not work there)
Fixes Windows cross compilation for GHC 9.0 and 9.2.
Updates wine to use the version that is included with the chosen Nixpkgs (it used to be pinned to an older version).
Moves the configuration of the GHC source into the GHC derivation. This should make adding Hadrian support easier.
Propagates library dependences (not just pkgconfig ones) on windows so that any DLLs in those libraries can be copied for TH evaluation and to the `/bin` directory of executable components.
Adds gcc and mfcgthreads as library dependencies on Windows so that the DLLs they include will be found.
Use `$pkgsHostTarget` (instead of `ghc-pkg`) to find all the DLLs can copy them to the `/bin` directory of executable components.
Adds support for __int128_t and __uint128_t to language-c to fix aarch64-darwin builds.
Fixed reinstalling packages that come with patched versions in ghcjs.
This change updates to the latest `nix-tools` to get the following fixes (there are 3 PRs in nix-tools, but just the one in haskell.nix to avoid having to update the materialized files multiple times):
## Better support for source repository packages
* https://github.com/input-output-hk/nix-tools/pull/107
Currently these are replaced by the `cabalProject` functions with regular `packages:` before running cabal configure. Cabal does not treat these the same (the setting of `tests:` and `benchmarks:` in the `cabal.project` file):
* The plan found by `cabalProject` may not match the one used when running `cabal`.
* The performance of the solver may not be consistent with running `cabal`.
This change replaces `source-repository-package` with another `source-repository-package` pointing at a minimal git repo.
## Only include planned components
* https://github.com/input-output-hk/nix-tools/pull/108
Only the components in the `plan.json` are now included in the haskell.nix cabal projects. This avoids missing dependencies attempting to build components that were not in the plan. Should fix#993.
## Pick latest packages
* https://github.com/input-output-hk/nix-tools/pull/109
When the same package occurs more than once in a `plan.json` file (perhaps because it is needed both by the project itself and by one of the `setup` dependencies or `build-tool-dependencies` of the project) the latest version will now be the one picked by haskell.nix. This is a work around for a common issue with `cabal-doctest` when cross compiling to windows (an old version of Win32 is used even if a newer one was required by the projects `constraints`).
* 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
See https://github.com/input-output-hk/nix-tools/pull/101
We should look up hsPkgs.${pkg-name}.components.exe.${component-name}
instead of including the package as a dependency.
Adding `hsPkgs.${pkg-name}` a tool it is not clear which executable in the package `haskell.nix` should choose.
Haskell.nix did not deal with this well and in fact it could lead to `nix-shell` crashing. For instance using `shellFor` to make a shell for building `haskell-language-server` with `cabal build` crashed as a dependency on `ghcide` the executable (by the `ghcide-bench` executable) caused infinite recursion. Allowing `ghcide-bench` to correctly depend just on `components.exes.ghcide` fixes this.
This PR also includes:
* Updated materialized files built with the new nix-tools and latest index-state
* Small update to GHCJS (pins happy) to fix issue that showed up when the materialization was updated
* A fix for the infinite recursion issue when updating materialized files (by adding ghc-boot-packages-unchecked).
* Performance fix for shellFor (checks just the names of component derivations when filtering).
Fixes ghcjs 8.6.5 and 8.8.4.
Uses emscripten for ghcjs 8.8 and adds scripts for building ghcjs 8.8.
Many fixes for ghcjs test failures.
Includes relocatableConfigFiles for making relocatable ghcjs bundles.
* ghc 8.10
* Adds/Updates/Removes materialization files
* Disable one-shot-kqueue-on-macos patch on ghc-8.10
* Test ghc883 and ghc8101 but only with nix 20.03
* Various smaller fixes.
This should fix the infinite recursion issue with #654
Co-authored-by: Lennart Spitzner <hexagoxel@hexagoxel.de>
This change improves the dummy ghc scripts by adding a bang pattern,
supporting `--version` and using bash case instead of lots of `elif`
Includes the same fixes for dummy-ghc-pkg
Although the default ghc used by haskell.nix is ghc 8.6.5 many of
the tools used in haskell.nix are still built with the boot compiler
ghc 8.4.4. These include
* haskell-nix.cabal-install
* haskell-nix.alex
* haskell-nix.happy
This change updates those to ghc 8.6.5 and includes materializations
for the new versions.
When cabal-install is built it is careful to disable materialization
checks on the version of itself used during the build to avoid
infinite recursion.
There was a version of nix-tools built with the boot ghc which was
only used when `checkMaterialization = true`. It was used for
the boot versions of alex, happy and hscolour. These have been update
to use the default (ghc 8.6.5) version of nix-tools and
checkMaterialization is forced off when they are being used to build
ghc. This means the materialization will only be checked for these
when they are built independently (they are included in the test set
via haskellNixRoots).
Three new arguments are added to `default.nix`:
* `defaultCompilerNixName` if not specified "ghc865" is used
* `checkMaterialization` makes it easier to switch on materialization checks
* `system` defaults to `builtins.currentSystem`
This change also moves the work needed for hydra eval to the eval
system using a new `evalPackages` feature. This includes:
* Fetching from git with `fetchgit`
* Building scripts with `runCommand` and `writeTextFile`
* `git ls-files` in `cleanGit`
* running `cabal v2-configure`
* copying materialized files (we are not sure why this is necessary but
if we do not `cp -r` the files nix will not load them on hydra)
Reduce size of `make-config-files.nix` strings by around 80%.
These are unlikely to be the cause of hydra eval time memory
issues in the GB range, but were still quite large (around 10MB for the
`cabal-simple` test case).
There was issue causing excessive builds of the `git` package when
cross compiling. Gory details are a comment in `lib/defaults.nix`
but in short if you use `git` you need an extra `.buildPackages`
one is not enough because it depends on `gdb` and that will
be different in `buildPackages` compared to
`buildPackages.buildPackages`.
Adds missing materialization files for ghc 8.4.4 (only needed
when `checkMaterialization` is on because of other
materialiazations, but good to have).
The `cabalProject` function works by running `cabal v2-configure` followed by `plan-to-nix`. However for `v2-configure` to correctly calculate the plan (including flag settings and buildable components) it needs to know what GHC we want to use.
This causes significant problems:
* For hydra to assemble a list of jobs from `components.tests` it must first have GHC that will be used. If a patch has been applied to the GHC to be used it must be rebuilt before the list of jobs can be assembled. If a lot of different GHCs are being tests that can be a lot of work all happening in the eval stage where little feedback is available.
* Once the jobs are running the compilation of the GHC needed (the eval stage already must have done it, but the outputs there are apparently not added to the cache) happens inside the IFD part of `cabalProject`. This causes a very large amount of work to be done in the IFD and our understanding is that this can cause problems on nix and/or hydra.
* When using `cabalProject` we cannot examine the properties of the project without building or downloading the GHC (less of an issue as we would normally need it soon anyway).
The solution here is to:
* Create a dummy `ghc` and `ghc-pkg` from the real ones by capturing the `ghc` and `ghc-pkg` outputs that `cabal v2-configure` requests.
* The dummy `ghc` and `ghc-pkg` is used instead of the real one in `cabalProject` when running `cabal v2-configure`.
* The captured outputs are materialized into the haskell.nix repo so that the real GHC is only needed when `checkMaterialization` is set.
