haskellPackages.llvm-ffi: set LLVM#227424
Conversation
|
Must |
|
Yeah, that’s correct please remove the package from I am not 100% certain about the LLVM override. @sternenseemann is that okay this way? |
|
Just managed to properly unmark llvm-ffi as broken. In case anyone else wants to unmark a package as broken the steps are
The documented method in HACKING.md does not cover removing packages from broken.yaml |
|
@MaxHearnden that’s actually not quite right. Running Also, the So the correct steps are:
and then optionally if you want to go the extra mile and see the effect for all dependencies on hydra as soon as possible:
|
|
I have hopefully done it correctly this time |
|
It is preferred to rebase PR branches on top of the target instead of merging the target branch back in again. |
There was a problem hiding this comment.
Does it more sense to use the default LLVM (i.e. self.llvmPackages.libllvm) used for the compiler (maybe just to reduce closure size in some cases)? Seems like llvm-ffi supports multiple versions.
|
On Sat, 22 Apr 2023, sternenseemann wrote:
@sternenseemann commented on this pull request.
____________________________________________________________________________________________________
In pkgs/development/haskell-modules/configuration-common.nix:
> @@ -2621,4 +2621,6 @@ self: super: {
# compatability with other gi- packages.
# Take another look when gi-webkit2 updates as it may have become compatible with libsoup-3
gi-soup = assert versions.major self.gi-webkit2.version == "4"; self.gi-soup_2_4_28;
+
+ llvm-ffi = super.llvm-ffi.override {LLVM = pkgs.llvmPackages_13.libllvm;};
Does it more sense to use the default LLVM (i.e. self.llvmPackages.libllvm) used for the compiler
(maybe just to reduce closure size in some cases)? Seems like llvm-ffi supports multiple versions.
I cannot promise that I always support the version that is chosen by Nix
as default for GHC. What versions of GHC and LLVM have you chosen for the
next NixOS release?
|
|
We currently use llvm 12, and I don’t expect that to change before branch-off. |
|
On Sun, 23 Apr 2023, maralorn wrote:
We currently use llvm 12, and I don’t expect that to change before branch-off.
Then llvm-ffi must be built with Cabal flag "llvm1200" enabled.
|
|
GHC chooses a range of supported LLVM versions and we have different ones per package set as a result. Since the newer GHC versions already support LLVM 14, it seems reasonable to assume that llvm-ffi doesn't keep up, so maybe pinning the version is the best course of action. Worst case is that you have to download LLVM twice when building |
|
I have, regenerated haskell packages using the updated script, set llvm to llvm 12 and enabled the cabal flag. |
|
But if we are pinning for the convenience of llvm-ffi anyway, why not leave it at pinning llvm 13? |
|
I have simplified it to only using llvm 13 although pinning on llvm 12 would ensure that it doesn't break when llvm-ffi updates to llvm 14 |
|
Fair point, but then we notice the build error and can update the pin to llvm 14 so that’s basically what we want. Thank you for bearing with us! |
|
I have updated |
|
@thielema Apparently LLVM 16, if I understand this correctly. https://discourse.nixos.org/t/breaking-changes-announcement-for-unstable/17574/37 |
Description of changes
Overrides LLVM from null to llvmPackages_13.libllvm
Fixes #227412
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)