This change introduces a `ghc8102-experimental` compiler-nix-name that behaves much like the `ghc8102` version but includes @JoshMeredith's patch `./patches/ghc/ghc-8.10-ubxt.patch` that writes the `cg_binds` field with:
```haskell
liftIO $ registerInterfaceDataWith "ghc/phase/core" hsc_env $ \bh ->
putWithUserData (const $ return ()) bh (map toIfaceBind $ cg_binds cg_guts)
```
Some of the places where we used to depend on the output of `plan-to-nix` containing the correct `nix-name` for the compiler have been update to avoid using incompatible interface files from the `compiler-nix-name = "ghc8102"` version of GHC.
Fixes the #441 issue with GHC 8.8.3 (fix that was already applied to GHC 8.6.5 with PR #480).
Testing environment:
- GHC 8.8.3 (cross-compiler)
- NixOS 20.03
- Building host: x86_64
- Target host: armv6l
Without this PR, the symbol `__sync_val_compare_and_swap_8` was not found by `remote-iserv` as described in #441 but this time with GHC 8.8.3. The 8.6.5 patch also works for 8.8.3. Perhaps it would be preferable to apply this patch to a range of GHC versions rather than specific versions, but I have only tested it and verified that it works properly on those specific versions.
I have not submitted this patch to the GHC GitLab as I haven't encountered any problem building a cross-compiling version of GHC from there.
It looks like we can't use 8.8 for booting due to
https://gitlab.haskell.org/ghc/ghc/-/issues/18143
* Adds nixpkgs 20.09 to get mingw-w64 version 6
(also needed for ghc 8.10 windows cross compile)
* Add materialization for ghc 8.10.2 windows cross
* Fix issue with harfbuzz override so it works with nixpkgs 20.09
* Fixes eval time issue for windows index-state test (turns off native-dns cabal flag for windows)
* Include exe extension for windows in coverage test
lib:ghc is still broken for ghc 8.10 (all variants), but it always has been and we should try to fix it properly, but it will be very tricky.
- Added the ability to generate coverage reports for packages and
projects.
- Outputs mix and tix information, as well as a HTML report.
- Added the "doCoverage" module option that allows users to choose
packages to enable coverage for.
- Added a "doCoverage" flag to the component builder that outputs HPC
information when coverage is enabled.
- Added the "overrideModules" library function to make it more
ergonomic fo users to enable coverage on existing projects.
- Modified the "check" builder to also output ".tix" files (if they
exist). This information is required to generate the coverage
report.
- Added a test for coverage.
Fixes the following error that occurs on single-user nix installations when
compiling an otherwise trivial cabalProject/stackProject:
> error: moving build output '/nix/store/d5zpqajgysbk38iqgcjwgqx44amqh9pw-ghc-boot-src' from the sandbox to the Nix store: Permission denied
Tested on ghc-8.4 where there is nothing in the cache.
Materialisation of ghc(-boot-src) also still works/works again.
See https://github.com/input-output-hk/haskell.nix/issues/466
and the previous attempt to fix this
at https://github.com/input-output-hk/haskell.nix/pull/399
(d3905d62b5c5ca7f671f5a301c4fcab433ebf68c..8561498e7d9237cc271f9ffd7bff19e3293122b0)
This makes it less noisy when added to haskell.nix. This change
also simplifies things to just use `ifdLevel` 2. In the past higher
`ifdLevels` were not always supersets of the lower levels. This is
no longer the case so we can safely use just level 2.
Changes to the interface of haskell.nix (from the changelog.md file):
* Removed `sources.nixpkgs-default`, use `sources.nixpkgs` instead.
* Removed `./nixpkgs` directory, use `(import ./. {}).sources`
or `./nix/sources.nix` instead.
* Removes V1 interface for details on how to fix old code see:
https://github.com/input-output-hk/haskell.nix/issues/709
* Removed defaultCompilerNixName.
* cabalProject, cabalProject', hackage-project and hackage-package
now require a `compiler-nix-name` argument.
* `haskell-nix.tool` and `.tools` now require a `compiler-nix-name` argument.
New functions `p.tool` and `p.tools` (where p is a project) do not.
Like `shellFor { tools = ... }` they will use the compiler nix name
from the project (including stack projects where it is derived from
the resolver).
* `haskell-nix.alex` and `haskell-nix.happy` have been removed. Use
`p.tool "alex" "3.2.5"` or `shellFor { tools = { alex = "3.2.5"; } }`.
* `haskell-nix.nix-tools` -> `haskell-nix.nix-tools.ghc883` (it includes
the hpack exe now).
* `haskell-nix.cabal-install` ->
`p.tool "cabal" "3.2.0.0"` or `shellFor { tools = { cabal = "3.2.0.0"; } }`
* `haskell-nix.haskellNixRoots` -> `haskell-nix.roots ghc883` or `p.roots`
Other changes:
Adds hpack executable to the nix-tools derivations.
Adds a `cabal-hpack` test to make sure `hpack` works with
`cabalProject`.
Reduces the number of calls to `cabalProject` (particularly when
checking materialization), by giving internal tools a per-compiler
attribute.
Uses happy 1.19.12 when building newer ghc versions.
Updates cabal-install 3.2.0.0 to use the source from github that
is compatible with ghc 8.10.1.
Updates the docs for callCabalProjectToNix.
Adds a license mapping to fix a common warning.
This change allows a resolverSha256 to be passed to stackProject.
When provided the resolver found in the stack.yaml is fetched
using this sha256 and the uri string is replaced with the
path to the fetched version.
Currently the ghc version is picked to match the `shellFor` project
and you cannot replace it by specifying `compiler-nix-name`.
This change fixes that and also uses `ghcOverride` so warning to asking
for a `compiler-nix-name` is not displayed when the compiler has already
been picked (by the project that shellFor is for).
Generalized version of the `cabalProject` and `stackProject`
functions.
Automatically selects the correct project type based on the
`projectFileName` argument if provided or what files exist in
the `src` directory if no `projectFileName` was specified.
If it cannot be determined which it should use the following
error message is given:
```
error: haskell-nix.project : both `stack.yaml` and `cabal.project` files exist set `projectFileName = "stack.yaml;"` or `projectFileName = "cabal.project";`
```
This is a simple way to specify the sha256 values for references
to git repositories that do not have a `--sha256:` comment in the
`cabal.project` file or a `# nix-sha256:` comment in the `stack.yaml`
file.
The tests demonstrate how to use `sha256map` with both
`cabalProject` and `stackProject` to build the
haskell-language-server from github with the sha256 hashes
needed to work with `--option restrict-eval true`.
* Use hydra-migration in check-hydra.nix
* mkdocs fix is now in nixpkgs 20.03 (so this drops our work around)
* Adds sanity checks for #660
* Add missing ${targetPrefix} to NIX_LDFLAGS
* Use eval system for callStackToNix.
* Improves pins.
Fix flake overlay attr
Solves the following error:
while evaluating the attribute 'overlays.combined-eval-on-build' at /nix/store/0gg5rsi7nvwlk2ky1w595qyjgwpqj35g-source/flake.nix:11:5:
value is a function while a set was expected, at /nix/store/0gg5rsi7nvwlk2ky1w595qyjgwpqj35g-source/flake.nix:10:15
Fixes#672 by using the first index-state that is > than desired
index state. It also passes `--index-state` to `cabal v2-cconfigre`
to make sure it cabal uses only the packages in the hackage
file that are before the specified date.
Fixes#540 by returning the `index-state` used back out of
`cabalProject` in the same way `plan-nix` is returned.
* Add script for fixing materialized files
This is useful in two ways:
- We reference it in the error message, so users can more easily
copy-paste the correct call, rather than several lines of commands.
- We add it to `passthru`, so users can reference it directly when they
know they need to update the files, without having to first run a build
and find it on stderr.
* Add script for calculating the sha
This is useful in two ways:
- It makes it easier for users to copy from the message.
- We add it to `passthru` so users can call it directly if they know
they need to update the sha, without having to run a build and copy it
from stderr.
* Refactor unchecked a bit
Put the positive logic first, use the materialized files by preference
if they're there.
* Allow the updater script to take an argument
* Use double brackets
* Fix a dependency
* Separate generating and updating scripts
* 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>
Now that the defaultCompilerNixName is used to choose which GHC to use
for tools we need to update haskellNixRoots to make sure the common
tools wind up in the cache.
To do this we add the compilerNixName as a dimension in ci.nix.
This has the added bonus of ensuring the tests a run with the
supported versions of ghc (not just the default one).
haskellNixRoots is also updated to include the tools built with the
defaultCompilerNixName (in particular cabal-install was not pinned
and this was the likely cause of significant builds due to cache
misses).
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).
It turns out `git` depends on `gdb` in a round about way:
```
git -> openssh -> libfido2 -> systemd -> python libxml -> Cython -> gdb
```
Somewhere in that chain there should perhaps be a `buildPackages` so
that the `gdb` that is used is not the one for debugging code in
the `final` (but instead the one for debugging code in
`final.buildPackages`).
Using `final.buildPackages.git` causes two problems:
* Multiple versions of `git` (and that dependency chain
to `gdb` are needed when cross compiling).
* When `gdb` does not exist for `js`, so when cross
compiling with `ghcjs` `final.buildPackages.git` fails
to build at all.
* Add compiler-nix-name to cabalProject
Setting the compiler explicitly does not make it easy for cross
compilation to also choose the correct compiler when compiling
build tools for the build platform. Also it is easy to pass the
wrong compiler type. Specifying just the nix-name of the compiler
makes that less likely.
Co-authored-by: Moritz Angermann <moritz.angermann@gmail.com>
The newer versions of ghcjs use emscripten to deal with .c code.
The version of emscripten that is available by default in nixpkgs
does not include the "upstream" version of emscripten.
This commit takes the existing emscripten from nixpkgs and adds
the "upstream" version.
