Comparing to a default value to detect if an argument was provided
forces it to at least WHNF, which can cause failure (e.g., if the
argument is a string with a quoted path from a broken package).
Allow the darwin links code to overwrite libs that were already
copied, because C dependencies can occur multiple times.
Solves errors like
ln: failed to create symbolic link '/nix/store/higpc9xavwcjjzdipz7m9ly03bh7iy2z-hercules-ci-agent-source-0.7.0/lib/links/libboost_context.dylib': File exists
Raise the maximum number of cores used for parallel building from 4 to 16.
Increase the size of the allocation area for GHC's garbage collector from 1 MiB
to 64 MiB.
See https://www.twitch.tv/videos/611899011 for the motivation for this change.
Recent updates to the generic builder have caused haskellPackages.lmdb-simple to
fail to build on Darwin, since it cannot see the lmdb C dynamic library included
by its dependent haskellPackages.lmdb.
The C dynamic library has suffix `.so` not `.dylib`, so this fix allows for
that.
Closes#80190, but that issue may identify a preferable solution.
Previously the package conf files were handled without paying attention
to the fact that it's pretty-printed output. One problem was discovered
with GHC 8.8.1 on Darwin, where the dynamic-library-dirs first field
seems to have increased in length, meaning while before it was
dynamic-library-dirs: some-small-directory-name
some-more-directories
Now it is
dynamic-library-dirs:
some-larger-directory-name
some-more-directories
Which breaks the code installed for https://github.com/NixOS/nixpkgs/pull/25537,
because that assumed the former format, resulting in the reoccurence of
the bug in https://github.com/NixOS/nixpkgs/issues/22810, see
https://github.com/Infinisil/all-hies/issues/43
This commit fixes this by "unprettyfying" the package conf files before
processing them.
Closes https://github.com/NixOS/nixpkgs/pull/78738.
This makes it work like work-on-multi from Reflex Platform. In
particular, rather than making `.env` from `shellFor`, we make `.env`
the primitive, and `shellFor` works by combining together the arguments
of all the packages to `generic-builder` and taking the `.env` of the
resulting mashup-package.
There are 2 benefits of this:
1. The dependency logic is deduplicated. generic builder just concatted
lists, whereas all the envs until now would sieve apart haskell and
system build inputs. Now, they both decide haskell vs system the same
way: according to the argument list and without reflection.
Consistency is good, especially because it mean that if the build
works, the shell is more likely to work.
2. Cross is handled better. For native builds, because the
`ghcWithPackages` calls would shadow, we through both the regular
component (lib, exe, test, bench) haskell deps and Setup.hs haskell
deps in the same `ghcWithPackages` call. But for cross builds we use
`buildPackages.ghcWithPackages` to get the setup deps. This ensures
everything works correctly.
When visiting local documentation via hoogle, currently for most packages the
quickjump index is missing so you only get a sad error when pressing "s" to
search in the current documentation.
The quickjump option is only supported by the haddock utility that's shipped
with ghc 8.6.x or later.
Closes https://github.com/NixOS/nixpkgs/pull/75942.
This commit disables the library-for-ghci flag passed to
`Setup configure` in the Haskell generic-builder.nix file.
This stops the HSfoo.o file from being built. Building this
HSfoo.o file caused doctest to take an extremely long time
to load dependencies when running.
This is a follow-up from https://github.com/NixOS/nixpkgs/pull/58743.
In order to build the package databases that we will use when compiling
a Haskell package, we iterate over the relevant dependencies, and if
they contain a package db, we copy its contents over.
So far so good, except when one of those dependencies is GHC. This
doesn't happen ordinarily, but it will happen when we construct the
package database for compiling `Setup.hs`. This is compiled for the
build architecture, so we get the build deps, including both the native
and the cross GHC (if there is one).
In this case, we end up copying the packages from the GHC's package
database. This is at best unnecessary, since we will get those packages
from the GHC when we compile with it.
At worst, however, this is semantically questionable. We can end up
having multiple copies of e.g. Cabal with the same version, but
(potentially) different contents. At the moment, GHC will expose one of
these at semi-random depending on which one it looks at "first".
However, there is a MR open [in
GHC](https://gitlab.haskell.org/ghc/ghc/merge_requests/545) which as a
side effect will instead expose both, leading to ambiguous module
warnings (which is not unreasonable, since it *is* ambiguous).
So what can we do about it? The simplest solution is just to not copy
the package databases from GHC. GHC is special in this regard, so I
think it's okay to treat it specially.
This PR should have no effect on anything now, but will prevent any
breakage when/if the GHC patch lands.
Closes https://github.com/NixOS/nixpkgs/pull/57706.
`all-functions` corresponds to `-fprof-auto` which places an SCC on every binding. It is well known that SCCs hinder GHC from doing its optimization magic and really slows down profiled code to a point where the profiling reports are completely skewed towards things that were completely optimized away in production settings. Concretely this shows up with things like lenses which do not carry runtime overhead when properly simplified.
`exported-functions` corresponds to GHCs `-fprof-auto-exported` which doesn't put SCCs on `INLINE`d code and in turn doesn't influence simplification of this basic but important stuff.
This commit is not really correct. The `hasActiveLibrary` check is wrong.
We can have an active library even if we do not ask for a static lirbary or
dynamic one; we can still have just a set of objet files and archives.
If empty directory isn't deleted, referer depenedencies will
fail with:
cp: missing destination file operand after '/tmp/nix-build-cabal-helper-0.8.0.2.drv-0/setup-package.conf.d/'
This is currently only the case for cabal-install, as cabal2nix
doesn't handle well buildable=False flags due to long-standing bugs
in Cabal itself.
This was reverted in 6e07a3a19a with the
other commits in the PR, as the number of overrides added in that PR was deemed
excessive. But this commit adds no overrides, and is valuable on its
own, so I am adding it back.
(cherry picked from commit 359e0ce4bb)
