ghc: make sure top level exposed GHC is always host->target
See the added comment in all-packages.nix for a more detailed explanation. This makes the top-level GHC different from haskellPackages.ghc (which is build->host and used for building the package set), but more consistent with gcc, gnat etc. Specifically, pkgsCross.${platform}.buildPackages.ghc will now be a cross-compiler instead of a native build->build compiler. Since this change has a slight chance of being disruptive, add a note to the changelog.
This commit is contained in:
parent
55b8d8c1bf
commit
558da925f3
|
@ -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>
|
||||
|
|
|
@ -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}
|
||||
|
|
|
@ -12066,7 +12066,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;
|
||||
|
||||
|
|
Loading…
Reference in a new issue