These are often programs and libraries used by the new derivation at *run*-time, but that isn’t always the case. For example, the machine code in a statically-linked library is only used at run-time, but the derivation containing the library is only needed at build-time. Even in the dynamic case, the library may also be needed at build-time to appease the linker.

##### `depsTargetTarget` {#var-stdenv-depsTargetTarget}

A list of dependencies whose host platform matches the new derivation’s target platform. These are packages that run on the target platform, e.g. the standard library or run-time deps of standard library that a compiler insists on knowing about. It’s poor form in almost all cases for a package to depend on another from a future stage \[future stage corresponding to positive offset\]. Do not use this attribute unless you are packaging a compiler and are sure it is needed.

##### `depsBuildBuildPropagated` {#var-stdenv-depsBuildBuildPropagated}

The propagated equivalent of `depsBuildBuild`. This perhaps never ought to be used, but it is included for consistency \[see below for the others\].

##### `propagatedNativeBuildInputs` {#var-stdenv-propagatedNativeBuildInputs}

The propagated equivalent of `nativeBuildInputs`. This would be called `depsBuildHostPropagated` but for historical continuity. For example, if package `Y` has `propagatedNativeBuildInputs = [X]`, and package `Z` has `buildInputs = [Y]`, then package `Z` will be built as if it included package `X` in its `nativeBuildInputs`. Note that if instead, package `Z` has `nativeBuildInputs = [Y]`, then `X` will not be included at all.

##### `depsBuildTargetPropagated` {#var-stdenv-depsBuildTargetPropagated}

The propagated equivalent of `depsBuildTarget`. This is prefixed for the same reason of alerting potential users.

##### `depsHostHostPropagated` {#var-stdenv-depsHostHostPropagated}

The propagated equivalent of `depsHostHost`.

##### `propagatedBuildInputs` {#var-stdenv-propagatedBuildInputs}

The propagated equivalent of `buildInputs`. This would be called `depsHostTargetPropagated` but for historical continuity.

##### `depsTargetTargetPropagated` {#var-stdenv-depsTargetTargetPropagated}

The propagated equivalent of `depsTargetTarget`. This is prefixed for the same reason of alerting potential users.

## Attributes {#ssec-stdenv-attributes}

### Variables affecting `stdenv` initialisation {#variables-affecting-stdenv-initialisation}

#### `NIX_DEBUG` {#var-stdenv-NIX_DEBUG}

A number between 0 and 7 indicating how much information to log. If set to 1 or higher, `stdenv` will print moderate debugging information during the build. In particular, the `gcc` and `ld` wrapper scripts will print out the complete command line passed to the wrapped tools. If set to 6 or higher, the `stdenv` setup script will be run with `set -x` tracing. If set to 7 or higher, the `gcc` and `ld` wrapper scripts will also be run with `set -x` tracing.

### Attributes affecting build properties {#attributes-affecting-build-properties}

#### `enableParallelBuilding` {#var-stdenv-enableParallelBuilding}

If set to `true`, `stdenv` will pass specific flags to `make` and other build tools to enable parallel building with up to `build-cores` workers.

Unless set to `false`, some build systems with good support for parallel building including `cmake`, `meson`, and `qmake` will set it to `true`.

### Fixed-point arguments of `mkDerivation` {#mkderivation-recursive-attributes}

If you pass a function to `mkDerivation`, it will receive as its argument the final arguments, including the overrides when reinvoked via `overrideAttrs`. For example:

```nix
mkDerivation (finalAttrs: {
  pname = "hello";
  withFeature = true;
  configureFlags = lib.optionals finalAttrs.withFeature [ "--with-feature" ];
})
```

Note that this does not use the `rec` keyword to reuse `withFeature` in `configureFlags`.
The `rec` keyword works at the syntax level and is unaware of overriding.

Instead, the definition references `finalAttrs`, allowing users to change `withFeature`