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.
Hadrian (the GHC build tool) is built separately from GHC. This means
that if `haskell.compiler.ghc961` is overridden to add patches, those
patches will _only_ be applied to the GHC portion of the build, and not
the Hadrian build. For example, backporting this patch to GHC 9.6.1
failed because the changes to `hadrian/` files were not reflected in the
Nix build:
5ed77deb1b
By lifting `src` and `hadrian` from variables defined in the function
body to parameters with default values, the `hadrian/` files can be
overridden using the `haskell.compiler.ghc961.override` function. For
example:
self.haskell.compiler.ghc961.override {
# The GHC 9.6 builder in nixpkgs first builds hadrian with the
# source tree provided here and then uses the built hadrian to
# build the rest of GHC. We need to make sure our patches get
# included in this `src`, then, rather than modifying the tree in
# the `patchPhase` or `postPatch` of the outer builder.
src = self.applyPatches {
src = let
version = "9.6.1";
in
self.fetchurl {
url = "https://downloads.haskell.org/ghc/${version}/ghc-${version}-src.tar.xz";
sha256 = "fe5ac909cb8bb087e235de97fa63aff47a8ae650efaa37a2140f4780e21f34cb";
};
patches = [
# Enable response files for linker if supported
(self.fetchpatch {
url = "5ed77deb1b.patch";
hash = "sha256-dvenK+EPTZJYXnyfKPdkvLp+zeUmsY9YrWpcGCzYStM=";
})
];
};
}
Note that we do have to re-declare the `src` we want, but I'm not sure
of a good way to avoid this while also sharing one set of patches
between the GHC and Hadrian builds.
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.
