diff options
Diffstat (limited to 'doc/multiple-output.xml')
| -rw-r--r-- | doc/multiple-output.xml | 158 |
1 files changed, 30 insertions, 128 deletions
diff --git a/doc/multiple-output.xml b/doc/multiple-output.xml index d0247e081f995..83275bb2fbd1a 100644 --- a/doc/multiple-output.xml +++ b/doc/multiple-output.xml @@ -10,31 +10,16 @@ <title>Introduction</title> <para> - The Nix language allows a derivation to produce multiple outputs, which is - similar to what is utilized by other Linux distribution packaging systems. - The outputs reside in separate Nix store paths, so they can be mostly - handled independently of each other, including passing to build inputs, - garbage collection or binary substitution. The exception is that building - from source always produces all the outputs. + The Nix language allows a derivation to produce multiple outputs, which is similar to what is utilized by other Linux distribution packaging systems. The outputs reside in separate Nix store paths, so they can be mostly handled independently of each other, including passing to build inputs, garbage collection or binary substitution. The exception is that building from source always produces all the outputs. </para> <para> - The main motivation is to save disk space by reducing runtime closure sizes; - consequently also sizes of substituted binaries get reduced. Splitting can - be used to have more granular runtime dependencies, for example the typical - reduction is to split away development-only files, as those are typically - not needed during runtime. As a result, closure sizes of many packages can - get reduced to a half or even much less. + The main motivation is to save disk space by reducing runtime closure sizes; consequently also sizes of substituted binaries get reduced. Splitting can be used to have more granular runtime dependencies, for example the typical reduction is to split away development-only files, as those are typically not needed during runtime. As a result, closure sizes of many packages can get reduced to a half or even much less. </para> <note> <para> - The reduction effects could be instead achieved by building the parts in - completely separate derivations. That would often additionally reduce - build-time closures, but it tends to be much harder to write such - derivations, as build systems typically assume all parts are being built at - once. This compromise approach of single source package producing multiple - binary packages is also utilized often by rpm and deb. + The reduction effects could be instead achieved by building the parts in completely separate derivations. That would often additionally reduce build-time closures, but it tends to be much harder to write such derivations, as build systems typically assume all parts are being built at once. This compromise approach of single source package producing multiple binary packages is also utilized often by rpm and deb. </para> </note> </section> @@ -42,23 +27,18 @@ <title>Installing a split package</title> <para> - When installing a package via <varname>systemPackages</varname> or - <command>nix-env</command> you have several options: + When installing a package via <varname>systemPackages</varname> or <command>nix-env</command> you have several options: </para> <itemizedlist> <listitem> <para> - You can install particular outputs explicitly, as each is available in the - Nix language as an attribute of the package. The - <varname>outputs</varname> attribute contains a list of output names. + You can install particular outputs explicitly, as each is available in the Nix language as an attribute of the package. The <varname>outputs</varname> attribute contains a list of output names. </para> </listitem> <listitem> <para> - You can let it use the default outputs. These are handled by - <varname>meta.outputsToInstall</varname> attribute that contains a list of - output names. + You can let it use the default outputs. These are handled by <varname>meta.outputsToInstall</varname> attribute that contains a list of output names. </para> <para> TODO: more about tweaking the attribute, etc. @@ -66,19 +46,11 @@ </listitem> <listitem> <para> - NixOS provides configuration option - <varname>environment.extraOutputsToInstall</varname> that allows adding - extra outputs of <varname>environment.systemPackages</varname> atop the - default ones. It's mainly meant for documentation and debug symbols, and - it's also modified by specific options. + NixOS provides configuration option <varname>environment.extraOutputsToInstall</varname> that allows adding extra outputs of <varname>environment.systemPackages</varname> atop the default ones. It's mainly meant for documentation and debug symbols, and it's also modified by specific options. </para> <note> <para> - At this moment there is no similar configurability for packages installed - by <command>nix-env</command>. You can still use approach from - <xref linkend="sec-modify-via-packageOverrides" /> to override - <varname>meta.outputsToInstall</varname> attributes, but that's a rather - inconvenient way. + At this moment there is no similar configurability for packages installed by <command>nix-env</command>. You can still use approach from <xref linkend="sec-modify-via-packageOverrides" /> to override <varname>meta.outputsToInstall</varname> attributes, but that's a rather inconvenient way. </para> </note> </listitem> @@ -88,25 +60,15 @@ <title>Using a split package</title> <para> - In the Nix language the individual outputs can be reached explicitly as - attributes, e.g. <varname>coreutils.info</varname>, but the typical case is - just using packages as build inputs. + In the Nix language the individual outputs can be reached explicitly as attributes, e.g. <varname>coreutils.info</varname>, but the typical case is just using packages as build inputs. </para> <para> - When a multiple-output derivation gets into a build input of another - derivation, the <varname>dev</varname> output is added if it exists, - otherwise the first output is added. In addition to that, - <varname>propagatedBuildOutputs</varname> of that package which by default - contain <varname>$outputBin</varname> and <varname>$outputLib</varname> are - also added. (See <xref linkend="multiple-output-file-type-groups" />.) + When a multiple-output derivation gets into a build input of another derivation, the <varname>dev</varname> output is added if it exists, otherwise the first output is added. In addition to that, <varname>propagatedBuildOutputs</varname> of that package which by default contain <varname>$outputBin</varname> and <varname>$outputLib</varname> are also added. (See <xref linkend="multiple-output-file-type-groups" />.) </para> <para> - In some cases it may be desirable to combine different outputs under a - single store path. A function <literal>symlinkJoin</literal> can be used to - do this. (Note that it may negate some closure size benefits of using a - multiple-output package.) + In some cases it may be desirable to combine different outputs under a single store path. A function <literal>symlinkJoin</literal> can be used to do this. (Note that it may negate some closure size benefits of using a multiple-output package.) </para> </section> <section xml:id="sec-multiple-outputs-"> @@ -117,29 +79,18 @@ </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 - <<filename>nixpkgs/pkgs/build-support/setup-hooks/multiple-outputs.sh</filename>>; - 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). + 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 <<filename>nixpkgs/pkgs/build-support/setup-hooks/multiple-outputs.sh</filename>>; 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. Typically you also want to have the main - <varname>out</varname> 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 <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" />. + There is a special handling of the <varname>debug</varname> output, described at <xref linkend="stdenv-separateDebugInfo" />. </para> </note> @@ -147,36 +98,15 @@ <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. + 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>). + 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). + 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> @@ -184,13 +114,7 @@ <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 – a default output name is defined, - falling back to other possibilities if the output isn't defined. + 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 – a default output name is defined, falling back to other possibilities if the output isn't defined. </para> <variablelist> @@ -200,9 +124,7 @@ </term> <listitem> <para> - is for development-only files. These include C(++) headers, pkg-config, - cmake and aclocal files. They go to <varname>dev</varname> or - <varname>out</varname> by default. + is for development-only files. These include C(++) headers, pkg-config, cmake and aclocal files. They go to <varname>dev</varname> or <varname>out</varname> by default. </para> </listitem> </varlistentry> @@ -212,8 +134,7 @@ </term> <listitem> <para> - is meant for user-facing binaries, typically residing in bin/. They go - to <varname>bin</varname> or <varname>out</varname> by default. + is meant for user-facing binaries, typically residing in bin/. They go to <varname>bin</varname> or <varname>out</varname> by default. </para> </listitem> </varlistentry> @@ -223,9 +144,7 @@ </term> <listitem> <para> - is meant for libraries, typically residing in <filename>lib/</filename> - and <filename>libexec/</filename>. They go to <varname>lib</varname> or - <varname>out</varname> by default. + is meant for libraries, typically residing in <filename>lib/</filename> and <filename>libexec/</filename>. They go to <varname>lib</varname> or <varname>out</varname> by default. </para> </listitem> </varlistentry> @@ -235,9 +154,7 @@ </term> <listitem> <para> - is for user documentation, typically residing in - <filename>share/doc/</filename>. It goes to <varname>doc</varname> or - <varname>out</varname> by default. + is for user documentation, typically residing in <filename>share/doc/</filename>. It goes to <varname>doc</varname> or <varname>out</varname> by default. </para> </listitem> </varlistentry> @@ -247,10 +164,7 @@ </term> <listitem> <para> - is for <emphasis>developer</emphasis> documentation. Currently we count - gtk-doc and devhelp books in there. It goes to <varname>devdoc</varname> - or is removed (!) by default. This is because e.g. gtk-doc tends to be - rather large and completely unused by nixpkgs users. + is for <emphasis>developer</emphasis> documentation. Currently we count gtk-doc and devhelp books in there. It goes to <varname>devdoc</varname> or is removed (!) by default. This is because e.g. gtk-doc tends to be rather large and completely unused by nixpkgs users. </para> </listitem> </varlistentry> @@ -260,8 +174,7 @@ </term> <listitem> <para> - is for man pages (except for section 3). They go to - <varname>man</varname> or <varname>$outputBin</varname> by default. + is for man pages (except for section 3). They go to <varname>man</varname> or <varname>$outputBin</varname> by default. </para> </listitem> </varlistentry> @@ -271,8 +184,7 @@ </term> <listitem> <para> - is for section 3 man pages. They go to <varname>devman</varname> or - <varname>$outputMan</varname> by default. + is for section 3 man pages. They go to <varname>devman</varname> or <varname>$outputMan</varname> by default. </para> </listitem> </varlistentry> @@ -282,8 +194,7 @@ </term> <listitem> <para> - is for info pages. They go to <varname>info</varname> or - <varname>$outputBin</varname> by default. + is for info pages. They go to <varname>info</varname> or <varname>$outputBin</varname> by default. </para> </listitem> </varlistentry> @@ -296,31 +207,22 @@ <itemizedlist> <listitem> <para> - Some configure scripts don't like some of the parameters passed by - default by the framework, e.g. <literal>--docdir=/foo/bar</literal>. You - can disable this by setting <literal>setOutputFlags = false;</literal>. + Some configure scripts don't like some of the parameters passed by default by the framework, e.g. <literal>--docdir=/foo/bar</literal>. You can disable this by setting <literal>setOutputFlags = false;</literal>. </para> </listitem> <listitem> <para> - The outputs of a single derivation can retain references to each other, - but note that circular references are not allowed. (And each - strongly-connected component would act as a single output anyway.) + The outputs of a single derivation can retain references to each other, but note that circular references are not allowed. (And each strongly-connected component would act as a single output anyway.) </para> </listitem> <listitem> <para> - Most of split packages contain their core functionality in libraries. - These libraries tend to refer to various kind of data that typically gets - into <varname>out</varname>, e.g. locale strings, so there is often no - advantage in separating the libraries into <varname>lib</varname>, as - keeping them in <varname>out</varname> is easier. + Most of split packages contain their core functionality in libraries. These libraries tend to refer to various kind of data that typically gets into <varname>out</varname>, e.g. locale strings, so there is often no advantage in separating the libraries into <varname>lib</varname>, as keeping them in <varname>out</varname> is easier. </para> </listitem> <listitem> <para> - Some packages have hidden assumptions on install paths, which complicates - splitting. + Some packages have hidden assumptions on install paths, which complicates splitting. </para> </listitem> </itemizedlist> |