Fixes#9044, close#9667. Thanks to @taku0 for suggesting this solution.
Now we have no modes starting with `/` or `+`.
Rewrite the `-perm` parameters of find:
- completely safe: rewrite `/0100` and `+100` to `-0100`,
- slightly semantics-changing: rewrite `+111` to `-0100`.
I cross-verified the `find` manual pages for Linux, Darwin, FreeBSD.
By default `makeWrapper` will not set argv[0] (this is a reversion to
the old default behavior). Based on the breakage we have seen from
changing the default, this is what most people want. The `wrapProgram`
function will send `--argv0 '"$0"'` to `makeWrapper`, i.e. it will
continue to pass-through the argv[0] that the wrapper is called with.
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
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.)
