From da3658f1bf26a6720d7958f588c553766e283151 Mon Sep 17 00:00:00 2001 From: Ilya Kolpakov Date: Mon, 6 Nov 2017 15:13:35 +0100 Subject: docs: multiple outputs: now mentions glibc as not having executables in the first output contrary to the convention --- doc/multiple-output.xml | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/multiple-output.xml b/doc/multiple-output.xml index a2acc91e55a2..dc389c6757af 100644 --- a/doc/multiple-output.xml +++ b/doc/multiple-output.xml @@ -36,10 +36,16 @@ Here you find how to write a derivation that produces multiple outputs. In nixpkgs there is a framework supporting multiple-output derivations. It tries to cover most cases by default behavior. You can find the source separated in <nixpkgs/pkgs/build-support/setup-hooks/multiple-outputs.sh>; it's relatively well-readable. The whole machinery is triggered by defining the outputs attribute to contain the list of desired output names (strings). outputs = [ "bin" "dev" "out" "doc" ]; - Often such a single line is enough. For each output an equally named environment variable is passed to the builder and contains the path in nix store for that output. By convention, the first output should contain the executable programs provided by the package as that output is used by Nix in string conversions, allowing references to binaries like ${pkgs.perl}/bin/perl to always work. Typically you also want to have the main out output, as it catches any files that didn't get elsewhere. - + Often such a single line is enough. For each output an equally named environment variable is passed to the builder and contains the path in nix store for that output. Typically you also want to have the main out output, as it catches any files that didn't get elsewhere. There is a special handling of the debug output, described at . +
+ <quote>Binaries first</quote> + A commonly adopted convention in nixpkgs is that executables provided by the package are contained within its first output. This convention allows the dependent packages to reference the executables provided by packages in a uniform manner. For instance, provided with the knowledge that the perl package contains a perl executable it can be referenced as ${pkgs.perl}/bin/perl within a Nix derivation that needs to execute a Perl script. + The glibc package is a deliberate single exception to the binaries first convention. The glibc has libs as its first output allowing the libraries provided by glibc to be referenced directly (e.g. ${stdenv.glibc}/lib/ld-linux-x86-64.so.2). The executables provided by glibc can be accessed via its bin attribute (e.g. ${stdenv.glibc.bin}/bin/ldd). + The reason for why glibc deviates from the convention is because referencing a library provided by glibc is a very common operation among Nix packages. For instance, third-party executables packaged by Nix are typically patched and relinked with the relevant version of glibc libraries from Nix packages (please see the documentation on patchelf for more details). +
+
File type groups The support code currently recognizes some particular kinds of outputs and either instructs the build system of the package to put files into their desired outputs or it moves the files during the fixup phase. Each group of file types has an outputFoo variable specifying the output name where they should go. If that variable isn't defined by the derivation writer, it is guessed – a default output name is defined, falling back to other possibilities if the output isn't defined. -- cgit 1.4.1