| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The code of `lib.closePropagation` was internally using a
recursion on the dependencies and returns all the derivation directly or
indirectly referenced by buildInputs.
`lib.closeProgation` is implemented in pure nix and uses an unique
function for list which is quadratic and does "true" equality, which
needs deep set comparison.
Instead, we use the `builtins.genericClosure` which is implemented as a
builtin and uses a more efficient sorting feature.
Note that `genericClosure` needs a `key` to discriminate the values, we
used the `outPath` which is unique and orderable.
On benchmarks, it performs up to 15x time faster on a benchmark related
to haskellPackages.ghcWithPackages.
|
|
This is a follow up to the discussion in https://github.com/NixOS/nixpkgs/pull/165337
|
|
|
|
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.
|
|
Workaround for https://github.com/NixOS/nixpkgs/issues/82245
Although this doesn't tackle the root cause of a null package sneaking
in (via executableHaskellDepends), it does effectively treat the symptom
by just ignoring any null packages.
Seeing as that issue has been open for more than a year I think this
band-aid is necessary.
|
|
Signed-off-by: Ben Siraphob <bensiraphob@gmail.com>
|
|
|
|
Use `buildPackages.stdenv.mkDerivation` because we are making a shell
script to start hoogle on the build platform.
|
|
This is necessary when a very large number of packages are included in the
package database. Without this change, setting up the build environment will
fail, since the environment will be too large.
This simply applies the technique mentioned in
https://github.com/NixOS/nixpkgs/issues/25057 to solve this problem.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously a few clumsy shell globs were used to find haddock output, which
broke every time something in `generic-builder.nix` changed.
Use the new `haddockDir` identifier exported by haskell packages.
|
|
`haskell.packages.ghcjs.ghcWithHoogle` failed because the following line:
for docdir in ${ghc.doc}/${docLibGlob}/*; do
failed because `doc` is not an attribute of `ghc` when `ghc` is
substituted for ghcjs.
|
|
Building hoogle environments with an empty list of packages threw a built-time
error. This was particularly confusing when giving e.g. `(hps: [hps.Cabal])`
which, since `Cabal` is set to `null` (because it’s a distribution package),
would have lead to the same error as an empty list.
It was not useful to throw an error at all, because sometimes one only wants to
build an environment for the distribution packages; also the default value for
packages wasn’t even a valid value, so it is removed.
|
|
|
|
The docs were split at #16167 and broke google support. @peti fixed
build, however hoogle still didn't see packages shipped with GHC. This
patch fixes location of the libraries shipped with GHC.
|
|
https://github.com/NixOS/nixpkgs/pull/16167
ghcWithHoogle builds with this patch applied, but it's probably still broken in
the sense that links might point nowhere or that the generated databases and/or
documentation might be incomplete.
|
|
|
|
|
|
for database creation
|
|
* Build most of the stuff on /tmp, not in /nix/store.
* Generate hoogle database for all the dependencies.
* Generate haddock index and contents files.
* Cleanup.
|
|
Replace `ghcWithPackages` to `ghcWithHoogle` in your config and enjoy.
|
|
|
