Skip to content

Comments

[staging-24.05] haskellPackages: backports from #315167#318354

Merged
sternenseemann merged 3 commits intoNixOS:staging-24.05from
sternenseemann:backports-from-315167
Jun 17, 2024
Merged

[staging-24.05] haskellPackages: backports from #315167#318354
sternenseemann merged 3 commits intoNixOS:staging-24.05from
sternenseemann:backports-from-315167

Conversation

@sternenseemann
Copy link
Member

Ref #315167.

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

Previously, we would set GHC_PACKAGE_PATH after configure, the reasons
being that

1. Setup.hs configure forbids this from being set since it can make a
   build fail that would otherwise succeed (since it influences how
   GHC behaves when invoked by Cabal).
2. Setting GHC_PACKAGE_PATH being set is sound in our case, since
   we set it precisely to the packages available to Cabal at configure
   time, so there should be no room for a mismatch.
3. Some test suites require GHC_PACKAGE_PATH or GHC_ENVIRONMENT to be
   set, so they can invoke GHC(i) with build dependencies available.
   Cabal >= 3.12 forbids GHC_PACKAGE_PATH from being set after
   <haskell/cabal@d6e38041a7c778fadf8f416>.
   Setting GHC_ENVIRONMENT would be possible, but is cumbersome without
   cabal-install (which has the handy cabal exec command which takes
   care of that). Additionally, it is not clear if it'll remain possible
   to do that: <haskell/cabal#7792>.

Our solution to Cabal 3.12's change is to be more targeted about setting
GHC_PACKAGE_PATH: We _just_ set it for the actual test suite executable.
This can be achieved by using --test-wrapper which when given is invoked
by Cabal to run the test suite. Here we can set any environment
variables after Cabal has already done its environment checks. As long
as we don't do anything stupid, this should be unproblematic.

Users can also arbitrarily influence what GHC_PACKAGE_PATH will contain
using the NIX_GHC_PACKAGE_PATH_FOR_TEST environment variable. This is
un(der)documented for now, since I want to keep some wiggle room for
changing stuff in the coming weeks. Also it's rarely necessary to
actually touch this variable.

(cherry picked from commit 120f242)
After 120f242, GHC_PACKAGE_PATH isn't
set implicitly in installPhase anymore. Instead we achieve the same by
telling the Makefile the exact ghc command line to use.

As a benefit, we can now cleanly separate build and host in this case:
We used to (implicitly) reuse the host package db. Now we can explicitly
request the package db also used for building Setup.hs.

(cherry picked from commit 482ab92)
It is somewhat curious that it behaves differently exclusively here, but
I don't think it is necessary to stop shipping a package due to floating
point arithmetic error—it would be unreasonable to assume there were
none…

See ekmett/ad#113.

(cherry picked from commit d902325)
@github-actions github-actions bot added the 6.topic: haskell General-purpose, statically typed, purely functional programming language label Jun 8, 2024
@ofborg ofborg bot added 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 5001+ This PR causes many rebuilds on Darwin and must target the staging branches. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 5001+ This PR causes many rebuilds on Linux and must target the staging branches. labels Jun 8, 2024
@sternenseemann sternenseemann merged commit 4ea4ec8 into NixOS:staging-24.05 Jun 17, 2024
@sternenseemann sternenseemann deleted the backports-from-315167 branch June 17, 2024 12:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

6.topic: haskell General-purpose, statically typed, purely functional programming language 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 5001+ This PR causes many rebuilds on Darwin and must target the staging branches. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 5001+ This PR causes many rebuilds on Linux and must target the staging branches.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant