When making ghcWithPackages, haskell package db configuration
is modified by sed, but newlines are not handled properly, so
resulting in
```
dynamic-library-dirs: ${pkgroot}/../lib/aarch64-osx-ghc-9.6.1
data-dir:
${pkgroot}/../share/aarch64-osx-ghc-9.6.1/filepath-1.4.100.1
```
is replaced like (data-dir: is swallowed)
```
dynamic-library-dirs:
/nix/store/zxmwvns8zg4ff47vw9hqgazjkiqa26kv-ghc-9.6.1-with-packages/lib/links
${pkgroot}/../share/aarch64-osx-ghc-9.6.1/filepath-1.4.100.1
```
This fixes the bug.
From GHC 9.6 on, the boot libraries (dependencies of the ghc library) are
present in a separate directory after the installation, and thus the
wrapper environment provided by ghcWithPackages needs to handle the links
to the boot dynamic libraries separately than other ordinary ones.
ghcWithHoogle was using unoverridden packages pulled from the
buildHaskellPackages package set. This commit fixes that by pulling the
packages from self instead.
QuickCheck's generator for floating point numbers started churning out
strange numbers more frequently, causing tests that can be broken by
the imprecisions of floating point arithmetic fail reliably.
Let's disable them until the situation is resolved upstream.
Turns out we can use the same code to install man pages for all hledger
related packages, since hledger also has the top level man pages.
Verified that the contents of $out/share are the same before and after.
Whether profiling should or should not be enabled does indeed depend on
GHC's target platform (or GHC in general, i.e. if it happens to be
ghcjs, we need to disable it). The profiling objects it produces are
excessively big if it is producing them for aarch64.
However, in a Haskell packages' derivation, GHC's and the resulting
derivation's platforms are offset
GHC: BUILD--HOST---TARGET
DRV: BUILD--HOST--(TARGET)
since we need to execute GHC in the derivation (so its host is our build
platform) and the machine code it produces need to be executable on the
host platform we are targeting. Unless our derivation is building a
compiler (or similar), the target platform of the derivation doesn't
matter.
stdenv exposes the platforms of the current derivation, not of GHC, so
checking the host platform is prudent. Changing this doesn't have a lot
of impact, since when cross-compiling Haskell packages (e.g. via
pkgsCross), host and target platform will usually be the same.
It does save unnecessary rebuilds in the buildHaskellPackages set
though, since most of the packages in here don't care about the target
platform, so they should be the same as their corresponding packages in
the ordinary (natively compiled) haskellPackages set. In short, after
this change
pkgsCross.aarch64-multiplatform.hoogle == haskellPackages.hoogle
holds whereas it would erroneously be compiled with different profiling
settings before.
