about summary refs log tree commit diff
path: root/pkgs/development/haskell-modules/make-package-set.nix
diff options
context:
space:
mode:
authorsternenseemann <sternenseemann@systemli.org>2023-05-05 18:58:08 +0200
committersternenseemann <sternenseemann@systemli.org>2023-05-05 18:58:08 +0200
commit391a9612d81f6ad76fae37c93a160471a947b9da (patch)
tree0bdd5f1da15948c0e1d378936cc52e640bb5c176 /pkgs/development/haskell-modules/make-package-set.nix
parent5751551558d7896ffb30ff3d709b4943bb3eafa8 (diff)
downloadnixlib-391a9612d81f6ad76fae37c93a160471a947b9da.tar
nixlib-391a9612d81f6ad76fae37c93a160471a947b9da.tar.gz
nixlib-391a9612d81f6ad76fae37c93a160471a947b9da.tar.bz2
nixlib-391a9612d81f6ad76fae37c93a160471a947b9da.tar.lz
nixlib-391a9612d81f6ad76fae37c93a160471a947b9da.tar.xz
nixlib-391a9612d81f6ad76fae37c93a160471a947b9da.tar.zst
nixlib-391a9612d81f6ad76fae37c93a160471a947b9da.zip
haskellPackages: ghcWithPackages needs buildHaskellPackages scope
ghc and also ghcWithPackages (when taken from a haskell package set) are
a bit weird—in the same way stdenv is: ghc is actually from
buildPackages (pkgsBuildHost) wheras the main package set belongs to
pkgsHostTarget. ghc (and stdenv) is included in the package set due to
its special relation to the set: it is built by that ghc, so constituted
by the compiler in a manner of speaking.

For ghc this works in a straightforward way: It is packaged
independently from the haskell package sets and passed to
make-package-set.nix to create the different sets we expose.
With ghcWithPackages an error crept in, though: Since it needs to
receive the haskellPackages fix point (and thus can't be instantiated
before the package set), it is defined in make-package-set.nix. Here it
was neglected to make sure that it also has the same scope as ghc, i.e.
buildHaskellPackages/buildPackages: Otherwise the shell the wrapper
scripts use to invoke ghc (originally from buildPackages) would be from
pkgsHostTarget—in the cross case, the wrapper scripts would be
executable by neither host nor build platform. We want them to work on
the build platform, though.

Note that this creates a weird mismatch where it is hard to see which of
the alternatives would be more natural: ghcWithPackages and
ghcWithHoogle now use packages from the package set they are a member
of, but have *-ghc and hoogle executables that are executable on the
build platform. This works because ghc originates from buildPackages (as
discussed) and hoogleWithPackages is taken from buildHaskellPackages.
This does imply though that while set.ghcWithHoogle will be executable
on the build platform, set.hoogleWithPackages will be executable on the
host platform—both will use the fix point of set for the package
selector function. This is maybe a confusing asymmetry, but it seems
like a valid use case to cross-compile a hoogle instance. Most
development tools use ghcWithHoogle (or equivalent), so that use case is
covered as well in principle.
Diffstat (limited to 'pkgs/development/haskell-modules/make-package-set.nix')
-rw-r--r--pkgs/development/haskell-modules/make-package-set.nix2
1 files changed, 1 insertions, 1 deletions
diff --git a/pkgs/development/haskell-modules/make-package-set.nix b/pkgs/development/haskell-modules/make-package-set.nix
index 7104a2164af3..e7a77e3474cc 100644
--- a/pkgs/development/haskell-modules/make-package-set.nix
+++ b/pkgs/development/haskell-modules/make-package-set.nix
@@ -281,7 +281,7 @@ in package-set { inherit pkgs lib callPackage; } self // {
     # GHC is setup with a package database with all the specified Haskell packages.
     #
     # ghcWithPackages :: (HaskellPkgSet -> [ HaskellPkg ]) -> Derivation
-    ghcWithPackages = self.callPackage ./with-packages-wrapper.nix {
+    ghcWithPackages = buildHaskellPackages.callPackage ./with-packages-wrapper.nix {
       haskellPackages = self;
     };