All JARs in $pkg/share/java (for each $pkg in the build inputs) are
added to $CLASSPATH. Thus, you can say
buildInputs = [ setJavaClassPath someJavaDependency ];
and the JARs in someJavaDependency will be found automatically by
tools like javac or ant.
Note that the manual used to say that JARs should be installed in
lib/java; this is now share/java, following the Debian policy:
http://www.debian.org/doc/packaging-manuals/java-policy/x110.html
The directory share/java makes more sense because JARs are
architecture-independent. (Also, a quick grep shows that we were not
exactly consistent about this in Nixpkgs.)
The function ‘mkDerivation’ now checks whether the current platform
type is included in a package's meta.platform field. If not, it
throws an exception:
$ nix-build -A linux --argstr system x86_64-darwin
error: user-thrown exception: the package ‘linux-3.10.15’ is not supported on ‘x86_64-darwin’
These packages also no longer show up in ‘nix-env -qa’ output. This
means, for instance, that the number of packages shown on
x86_64-freebsd has dropped from 9268 to 4764.
Since meta.platforms was also used to prevent Hydra from building some
packages, there now is a new attribute meta.hydraPlatforms listing the
platforms on which Hydra should build the package (which defaults to
meta.platforms).
Also:
- It's now installable by doing "nix-env -i nix-generate-from-cpan".
- It maps dependencies to the correct attribute (e.g. HTML::HeadParser
is mapped to HTMLParser).
- It automatically selects buildPerlPackage or buildPerlModule.
- It's documented in the manual.
There were conflicting patches of pkgs/os-specific/linux/module-init-tools.
Apparently, the expression was updated independently in both branches. I've
resolved the conflict by preferring the patches from stdenv-updates, because
those patches appeared to be more sophisticated, i.e. they build the manual,
etc.
svn path=/nixpkgs/branches/stdenv-updates/; revision=29680
