It sucks, I know, but GHC just doesn't compile reliably when built with
some -j<n> option. :-( We have build errors because of apparent race
conditions all over the place on Hydra. This causes so much trouble for
users that it's not worth keeping this option enabled, IMHO.
1) The wrapper erroneously used the ghc-pkg flag "--package-db" instead of
"--global-package-db". The result was that packages installed locally in
~/.ghc and ~/.cabal were invisible to GHC. This has been fixed.
2) The wrapper now deals gracefully with an empty package set: if no package
is requested to be included in the wrapped environment, the wrapper just
installs a pristine GHC.
3) Correctly configure the "docdir" path returned by ghc-paths.
4) Added some comments that describe the idea behind our ghc-paths patches and
gives users same sample shell code that can be used to import our special
environment variables into the currently running shell, so that programs
outside of the wrapped environment can use them, too.
The ghcWithPackage expression now has an argument 'ignoreCollisions' that
allows users to disable the path collision check like so:
(pkgs.haskellPackages.ghcWithPackages (pkgs: with pkgs; [ haskellPlatform ])).override { ignoreCollisions = true; };
See d64917ad17
for a long and detailed discussion of why these path collisions may occur.
Haskell packages -- i.e. packages built by our Cabal builder -- invariably have
the attributes 'pname' and 'version'. We use the absence of these attributes to
recognize non-Haskell packages and filter them from the closed package set
generated by closePropagation. We do this so that the generated Haskell
environment won't contain paths like "/lib/libz.a", which are part of the
closure but have nothing to do with Haskell.
The previous scheme used the attribute 'ghc' to accomplish the same thing, but
unfortunately other packages to contain a 'ghc' attribute, too, like the
old-style ghc-wrapper. Including the ghc-wrapper in this environment is
pointless, obviously. The new approach filters the ghc-wrapper successfully.
* There now is full support for building Haskell packages as shared libraries
for GHC versions 7.4.2 or later. The Cabal builder recognizes the following
attributes:
- enableSharedLibraries configures Cabal to build of shared libraries in
addition to static ones. This option requires that all dependencies of
the package have been compiled for use in shared libraries, too.
- enableSharedExecutables configures Cabal to prefer shared libraries when
linking executables.
The default values for these attributes are arguments to the haskellPackages
expression.
* Haskell builds now run in a LANG="en_US.UTF-8" environment to avoid plenty
of build and test suite errors. Without this setting, GHC seems unable to
deal with the UTF-8 character encoding that's generally considered standard
in the Haskell world.
* The Cabal builder supports a new attribute 'testTarget' to specify the exact
set of tests to be run during the check phase.
* The ghc-wrapper attribute ghcVersion has been removed. Instead, we use the
ghc.version attribute, which exists in unwrapped GHC derivations, too.
The change was supposed to trigger a re-build to fix a broken GHC binary
on the Hydra build farm, but now it turns out that the cause for the
errors we're seeing isn't GHC: all kinds of (non-Haskell) packages are
broken.
Conflict in kerberos, which was updated both in master and in
stdenv-updates. Kept the stdenv-updates version, except pulled in the
enableParallelBuilding change from master.
Signed-off-by: Shea Levy <shea@shealevy.com>
Conflicts:
pkgs/development/libraries/kerberos/krb5.nix
The wrapper script accumulated some cruft over the last couple of months
because we did changes in freaky ways to avoid triggering re-builds of all
Haskell packages. Most of these kludges have been thrown out now.
This patch doesn't change the behavior of the wrapper except for one thing: the
internal helper scripts "ghc-get-packages.sh" and "ghc-packages.sh" are no
longer installed in the bin directory of the generated derivation.
The freaky implementation was done that way in order to avoid unnecessary
re-builds of all Haskell packages by changing the wrapper script used
internally in those builds.
See <https://github.com/NixOS/nixpkgs/pull/466> for further details.
Conflicts:
pkgs/development/libraries/libxslt/default.nix
Commit 1764ea2b0a introduced changes to libxslt
in an awkward way to avoid re-builds on Linux. This patch has been simplified
during this merge.
This predicate filters out packages that weren't created by the Cabal builder.
Doing that greatly reduces the likelihood of file collisions in the generated
environment, because Haskell packages tend to have a lot of propagated build
inputs.
For example, both zeromq 2.x and 3.x use the same names for their header files.
Users of haskell-zeromq don't need those headers, so we just don't include them
in the generated environment to avoid the collision that would otherwise occur
when haskell-zeromq 2.x and 3.x are installed into the same environment.
uses for its core libraries, so that these files integrate seamlessly into one
profile, living right next to each other. This change is eventually going to
simply our with-packages wrapper quite a bit.
When the ghc-paths library is compiled, the paths of the
compiler it is compiled with are being hardcoded in the
library (and can then be queried from other applications
using the library).
But on Nix, packages are compiled with ghc-wrapper, and
subsequently possibly used with a special version of ghc
generated for a particular environment of packages. So
one version of ghc-paths may potentially end up being
used by lots of different instances of ghc. The hardcoding
approach fails.
As a work-around, we now patch ghc-paths so that it allows
setting the paths that can be queried via environment
variables. Specific GHC environments can then set these
environment variables in the wrapper shell script that
invokes GHC.
This should at least partially solve issue #213.
Any attempt to instantiate these expressions on an unsupported platform is
going to 'throw' an error. The call to 'assert' doesn't add any value to
that (and generates less readable error messages, too). Further details are
available at <https://github.com/NixOS/nix/issues/56>.
