Unless specified otherwise, the default package set compiles library variants
for profiling with profiling-detail "all-functions". Executables, however, are
not built with profiling enabled.
This change increases the closure size for many Haskell programs, but the
practical advantage of having stack traces and performance measurements easily
available during development seems to outweigh that cost.
Closes https://github.com/NixOS/nixpkgs/issues/22340.
This reverts commit e73e5c884f. Please don't
set $LD_LIBRARY_PATH! Instead, pass appropriate --extra-include-dir and
--extra-lib-dir arguments to "cabal configure" to ensure that Cabal knows
about system dependencies.
For a Haskell package "foo" the environment foo.env now contains the build tool
dependencies required for compiling the package in $PATH.
Fixes https://github.com/NixOS/cabal2nix/issues/331.
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.
