Currently if you try to build a ghcjs version that does not exist
haskell.nix falls back on the GHC version. Once ghcjs is in the
ghc tree this will work, but for now we should have an error
message that is more descriptive than attempting and failing to
build ghc for a js target.
New error looks like this:
```
$ nix-build -A pkgs-unstable.pkgsCross.ghcjs.buildPackages.haskell-nix.compiler.ghc861
error: ghcjs 8.6.1 is no longer supported by haskell.nix. Consider using 8.6.5
```
Anyone using `hpack` and/or `stack` will have a dependency on `internal-nix-tools` (built with a fixed version of ghc). This is fine if your `nixpkgs` is one of the ones we cache, but if not we may have to wait for an extra ghc to build. When this happens it would be nice if it is at least building a more recent version (rather than an older one).
* Use nix module system to check project arguments
This change uses the nix module system for the arguments to:
* `cabalProject'`
* `cabalProject`
* `stackProject'`
* `stackProject`
This will:
* Give an error when the name or type of an argument is incorrect
(currently misnamed args are quietly ignored).
* Fixes a problem with `projectCross` not having a way to pass different args to `cabalProject`
for different platforms. We can now use:
`({pkgs, ...}: { cabalProjectLocal = if pkgs.stdenv.hostPlatform.isX then ... })`
* 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).
`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"];
Fixes:
Warning: `stdenv.lib` is deprecated and will be removed in the next release. Please use `pkgs.lib` instead. For more information see https://github.com/NixOS/nixpkgs/issues/108938
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.
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.
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.
* 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>
