| Warning: This package indirectly depends on multiple versions of the same
| package. This is highly likely to cause a compile failure.
| package wai-app-static-3.1.6.1 requires optparse-applicative-0.13.2.0
| package tasty-rerun-1.1.6 requires optparse-applicative-0.13.2.0
| package tasty-0.11.2.1 requires optparse-applicative-0.13.2.0
| package git-annex-6.20170520 requires optparse-applicative-0.14.0.0
The motivation is to be able to get rid of common configuration
when initial packages differs since common configuration assumes
a very specific version set.
cc @jmitchell @peti
This actually will matter when I (soon) land cross-compilation support,
and native deps are compiled for the build, instead of host, platform.
But even now, it's good style do this, and one less thing to review
later.
The use of `$nativePkgs` is unfortunate, as it will need to be
swapped out for `$crossPkgs` for build != host builds. This will just a
temporarily cause pain, however, as eventually I will change stdenv to
use a `$runPkgs` (or moral equivalent) in both case.
Closes https://github.com/NixOS/nixpkgs/pull/26480.
The approach taken to add this package was to port over the definitions
currently existing for HEAD, and making the necessesary changes to get
this building.
The Haskell package set associated with this compiler doesn't yet
guarantee that all or most of the packages successfully build with this
new compiler, but that will improve over time after this GHC 8.2.1
is officially released and the ecosystem catches up.
By default, `ghcjs` haddocks are precluded from being built. I see no reason to disallow building haddocks on projects built with `ghc` and `ghcjs` (someone can correct me here). `HaLVM` currently does not support `haddock` since it's a Stage 1 `GHC`. https://github.com/GaloisInc/HaLVM/blob/master/src/misc/build.mk.in#L20
Currently, building `haddocks` for `ghcjs` projects requires altering the derivation, which doesn't allow users to take advantage of the cache. This change will relieve that.
This change is effectively a no-op to nixpkgs. However, it gives users
the flexibility to create and maintain their own package sets per
project, while benefiting from nix's Haskell configurations.
I would make immediate use of this change in stack2nix, a project that
generates nix expressions for all the dependencies of a given Haskell
project. @domenkozar is familiar with the motivations and helped
refine this change
As noted in #25595, a change introduced in 4b77d425aa causes an
explosion of inodes due to the constructions of many, many `ghcEnv`
symlink forests. This commit undoes that change.
To discuss reworking the support for GHCJS plugins, please see: #26192Fixes#25595
The Sierra linker added a limit on the number of paths that any one
dynamic library (`*.dylib`) can reference. This causes problems when
a Haskell library has many immediate dependencies (#22810).
We follow a similar fix as GHC/Cabal/Stack: for each derivation,
create a new directory with symlinks to all the dylibs of its immediate
dependencies, and patch its package DB to reference that directory
using the new `dynamic-library-dirs` field.
Note that this change is a no-op for older versions of GHC, i.e., they will
continue to fail on some packages as before.
Also note that this change causes the bootstrapped versions of GHC to be
recompiled, since they depend on `hscolour` which is built by
`generic-builder.nix`.
Tested by building the `stack` binary as described in #22810.
The tasty-discover test suite depends on tasty-discover in $PATH during
test-suite compilation. Adding an untested build of itself to build
tools fixes the problem, without putting the untested version in
the package set.
`stack setup` should not be called inside `nix-build` because
that makes stack download a GHC instead of using nix's one
(the one provided `generic-stack-builder.nix` as the `ghc` argument),
which will not work.
Further evidence for this is that the `stack --nix` support
intentionally uses `--system-ghc` for the same purpose.
We want code such as `(pkg.override {}).overrideScope (self: super: {})` to
work. This didn't work before, since `override` will call the original package
again, and the attribute `overideScope`, which `callPackageWithScope` added,
wasn't added again. The fix for this is to modify the package function itself
to include the `callPackageWithScope` attribute, so it'll be re-added whenever
the function is overriden for with arguments.
There is a small problem here though: since callPackage uses some magic
(`builtins.functionArgs`) to determine the auto-arguments of a function, we
can't just write `callPackageWith scope drvScope`, since
`builtins.functionArgs drvScope` will be `{}`. To fix this, we implement our own
`callPackageWith`.
Fixes https://github.com/NixOS/nixpkgs/issues/7953.
Closes https://github.com/NixOS/nixpkgs/pull/9336.
Peter Simons
Gleb Peregud
Domen Kožar
John Ericson
Renzo Carbonara
michael bishop
Shea Levy
Jörg Thalheim
David Johnson
Jacob Mitchell
Charles Strahan
Volth
Nicolas Mattia
Nikolay Amiantov
Domen Kožar
Judah Jacobson
Pierre Radermecker
Michal Rus
Leon Isenberg
Moritz Drexl
Ryan Trinkle
Robert Hensing
Pascal Wittmann
Niklas Hambüchen
Benno Fünfstück
Michael Alan Dorman