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>.
I got the following error in 4 consecutive attempts:
building rts/dist/build/AutoApply.debug_o
building rts/dist/build/AutoApply.thr_o
rts_dist_HC rts/dist/build/AutoApply.debug_o
/nix/store/1iigiim5855m8j7pmwf5xrnpf705s4dh-binutils-2.21.1a/bin/ld: cannot find libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers_o_split/gmp-wrappers__1.o
collect2: ld returned 1 exit status
make[1]: *** [libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.p_o] Error 1
This change allows use of the with-packages wrapper in user profiles that are
being updated with "nix-env -u \*". The previous name this expression generated
was considered by Nix to be an older version of "ghc-7.0.4-wrapper", because
that name has a higher priority.
svn path=/nixpkgs/trunk/; revision=33325
Merge conflicts:
* unzip (almost trivial)
* dvswitch (trivial)
* gmp (copied result of `git merge`)
The last item introduced gmp-5.0.3, thus full rebuild.
+ensureDir->mkdir -p in TeX packages was catched by git but not svn.
svn path=/nixpkgs/branches/stdenv-updates/; revision=32091
I assumed that Hydra would arrive at that result anyway, but apparently
it doesn't: no x86_64-darwin builds have occurred despite the fact that
we can bootstrap on that architecture now.
svn path=/nixpkgs/trunk/; revision=28882
I have no idea whether that's going to work, and I can't test it for
lack of access to a MacOS X machine, but think chances are pretty good
that this is going to succeed.
svn path=/nixpkgs/trunk/; revision=27751
There were two problems preventing GHC 7.0.2 from being built on MacOS. For
one, the 'configure' script automatically added the flag
-isysroot /Developer/SDKs/MacOSX10.5.sdk
to the command-line that's being passed to GCC. This setting doesn't work with
our GCC, and resulted in build errors because standard headers like <stdargs.h>
could no longer be found.
Secondly, the build depends on install_name_tool, which has been added as a
buildInput.
These changes trigger a re-build on all platforms, not just on Darwin. I
realize that this could have been avoided by adding some cruft. However, I
didn't want to add cruft, so there you are.
svn path=/nixpkgs/trunk/; revision=26513
This is supposed to become the new default version of GHC once
the new Haskell Platform is released (but only then).
svn path=/nixpkgs/trunk/; revision=26217
