The generated shell.nix file accepts a string argument called "compiler" that
determines the package set used to instantiate the generated expression. For
example, running "nix-shell --argstr compiler ghc7102" would evaluate the build
inside of "pkgs.haskell.packages.ghc7102". Earlier versions of cabal2nix had the
current default compiler hard-coded in the expression, but after this change this
is no longer the case. When "compiler" remains unspecified, it defaults to
"default", and this value causes evaluation in "pkgs.haskellPackages", which is
the package set most people would like to use by default. That change has to
benefits:
1) Generated expression no longer contain any particular compiler version. The
choice of the default compiler depends on the version of Nixpkgs that's used
to build the expression.
2) When the default compiler is used, overrides configured for the default
package set apply, which was not the case in earlier versions.
This update greatly enhances the accuracy with which dependencies are expressed
in the generated Nix files. Previous versions distinguished dependencies for
building ("buildDepends") and testing ("testDepends"). This distinction didn't
apply to system packages or build tools, however: the fields "extraLibs" and
"buildTools" applied to the entire build. This meant that dependencies required
only for testing would be pulled in regardless of whether the test were
actually being run, etc.
These days, we distinguish dependencies for libraries, executables, and tests,
and for each of those types we distinguish dependencies on Haskell libraries,
system libraries, pkgconfig libraries, and build tools. This gives us a
whopping 12 new attributes
xxxHaskellDepends
xxxSystemDepends
xxxPkgconfigDepends
xxxToolDepends
where "xxx" is any of "library", "executable", or "test".
The old dependency attributes are no longer generated by cabal2nix. The generic
builder in Nixpkgs still accepts them, though, for the sake of backwards
compatibility. This means that you don't have to re-generate all your build
expressions with the new version, but you *should*.
If gnum4 is built outside of a chroot, it will decide to use
/run/current-system/sw/bin/sh as the shell for "syscmd". (It gets this
path via "getconf PATH". Maybe our Glibc shouldn't return that path,
at least not during Nix builds...) If such a build of gnum4 is
subsequently used *inside* a chroot, it won't work because
/run/current-system doesn't exist. So specify an explicit path to the
shell.
Bazel 981b7bc1 depends on protobuf-2.5 and won't work with 2.6 (and in
bbe84fe3d upgraded straight to protobuf 3.0.0-alpha3); this commit fixes
the dependency to depend on protobuf2_5 specifically.
The bazel compile.sh needs `which` on the PATH; so this commit adds that
as a dependency.
Setting JAVA_HOME to ${jdk} broke bazel when used with openjdk, with the
message:
Problem with java installation: couldn't find/access rt.jar in /nix/store/z9vc0vzyzhnpl5l5inmqdnvdnbxmmmg7-openjdk-8u60b24
This is because if you set JAVA_HOME, bazel will look for rt.jar in
$JAVA_HOME/lib and $JAVA_HOME/jre/lib, but the nixpkgs openjdk
distribution puts rt.jar in ${jdk}/lib/openjdk/jre/lib for some reason.
To fix this, this commit uses the ${jdk.home} passthru value to use the
appropriate JAVA_HOME for the given jdk.
As bazel now works with openjdk, and openjdk is free while oraclejdk is
not, this commit changes the default jdk for bazel to openjdk.
Since this package didn't have a listed maintainer, I'm claiming it.
An interesting thing is that: stdenv != overrideCC stdenv gcc49;
I'm not sure why that is, but it doesn't seem important.
/cc maintainers: @nckx, @garbas, @abbradar, @cstrahan, @grwlf.
(cherry picked from commit 3064b6a0cc)
