* Will make it so that GHC.Paths's docdir NIX_GHC_DOCDIR points to an
actual directory.
* Documentation of all packages in the environment is available in
`$out/share/doc`.
This has previously been attempted in #76842 and reverted in #77442,
since documentation can collide when the libraries wouldn't (thanks to
the hash in the lib filename). `symlinkJoin` allows collision, so this
solution should be akin to #77523 (minus `buildEnv`, one step at a
time). `installDocumentation = false` restores the old behavior.
Collision in the documentation only happen if the dependency closure of
the given packages has more than one different derivation for the same
library of the very same version. I'm personally inclined not to claim
that our infrastructure does anything sensible in this case.
Additionally, the documentation is likely largely the same in such
cases (unless it is heavily patched).
Resolves#150666.
Resolves#76837.
Closes#150968.
Closes#77523.
This is done for consistency with generic-builder.nix and because it's
easier for downstream users to replicate which will inevitably use our
code as inspiration.
Adding a fake override function via passthru will at least give users of
the old override interface a more helpful error message. Additionally we
also document the changes in the changelog.
This is achieved by passing the entire package set to the respective
wrappers and passing the select function as a second attribute. Together
with the new support for callPackage-ing functions this allows for
things like `ghcWithPackages.override { useLLVM = true; } (p: [ … ])`.
To make this possible for `ghcWithHoogle` as well, we need to make the
wrapper a bit more bespoke and inline the hoogle feature as well. The
hoogle wrapper, however, can remain separate and is exposed as
`hoogleWithPackages` additionally, as it can also serve standalone use.
`hoogleLocal` is kept for backwards compatibility (including the old,
suboptimal API), but will inform users about the better alternative via
a warning.
Since GHC now will have LLVM available when needed, we don't need to add
it in the wrapper anymore. It can still be added if NCG is available,
but -fllvm should be used (e. g. to work around an NCG bug).
useLLVM is what we are using in the GHC derivations already -- for
better or for worse -- so we should rename the argument here for
consistency which we are free to do as this is purely internal at the
moment (with overriding being impossible).
This check was wrong and caused by a bit of confusion on my part.
GHC >= 8.10.5 && < 9 supports aarch64-darwin via LLVM and GHC >= 9.2.1
introduces the NCG backend for aarch64-darwin.
Based on https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms, although
it sadly doesn't list when the backends were introduced.
* PowerPC, x86 (and x86_64) and Sparc have been supported for longer.
* aarch64-darwin is new in 9.2.1 and backported to 8.10.5, 8.10.6 and
8.10.7 (check is dumb here since we'll grep for 8.10.7 anyways when
upgrading)
Fixes ghcWithPackages failing to evaluate on aarch64-darwin because of
missing support for the platform in LLVM 9's compiler-rt.
The availability of native codegen (which allows us to disable the LLVM
backend by default) hinges on the target platform of the compiler (that
is GHC), not on the platform it runs on (the host platform).
Now that `buildEnv` is ready, always put `makeWrapper` in
`nativeBuildInputs`, rather than `buildInputs` or (worse) mucking around
with setup hooks by hand.
(C.f. #112276, which didn't catch these because the manual setup hook
sourcing is such a hack to being with!)
Fixes#114687
While we are at it I:
* Disable tests, because I can‘t keep up with the speed hls introduces
more tests that cause trouble in nixpkgs.
* Fix builds of fourmolu and retrie
* Remove the wrapper for hls which is obsolete because of improved
package detection in hie-bios. And added a note that this can be removed
for ghcide soon, too.
`with-packages-wrapper.nix` has a hack to workaround the linker limit
in MacOS Sierra. However that is now broken with GHC 8.8, because of
slight change in the format of the package config.
In short, the package config produced by GHC 8.8 has a new line between
the key and list of values, while earlier versions have them separated
by a single space.
This PR fixes the linker hack by modifying the `grep` and `sed` commands
to pattern match on either space or new line, so that the hack can work
on all versions of GHC.
This closes#79441.
ghcWithPackages is using `ghc-pkg recache` to build its package
database. By doing so, it overrides the `package.cache[.lock]` files.
Details are unclear, but GHC 8.10 changed a bit the behavior.
Previously, it was unconditionally replacing the files by new ones. Now
it tries to open (for modification) the files. These files are symlinks
to another nix derivation, which is hence read-only.
This commit removes the files before running `ghc-pkg recache`, hence it
will just write the new files.
Tested with `haskellPackages.ghcWithPackages` (i.e. GHC 8.8) and
`haskell.packages.ghc8101.ghcWithPackages` (i.e GHC 8.10) with the
following nix file, at the root of the nixpkgs repository:
```
with import ./. {
overlays = [
(
self: super: {
haskellPackages = super.haskell.packages.ghc8101.override {
overrides = selfh: superh: {
th-lift-instances = super.haskell.lib.doJailbreak superh.th-lift-instances;
th-expand-syns = super.haskell.lib.doJailbreak superh.th-expand-syns;
th-reify-many = super.haskell.lib.doJailbreak superh.th-reify-many;
th-orphans = super.haskell.lib.doJailbreak superh.th-orphans;
haskell-src-meta = super.haskell.lib.doJailbreak superh.haskell-src-meta;
};
};
}
)
];
};
haskellPackages.ghcWithPackages(p:[p.PyF])
```
This will test with GHC 8.10. Comment out the `overlays` to test with
GHC 8.8.
The Sierra linker added a limit on the number of paths that any one
dynamic library (`*.dylib`) can reference. This causes problems when
a Haskell library has many immediate dependencies (#22810).
We follow a similar fix as GHC/Cabal/Stack: for each derivation,
create a new directory with symlinks to all the dylibs of its immediate
dependencies, and patch its package DB to reference that directory
using the new `dynamic-library-dirs` field.
Note that this change is a no-op for older versions of GHC, i.e., they will
continue to fail on some packages as before.
Also note that this change causes the bootstrapped versions of GHC to be
recompiled, since they depend on `hscolour` which is built by
`generic-builder.nix`.
Tested by building the `stack` binary as described in #22810.
