JakeHillion/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Merge pull request #147400 from sternenseemann/top-level-ghc-more-intuitive-cross

Browse Source 
ghc: make sure top level exposed GHC is always host->target
This commit is contained in:
John Ericson 2021-11-25 14:55:14 -05:00 committed by GitHub
commit 303999a073
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 44 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
nixos/doc/manual/from_md/release-notes/rl-2205.section.xml
View File

@ -24,8 +24,29 @@
</section>
<section xml:id="sec-release-22.05-incompatibilities">
<title>Backward Incompatibilities</title>
<para>
</para>
<itemizedlist spacing="compact">
<listitem>
<para>
<literal>pkgs.ghc</literal> now refers to
<literal>pkgs.targetPackages.haskellPackages.ghc</literal>.
This <emphasis>only</emphasis> makes a difference if you are
cross-compiling and will ensure that
<literal>pkgs.ghc</literal> always runs on the host platform
and compiles for the target platform (similar to
<literal>pkgs.gcc</literal> for example).
<literal>haskellPackages.ghc</literal> still behaves as
before, running on the build platform and compiling for the
host platform (similar to <literal>stdenv.cc</literal>). This
means you don’t have to adjust your derivations if you use
<literal>haskellPackages.callPackage</literal>, but when using
<literal>pkgs.callPackage</literal> and taking
<literal>ghc</literal> as an input, you should now use
<literal>buildPackages.ghc</literal> instead to ensure cross
compilation keeps working (or switch to
<literal>haskellPackages.callPackage</literal>).
</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="sec-release-22.05-notable-changes">
<title>Other Notable Changes</title>

12
nixos/doc/manual/release-notes/rl-2205.section.md
View File

@ -10,4 +10,16 @@ In addition to numerous new and upgraded packages, this release has the followin
## Backward Incompatibilities {#sec-release-22.05-incompatibilities}
* `pkgs.ghc` now refers to `pkgs.targetPackages.haskellPackages.ghc`.
This *only* makes a difference if you are cross-compiling and will
ensure that `pkgs.ghc` always runs on the host platform and compiles
for the target platform (similar to `pkgs.gcc` for example).
`haskellPackages.ghc` still behaves as before, running on the build
platform and compiling for the host platform (similar to `stdenv.cc`).
This means you don't have to adjust your derivations if you use
`haskellPackages.callPackage`, but when using `pkgs.callPackage` and
taking `ghc` as an input, you should now use `buildPackages.ghc`
instead to ensure cross compilation keeps working (or switch to
`haskellPackages.callPackage`).
## Other Notable Changes {#sec-release-22.05-notable-changes}

10
pkgs/top-level/all-packages.nix
View File

@ -12070,7 +12070,15 @@ with pkgs;
# current default compiler is”, if you bump this:
haskellPackages = dontRecurseIntoAttrs haskell.packages.ghc8107;
inherit (haskellPackages) ghc;
# haskellPackages.ghc is build->host (it exposes the compiler used to build the
# set, similarly to stdenv.cc), but pkgs.ghc should be host->target to be more
# consistent with the gcc, gnat, clang etc. derivations
#
# We use targetPackages.haskellPackages.ghc if available since this also has
# the withPackages wrapper available. In the final cross-compiled package set
# however, targetPackages won't be populated, so we need to fall back to the
# plain, cross-compiled compiler (which is only theoretical at the moment).
ghc = targetPackages.haskellPackages.ghc or haskell.compiler.ghc8107;
cabal-install = haskell.lib.compose.justStaticExecutables haskellPackages.cabal-install;