Now development stuff is propagated from the first output,
and userEnvPkgs from the one with binaries.
Also don't move *.la files (yet). It causes problems, and they're small.
- there were many easy merge conflicts
- cc-wrapper needed nontrivial changes
Many other problems might've been created by interaction of the branches,
but stdenv and a few other packages build fine now.
This is because libxml/libxslt are not the only implementations that
respect $XML_CATALOG_FILES.
Also, look in share/xml for catalogs (in addition to the
now-deprecated xml/dtd and xml/xsl).
This should fix the OpenJDK build, which was failing because paxctl is
in sbin and therefore not automatically added to $PATH.
http://hydra.nixos.org/build/15658346
Now it should contain *all* information from stdenv/setup.sh of
the original mutiple-output branch.
However, the configurability of the output paths is much greater.
This hook allows to scatter files in $out to multiple outputs.
For "bin" and "doc" outputs there are prefefined default masks, but
they can be overriden by setting files_<outname>, for example:
files_bin = [ "/bin/*" "/lib/libexec/" ];
To make an effect hook must be specified in buildInputs.
Stdenv adapters are kinda weird and un-idiomatic (especially when they
don't actually change stdenv). It's more idiomatic to say
buildInputs = [ makeCoverageAnalysisReport ];
Install names need to be absolute paths, otherwise programs that link
against the dylib won't work without setting $DYLD_LIBRARY_PATH. Most
packages do this correctly, but some (like Boost and ICU) do not.
This setup hook absolutizes all install names.
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.)
