The previous approach of selecting the highest possible LLVM version
brought complications, especially when the latest LLVM release candidate
was properly released and the llvm-ffi version on master didn't support
this properly, yet. This would result in an eval failure that was
impossible to properly solve on master.
We only introduced the logic of selecting the latest LLVM version,
because we didn't know about the cabal flags supporting lower LLVM
versions at first. We then stuck with this approach. However, we can
also just always use the default LLVM version that is present in
`llvmPackages`. This is more in the spirit of a *default* version
anyway.
This will not result in any eval failures / warnings. There is only one
failure mode: `haskellPackages.llvm-ffi` not supporting the new default
LLVM version. In this case it's perfectly fine to wait for an update of
llvm-ffi via `haskell-updates`.
The previous approach of selecting the highest possible LLVM version brought complications, especially when the latest LLVM release candidate was properly released and the llvm-ffi version on master didn't support this, yet. This would result in an eval failure that was impossible to properly solve on master.
We only introduced the logic of selecting the latest LLVM version, because we didn't know about the cabal flags supporting lower LLVM versions at first. We then stuck with this approach. However, we can also just always use the default LLVM version that is present in
llvmPackages. This is more in the spirit of a default version anyway.This will not result in any eval failures / warnings. There is only one failure mode:
haskellPackages.llvm-ffinot supporting the new default LLVM version. In this case it's perfectly fine to wait for an update of llvm-ffi viahaskell-updates.Targeting master to unblock #437137 properly, hopefully without creating merge conflicts.
Things done
nixpkgs-reviewon this PR. See nixpkgs-review usage.Add a 👍 reaction to pull requests you find important.