haskellPackages: update stackage and hackage#208421
Merged
Conversation
This commit has been generated by maintainers/scripts/haskell/update-stackage.sh
This commit has been generated by maintainers/scripts/haskell/update-hackage.sh
This commit has been generated by maintainers/scripts/haskell/regenerate-hackage-packages.sh
maralorn
requested review from
cdepillabout and
sternenseemann
as code owners
github-actions
bot
added
the
6.topic: haskell
ofborg
bot
added
8.has: package (new)
2 tasks
… template-haskell. This updates the `true-name` package to include changes up to version 0.1.0.4, as well as compilation failures when building with template-haskell version 2.16 and higher.
Add a patch to allow `true-name` to build with current template-haskell.
This commit has been generated by maintainers/scripts/haskell/regenerate-hackage-packages.sh
Finally building a cross compiler using hadrian is possible, but there are some outstanding issues regarding external libraries in the package db which causes issues with ghc-bignum.
Member
ofborg
bot
added
the
11.by: package-maintainer
GHC's js backend depends on systemd via emscripten via closure compiler via jdk via cups. Before it fails to evaluate, though, since llvmPackages looks into `targetPackages.stdenv.cc` to determine which C++ library to use (something that should be rectified in the future). [Unfortunately], for `pkgsCross.ghcjs`, `stdenv.cc` throws which blows up evaluating `pkgsCross.buildPackages.llvmPackages.clang`. This is in principle unnecessary. We want to build `pkgsCross.ghcjs.buildPackages.haskell.compiler.native-bignum.ghcHEAD` which depends on `pkgsCross.ghcjs.buildPackages.systemd` which needs clang and friends only in `nativeBuildInputs`, so `pkgsCross.ghcjs.buildPackages.buildPackages.llvmPackages.clang`. Unfortunately, due to the nature of splicing, we first evaluate the “adjacent” derivation before we can access the spliced derivation we are actually interested in. If the former fails (`pkgsCross.ghcjs.buildPackages.llvmPackages.clang`), we can't do the latter. The solution is to just not rely on splicing in this case and take `buildPackages.llvmPackages.clang` directly (relative to `buildPackages.systemd` in this case!) which avoids the whole problem. [Unfortunately]: c739c42#diff-3209527bd27cbc775f579b1e295b0264c850859c7245d526965cec456b8c70a4R61
This will be required for the JavaScript backend to work.
For the GHC JavaScript backend, we'll use emscripten in place of targetCC. To avoid having too much special logic for this, we'll make the emscripten derivation look like the result of wrapCC as far as GHC is concerned, i.e. we need targetPrefix and bintools. For bintools, we'll just reexpose emscripten, as it has emar, the only relevant bintools. That the other ones are missing doesn't matter in practice, as the GHC build system won't attempt to use them. targetPrefix can immediately be (ab)used to make sure GHC will correctly call emcc etc. instead of plain cc.
gmp is part of buildInputs _and_ depsTargetTarget, so we need to check the host and target platform to be correct. In practice this doesn't change much though, as gmp.meta.platforms is _quite_ liberal.
Since #200337 gobject-introspection propagates itself via depsTargetTargetPropagated, so one doesn't have to add it to every derivation twice. The problem is that gobject-introspection still is in a lot of buildInputs and will thus propagate itself again for target, breaking evaluation unnecessarily if gobject-introspection doesn't evaluate on whatever the target platform turns out to be. temurin-bin and openjdk19 caused such a situation via gtk3 which GHC's JavaScript backend depends on. To fix evaluation of those packages in pkgsCross.ghcjs.buildPackages, we'll just disable the features pulling in gtk3 until this is fixed properly.
This is now possible by building a cross compiler for js-unknown-ghjs
using `pkgsCross.ghcjs.buildPackages.haskell.compiler.ghcHEAD`.
To allow this, the following things needed to be done:
* Disable dependencies that wouldn't work:
- Don't pull in ncurses for terminfo
- Don't pull in libffi
- Don't pull in libiconv
- Don't enable the LLVM backend
- Enable gmp-less native-bignum backend
* Use emscripten instead of a C compiler. The way this works is inspired
by emscriptenPackages, but avoids the following flaws:
- Instead of using a custom configurePhase, just set
`configureScript = "emconfigure ./configure";` which is much simpler.
- Create writable EM_CACHE before configuring, as configure scripts
want to compile test programs.
Additionally, we need to disable the targetCC check, as it is not
applicable with emscripten which never appears as part of stdenv.
* Use generic $configureScript in installPhase to be able to work with
our emconfigure trick.
Note that the corresponding Haskell package set does not work yet. Cabal
doesn't seem to like GHC 9.7 yet and the generic-builder is clueless
about the JS backend.
Member
|
@maralorn HLS for 9.4.4 fails to eval. |
haskell.compiler.ghcHEAD: support JS backend
github-actions
bot
added
the
6.topic: systemd
This commit has been generated by maintainers/scripts/haskell/mark-broken.sh
| - Feval | ||
| - fez-conf | ||
| - ffeed | ||
| - fft |
Member
There was a problem hiding this comment.
I am not sure why fft was marked broken, it seems to build fine on hydra https://hydra.nixos.org/job/nixpkgs/trunk/haskellPackages.fft.x86_64-linux
Edit: was looking at the wrong branch https://hydra.nixos.org/job/nixpkgs/haskell-updates/haskellPackages.fft.x86_64-linux
Seems to build on nixos-23.05. Since we need it for a haskell package I am going to create a PR removing this again.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This Merge
This PR is the regular merge of the
haskell-updatesbranch intomaster.This branch is being continually built and tested by hydra at https://hydra.nixos.org/jobset/nixpkgs/haskell-updates. You may be able to find an up-to-date Hydra build report at cdepillabout/nix-haskell-updates-status.
We roughly aim to merge these
haskell-updatesPRs at least once every two weeks. See the @NixOS/haskell team calendar for who is currently in charge of this branch.haskellPackages Workflow Summary
Our workflow is currently described in
pkgs/development/haskell-modules/HACKING.md.The short version is this:
haskell-updates(normally at the beginning of a merge window).haskell-updatesintomasterevery two weeks.mergeablejob is succeeding on hydra.maintainedpackage is still broken at the time of merge, we will only merge if the maintainer has been pinged 7 days in advance. (If you care about a Haskell package, become a maintainer!)This is the follow-up to #208126. Come to #haskell:nixos.org if you have any questions.