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.
The ecj build fails in Java 8 due to backwards incompatible changes in
the `javax.lang.model` namespace so with this change we specifically ask
for a JDK for Java 7.
The last commit that touched this library updated the version number but
not the hash. I opted into fixing the version number rather than the
hash because actually updating libraw into version 0.16.1 or later
causes a build failure in libkdcraw and therefore breaks gwenview (which
is one of the main KDE apps).
GTK+ 2 is still our default, so packages should generally not depend
on GTK+ 3. For instance, this causes Emacs to depend on both GTK+ 2
and 3, which is obviously a bad thing.
Issue #8990.
Also use recurseIntoAttrs only on the default version (instead of only on 3.4).
The "self" variants (stil) don't build and they're inconsistent
versions. /cc @shlevy (fea2266290).
