Cabal 1.x says:
| Warning: This package indirectly depends on multiple versions of the same
| package. This is highly likely to cause a compile failure.
But in version 2.x, that warning is split into two lines differently:
| Warning:
| This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
This commit modifies the call to "egrep" to recognize both versions by virtue
of the "-z" flag, which essentially interprets the whole configure-time output
as one long line.
This works by extracting out some logic from generic-builder.nix to
make it possible to get at the relevant information by overriding
mkDerivation for the haskell package.
This partially undoes the change from 8788bfe762.
The 'doBenchmark' name is more consistent with the naming scheme used for
other phases, like 'doCheck', 'doHaddock', etc.
This reverts commit dfb0f25484, reversing
changes made to 7f8ff02437. These changes broke
the ghcWithPackages wrapper:
nix-shell -p "haskellPackages.ghcWithPackages (ps: [ps.mtl])" --run "ghc-pkg list mtl"
/nix/store/szz84j5k1dy3jdashis6ws28d8l8zxxb-ghc-8.0.2-with-packages/lib/ghc-8.0.2/package.conf.d
(no packages)
WIP
If the `hoogle.nix` file wants to have any sane chance of finding haddock
outputs, the packages need to export the haddock folders as an identifier.
A few TODOs still stand, like passing self to the package instead of needing to
pass it to `haddockDir`. Maybe the exported identifier should be integrated into
the fixpoint somehow instead of using `passthru`?
We achieve this by moving setupHaskellDepends from the buildInputs attribute
into "otherBuildInputs", which is the attribute the builder uses to construct
the build inputs in both the actual build as well as the "env" attribute.
As @oxij points out in [1], this breakage is especially serious because
it changes the contents of built environments without a corresonding
change in their hashes. Also, the revert is easier than I thought.
This reverts commit 3cb745d5a6.
[1]: https://github.com/NixOS/nixpkgs/pull/27427#issuecomment-317293040
This makes those files a bit easier to read. Also, for what it's worth,
it brings us one baby step closer to handling spaces in store paths.
Also, I optimized handling of many transitive deps with read. Probably,
not very beneficial, but nice to enforce the pkg-per-line structure.
Doing so let me find much dubious code and fix it.
Two misc notes:
- `propagated-user-env-packages` also needed to be adjusted as
sometimes it is copied to/from the propagated input files.
- `local fd` should ensure that file descriptors aren't clobbered
during recursion.
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.
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.
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.
This reverts commit a27bc8b317. Please don't add
random stuff to the interface provided by the generic builder without
coordinating with others. There is a proper effort underway to provide that
information in https://github.com/NixOS/nixpkgs/pull/23023.
This reverts commit c153036525. Please don't add
random stuff to the interface provided by the generic builder without
coordinating with others. There is a proper effort underway to provide that
information in https://github.com/NixOS/nixpkgs/pull/23023.
A function is added to enable the generation of a HPC report. For example:
pkgs.haskell.lib.doCoverage drv
will create a HPC report of the Haskell package drv in the directory:
$out/share/hpc
Closes https://github.com/NixOS/nixpkgs/pull/22797/files.
-split-sections replaced -split-objs with following upsides:
1) -split-objs adds considerable overhead to compile time
2) combined with stripping, it causes issues when cross-compiling
For upstream see https://ghc.haskell.org/trac/ghc/ticket/8405
This is supported only for Linux/Windows using ld linker.
GHC master also turns on -split-sections by default.
Example using stack:
Without splitting
$ du /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2
4 /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2/share/bash-completion/completions
4 /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2/share/bash-completion
4 /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2/share
23416 /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2/bin
23420 /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2
With -split-objs
$ du /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2
20632 /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2/bin
4 /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2/share/bash-completion/completions
4 /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2/share/bash-completion
4 /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2/share
20636 /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2
With -split-sections
$ du /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2
4 /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2/share/bash-completion/completions
4 /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2/share/bash-completion
4 /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2/share
20672 /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2/bin
20676 /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2
Note: you currently need following overrides to build stack on 802:
vector-algorithms = dontCheck super.vector-algorithms;
path-io = doJailbreak super.path-io;
stack = doJailbreak super.stack;
Note: Should also work on GHC 8.0.1, but I'm being careful here.
We could backport later on.
This fix doesn't actually fix the cabal bug (see #16357), but it does
cause other bugs (see #20476)
Fixes#20476
This reverts commit b89fa5fd5c, reversing
changes made to e4b146b041.
This reverts commit ec8b816154. The change told
the Cabal build system to use the hash-part of $out as the internal identifier
for the library it's building (rather than generating such an ID itself). While
a good idea in theory, this choice had an unfortunate side-effect: When Cabal
links libraries X, Y, and Z into an executable, then the generated binary
contains their respective IDs. Now, Nix finds those strings and treats them as
an indication that there is a *run-time dependency* on the corresponding store
paths. This means that the generated executable will always depend on the store
paths of all the Haskell libraries that went into it, even when linked
statically.
This commit fixes a problem that occurs with externally linked haskell
libraries on Darwin. It does this by adding the libraries to the
--extra-lib-dirs flag and the DYLD_LIBRARY_PATH environment variable.
Without this patch, attempts to install at least some of the packages
that start to use setupHaskellDepends (mostly gtk-related packages)
results in collisions:
building path(s) ‘/nix/store/63k5smns43f5r2ad8wcc242x0gwd70m3-ghc-8.0.1’
collision between `/nix/store/k18i1nm5hgnb82y9w2g9hmlwhk3szjld-ghc-8.0.1/lib/ghc-8.0.1/Cabal-1.24.0.0/Distribution/Compat/Binary.dyn_hi' and `/nix/store/0rwhbwsg9kmywgbrib2bs29p2hmi80za-Cabal-1.24.0.0/lib/ghc-8.0.1/Cabal-1.24.0.0/Distribution/Compat/Binary.dyn_hi'
builder for ‘/nix/store/vrjkfpm8sb96m9i5k74h8vn0rwddgy4v-ghc-8.0.1.drv’ failed with exit code 25
This would appear to me to be a consequence of setupHaskellDepends
entries being added to propagateBuildInputs. It is sufficient in the
cases I'm familiar with (taffyBar), and I think correct, to simply add
it to the otherBuildInputs.
hydraPlatforms now defaults to the value of meta.platforms rather than
defaulting to ghc.meta.hydraPlatforms. This solution is, in fact, still
sub-optimal. See https://github.com/NixOS/nixpkgs/issues/9608 for further
details.
A derivation of the Hackage package "foo" is called "haskell-foo" if it is a
library, but only "foo" if it is an executable (without a library). This
distinction used to be fine when Haskell packages where visible to operations
like "nix-env -qa" or "nix-env -i", but after our switch to Haskell NG it has
no more purpose. Consequently, this patch removes the name prefix from all
Haskell packages -- every Haskell package is now called exactly like it's
called on Hackage.
Closes https://github.com/NixOS/nixpkgs/pull/9538.
