This makes `justStaticExecutables` error if the produced store path
contains references to GHC. This is almost always erroneous and due to
the generated `Paths_*` module being imported. This helps prevent
`justStaticExecutables` from producing binaries with closure sizes in
the gigabytes.
See: https://github.com/NixOS/nixpkgs/issues/164630
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
This changes `haskell.lib.packagesFromDirectory` to ignore non-Nix
files so that it doesn't attempt to run `callPackage` on, say, a
`.md` file in the same directory.
The current workaround for the regression is propagating the
runtime dependency closure (technically only Requires.private in the
pkg-config files). This can easily be done automatically by mimicking
how e.g. pkgsStatic converts buildInputs to propagatedBuildInputs.
This is extracted into a helper function,
__CabalEagerPkgConfigWorkaround, which can be applied to any package
easily.
This restarts a Haskell section in the nixpkgs manual. The content
presented here has been written from scratch, although some parts of it
take inspiration from the existing haskell4nix documentation.
It is by no means complete, the idea is mostly to get the ball rolling
in some way. Upcoming tasks are hinted at in the comments in the
documentation file.
Deprecate haskell.lib{,.compose}.generateOptparseApplicativeCompletion*
in favor of the newly added
haskell.packages.*.generateOptparseApplicativeCompletions (plural!)
which takes into account whether we are cross-compiling or not. If we
are, generating completions is disabled, since we can't execute software
built for a different platform.
The move is necessary, so we can receive the /same/ stdenv as the
package we are overriding in order to accurately check whether we can
execute produced binaries.
Resolves#174040.
Resolves#49648.
release-lib.nix's packagePlatforms will (understandably) take
hydraPlatforms at face value, so we need to make sure that we don't slip
anything actually unsupported in there.
This reflects the default value set in generic-builder.nix, following
the reasoning that GHC can cross-compile and we assume that packages are
generally portable.
1. Putting the string on one line (instead of using a multiline
string) means it is not ended with \n, which means if somebody wants
to append more lines, they have to start it with \n or it will get
concatenated to the `postFixup` here, so add \n.
2. Previously, ignoring `drv.postFixup` would throw away any
`postFixup`s set in `drv`, which is not something we want.
The extra empty line is a cute trick to prevent concatenating the code
with any previous `postFixup` that doesn’t end in \n.
