In #424368, there was some confusion whether glibcLocales should come from
buildPackages or pkgsHostTarget since there were seemingly different pieces
of code in generic-builder.nix. As it turns out, the plain glibcLocales was
inherited from buildPackages, so there was no actual difference. Making this
explicit everywhere should clear things up.
Fixes errors:
- user specified .o/.so/.DLL could not be loaded (addDLL: pthread or dependencies not loaded. (Win32 error 126))
- iserv-proxy-interpreter.exe:Couldnotload`libwinpthread-1.dll'.Reason:addDLL:libwinpthread-1.dllordependenciesnotloaded.(Win32error126)
Fixes error:
wine: failed to open "/nix/store/5hhjpr2hgz7pyzhpl2hrl0pgmh8sczaq-iserv-proxy-x86_64-w64-mingw32-9.3-unstable-2025-06-21/bin/iserv-proxy-interpreter": c0000135
This is particularly relevant for us because we include
objects in haskell derivation outputs, and this fixes
reproducibility for a significant number of those.
Towards #151347
This is useful so that you can call `Setup build` on other targets e.g.
for code generation while still having the same flags.
The context that led me to write this patch is that we have HIE file
generation in an overlay at work and I was packaging Glean, which
requires a code gen component get built, and it was building twice due
to the hie flags not getting propagated to the Setup build commands I
was running manually.
`stdenv.mkDerivation` does not require meta.license to be passed, so there
is no reason `haskellPackages.mkDerivation` needs to enforce this. This
would free up cabal2nix to not report a license if it is not sure.
As I have argued in https://github.com/NixOS/cabal2nix/pull/677#issuecomment-3444635379,
it is better not to report a license than reporting an inaccurate one.
This would also allow to stop generating arbitrary strings as licenses
in cabal2nix to remove string values to facilitate more cleanliness in
the spirit of https://github.com/NixOS/nixpkgs/pull/445672, though the
question is whether it is wise to remove the meta data altogether.
Since Cabal only allows a single cabal file per directory, we can just
jailbreak *.cabal which works even if the user doesn't have set pname to
match the cabal file name (which they SHOULD do, though).
The only remaining reference to ${pname}.cabal in the revision handling
code is fine since we know the proper name of the cabal file from
Hackage in that case.
In general, `pname` SHOULD be the same as the Cabal package name in
Haskell updates, but things work fine without this in many cases (e.g.
when only building executables), so we need to preserve this.
Since Cabal only allows a single .cabal file per directory, we can just
process *.cabal.
Automatically use sed(1) to remove DOS line endings from .cabal files.
This is intended to work around Hackage producing revised cabal files
with DOS line endings (https://github.com/haskell/hackage-server/issues/316).
This frequently leads to
- patches failing to apply. Unfortunately there is no way to apply a
patch with Unix line endings to a file with DOS line endings with
GNU patch(1). Only the following combinations are supported:
file patch comment
Unix Unix
DOS DOS using --binary
DOS Unix Haven't tested it, but I assume it works because
patch(1) converts the file to Unix line endings
implicitly (which can be disabled using --binary),
but never the patch…
- Test suites sometimes involve the .cabal file which can be
affected by the line endings.
This behavior is enabled by default to prevent cases where (unrevised)
packages regress when they get a revision later. Of course, the behavior
is a little nonsensical for non-Hackage packages, but it is probably
rarely an issue in practice. When DOS line endings need to be preserved,
the user can pass `dontConvertCabalFileToUnix = true`.
Supersedes #279248.
Resolves#206840.
This was used for bootstrapping GHC on powerpc64le, but it's unclear
whether that actually still works. It makes no sense to pretend to
support it, when it's most likely broken, but we can't even verify.
Also the bootstrap chain will be broken once we drop GHC 8.10.7, so we
might as well drop the whole thing.
This affects haskelPackages.mkDerivation, ghcWithPackages and
hoogleWithPackages which means that it is not possible to re-introduce
a ghcjs derivation downstream and create a ghcjs package set with an up
to date Nixpkgs.
Previously, setting environment variables in a Haskell package build
required using `.overrideAttrs`, which (I think?) breaks later
invocations of `haskell.lib.overrideCabal`.
This patch adds an `env` argument to `haskellPackages.mkDerivation`,
which can be used to set environment variables during Haskell package
builds.
Fixes build of `pkgsCross.aarch64-android-prebuilt.haskell.packages.ghc910.attoparsec`:
```
RPATH of binary /nix/store/g6ncgk2b04mv722hh2jgfbixyawbwabv-attoparsec-aarch64-unknown-linux-android-0.14.4/lib/ghc-9.10.1/lib/aarch64-android-ghc-9.10.1-inplace/libHSattoparsec-0.14.4-GkMCGqk5eKArKmd1r9IB7-ghc9.10.1.so contains a forbidden reference to /build/
```
testTarget takes a space separated list of test suites to run. We itnroduce a new testTargets argument that instead takes a list, and add a backwards compatibility shim
Alexandre Esteves