noogle/scripts/data/derivation-doc.txt

1 line
7.0 KiB
Plaintext
Raw Normal View History

2023-02-05 13:40:33 +03:00
# Derivations\n\nThe most important built-in function is `derivation`, which is used to\ndescribe a single derivation (a build task). It takes as input a set,\nthe attributes of which specify the inputs of the build.\n\n - There must be an attribute named [`system`]{#attr-system} whose value must be a\n string specifying a Nix system type, such as `\"i686-linux\"` or\n `\"x86_64-darwin\"`. (To figure out your system type, run `nix -vv\n --version`.) The build can only be performed on a machine and\n operating system matching the system type. (Nix can automatically\n [forward builds for other\n platforms](../advanced-topics/distributed-builds.md) by forwarding\n them to other machines.)\n\n - There must be an attribute named `name` whose value must be a\n string. This is used as a symbolic name for the package by\n `nix-env`, and it is appended to the output paths of the derivation.\n\n - There must be an attribute named `builder` that identifies the\n program that is executed to perform the build. It can be either a\n derivation or a source (a local file reference, e.g.,\n `./builder.sh`).\n\n - Every attribute is passed as an environment variable to the builder.\n Attribute values are translated to environment variables as follows:\n \n - Strings and numbers are just passed verbatim.\n \n - A *path* (e.g., `../foo/sources.tar`) causes the referenced file\n to be copied to the store; its location in the store is put in\n the environment variable. The idea is that all sources should\n reside in the Nix store, since all inputs to a derivation should\n reside in the Nix store.\n \n - A *derivation* causes that derivation to be built prior to the\n present derivation; its default output path is put in the\n environment variable.\n \n - Lists of the previous types are also allowed. They are simply\n concatenated, separated by spaces.\n \n - `true` is passed as the string `1`, `false` and `null` are\n passed as an empty string.\n\n - The optional attribute `args` specifies command-line arguments to be\n passed to the builder. It should be a list.\n\n - The optional attribute `outputs` specifies a list of symbolic\n outputs of the derivation. By default, a derivation produces a\n single output path, denoted as `out`. However, derivations can\n produce multiple output paths. This is useful because it allows\n outputs to be downloaded or garbage-collected separately. For\n instance, imagine a library package that provides a dynamic library,\n header files, and documentation. A program that links against the\n library doesnt need the header files and documentation at runtime,\n and it doesnt need the documentation at build time. Thus, the\n library package could specify:\n \n ```nix\n outputs = [ \"lib\" \"headers\" \"doc\" ];\n ```\n \n This will cause Nix to pass environment variables `lib`, `headers`\n and `doc` to the builder containing the intended store paths of each\n output. The builder would typically do something like\n \n ```bash\n ./configure \\n --libdir=$lib/lib \\n --includedir=$headers/include \\n --docdir=$doc/share/doc\n ```\n \n for an Autoconf-style package. You can refer to each output of a\n derivation by selecting it as an attribute, e.g.\n \n ```nix\n buildInputs = [ pkg.lib pkg.headers ];\n ```\n \n The first element of `outputs` determines the *default output*.\n Thus, you could also write\n \n ```nix\n buildInputs = [ pkg pkg.headers ];\n ```\n \n since `pkg` is equivalent to `pkg.lib`.\n\nThe function `mkDerivation` in the Nixpkgs standard environment is a\nwrapper around `derivation` that adds a default value for `system` and\nalways uses Bash as the builder, to which the supplied builder is passed\nas a command-line argument. See the Nixpkgs manual for details.\n\nThe builder is executed as follows:\n\n - A temporary directory i