diff options
Diffstat (limited to 'doc/stdenv/multiple-output.chapter.md')
| -rw-r--r-- | doc/stdenv/multiple-output.chapter.md | 28 |
1 files changed, 14 insertions, 14 deletions
diff --git a/doc/stdenv/multiple-output.chapter.md b/doc/stdenv/multiple-output.chapter.md index 90bc25bef73..d04f83302ac 100644 --- a/doc/stdenv/multiple-output.chapter.md +++ b/doc/stdenv/multiple-output.chapter.md @@ -6,7 +6,7 @@ The Nix language allows a derivation to produce multiple outputs, which is simil 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. -::: note +::: {.note} 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. ::: @@ -28,7 +28,7 @@ NixOS provides two ways to select the outputs to install for packages listed in `nix-env` lacks an easy way to select the outputs to install. When installing a package, `nix-env` always installs the outputs listed in `meta.outputsToInstall`, even when the user explicitly selects an output. -::: warning +::: {.warning} `nix-env` silenty disregards the outputs selected by the user, and instead installs the outputs from `meta.outputsToInstall`. For example, ```ShellSession @@ -38,7 +38,7 @@ $ nix-env -iA nixpkgs.coreutils.info installs the `"out"` output (`coreutils.meta.outputsToInstall` is `[ "out" ]`) instead of the requested `"info"`. ::: -The only recourse to select an output with `nix-env` is to override the package’s `meta.outputsToInstall`, using the functions described in <xref linkend="chap-overrides" />. For example, the following overlay adds the `"info"` output for the `coreutils` package: +The only recourse to select an output with `nix-env` is to override the package’s `meta.outputsToInstall`, using the functions described in [](#chap-overrides). For example, the following overlay adds the `"info"` output for the `coreutils` package: ```nix self: super: @@ -53,7 +53,7 @@ self: super: In the Nix language the individual outputs can be reached explicitly as attributes, e.g. `coreutils.info`, but the typical case is just using packages as build inputs. -When a multiple-output derivation gets into a build input of another derivation, the `dev` output is added if it exists, otherwise the first output is added. In addition to that, `propagatedBuildOutputs` of that package which by default contain `$outputBin` and `$outputLib` 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 `dev` output is added if it exists, otherwise the first output is added. In addition to that, `propagatedBuildOutputs` of that package which by default contain `$outputBin` and `$outputLib` are also added. (See [](#multiple-output-file-type-groups).) In some cases it may be desirable to combine different outputs under a single store path. A function `symlinkJoin` can be used to do this. (Note that it may negate some closure size benefits of using a multiple-output package.) @@ -69,8 +69,8 @@ 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. Typically you also want to have the main `out` output, as it catches any files that didn’t get elsewhere. -::: note -There is a special handling of the `debug` output, described at <xref linkend="stdenv-separateDebugInfo" />. +::: {.note} +There is a special handling of the `debug` output, described at [](#stdenv-separateDebugInfo). ::: ### “Binaries first” {#multiple-output-file-binaries-first-convention} @@ -85,35 +85,35 @@ The reason for why `glibc` deviates from the convention is because referencing a 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. -#### ` $outputDev` +#### `$outputDev` {#outputdev} is for development-only files. These include C(++) headers (`include/`), pkg-config (`lib/pkgconfig/`), cmake (`lib/cmake/`) and aclocal files (`share/aclocal/`). They go to `dev` or `out` by default. -#### ` $outputBin` +#### `$outputBin` {#outputbin} is meant for user-facing binaries, typically residing in `bin/`. They go to `bin` or `out` by default. -#### ` $outputLib` +#### `$outputLib` {#outputlib} is meant for libraries, typically residing in `lib/` and `libexec/`. They go to `lib` or `out` by default. -#### ` $outputDoc` +#### `$outputDoc` {#outputdoc} is for user documentation, typically residing in `share/doc/`. It goes to `doc` or `out` by default. -#### ` $outputDevdoc` +#### `$outputDevdoc` {#outputdevdoc} is for _developer_ documentation. Currently we count gtk-doc and devhelp books, typically residing in `share/gtk-doc/` and `share/devhelp/`, in there. It goes to `devdoc` or is removed (!) by default. This is because e.g. gtk-doc tends to be rather large and completely unused by nixpkgs users. -#### ` $outputMan` +#### `$outputMan` {#outputman} is for man pages (except for section 3), typically residing in `share/man/man[0-9]/`. They go to `man` or `$outputBin` by default. -#### ` $outputDevman` +#### `$outputDevman` {#outputdevman} is for section 3 man pages, typically residing in `share/man/man[0-9]/`. They go to `devman` or `$outputMan` by default. -#### ` $outputInfo` +#### `$outputInfo` {#outputinfo} is for info pages, typically residing in `share/info/`. They go to `info` or `$outputBin` by default. |