summary refs log tree commit diff
path: root/doc
diff options
context:
space:
mode:
authorVladimír Čunát <vcunat@gmail.com>2018-04-22 11:55:23 +0200
committerVladimír Čunát <vcunat@gmail.com>2018-04-22 11:55:23 +0200
commit17c4b83d05931bdc1364419b8264ea2c15b23223 (patch)
treef5a111724caf06466ecb069e53f0e117af86536e /doc
parenta1703436af652c435559278043bd5c220e7d756b (diff)
parente4afe8fc6c19ca62baa6e7c2c1bb64d7b09f3440 (diff)
downloadnixpkgs-17c4b83d05931bdc1364419b8264ea2c15b23223.tar
nixpkgs-17c4b83d05931bdc1364419b8264ea2c15b23223.tar.gz
nixpkgs-17c4b83d05931bdc1364419b8264ea2c15b23223.tar.bz2
nixpkgs-17c4b83d05931bdc1364419b8264ea2c15b23223.tar.lz
nixpkgs-17c4b83d05931bdc1364419b8264ea2c15b23223.tar.xz
nixpkgs-17c4b83d05931bdc1364419b8264ea2c15b23223.tar.zst
nixpkgs-17c4b83d05931bdc1364419b8264ea2c15b23223.zip
Merge #31320: docs and glibc: explicit comments on outputs
Diffstat (limited to 'doc')
-rw-r--r--doc/multiple-output.xml10
1 files changed, 8 insertions, 2 deletions
diff --git a/doc/multiple-output.xml b/doc/multiple-output.xml
index 2f23da8df01..277d3d81413 100644
--- a/doc/multiple-output.xml
+++ b/doc/multiple-output.xml
@@ -36,10 +36,16 @@
   <para>Here you find how to write a derivation that produces multiple outputs.</para>
   <para>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 &lt;<filename>nixpkgs/pkgs/build-support/setup-hooks/multiple-outputs.sh</filename>&gt;; it's relatively well-readable.  The whole machinery is triggered by defining the <varname>outputs</varname> attribute to contain the list of desired output names (strings).</para>
   <programlisting>outputs = [ "bin" "dev" "out" "doc" ];</programlisting>
-  <para>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 <literal>${pkgs.perl}/bin/perl</literal> to always work. Typically you also want to have the main <varname>out</varname> output, as it catches any files that didn't get elsewhere.</para>
-
+  <para>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 <varname>out</varname> output, as it catches any files that didn't get elsewhere.</para>
   <note><para>There is a special handling of the <varname>debug</varname> output, described at <xref linkend="stdenv-separateDebugInfo" />.</para></note>
 
+  <section xml:id="multiple-output-file-binaries-first-convention">
+    <title><quote>Binaries first</quote></title>
+    <para>A commonly adopted convention in <literal>nixpkgs</literal> 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 <literal>perl</literal> package contains a <literal>perl</literal> executable it can be referenced as <literal>${pkgs.perl}/bin/perl</literal> within a Nix derivation that needs to execute a Perl script.</para>
+    <para>The <literal>glibc</literal> package is a deliberate single exception to the <quote>binaries first</quote> convention. The <literal>glibc</literal> has <literal>libs</literal> as its first output allowing the libraries provided by <literal>glibc</literal> to be referenced directly (e.g. <literal>${stdenv.glibc}/lib/ld-linux-x86-64.so.2</literal>). The executables provided by <literal>glibc</literal> can be accessed via its <literal>bin</literal> attribute (e.g. <literal>${stdenv.glibc.bin}/bin/ldd</literal>).</para>
+    <para>The reason for why <literal>glibc</literal> deviates from the convention is because referencing a library provided by <literal>glibc</literal> 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 <literal>glibc</literal> libraries from Nix packages (please see the documentation on <link xlink:href="https://nixos.org/patchelf.html">patchelf</link> for more details).</para>
+  </section>
+
   <section xml:id="multiple-output-file-type-groups">
     <title>File type groups</title>
     <para>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 <varname>outputFoo</varname> variable specifying the output name where they should go.  If that variable isn't defined by the derivation writer, it is guessed &ndash; a default output name is defined, falling back to other possibilities if the output isn't defined.</para>