2005-02-01 21:53:14 +01:00
|
|
|
### Option `gc-keep-outputs'
|
|
|
|
#
|
|
|
|
# If `true', the garbage collector will keep the outputs of
|
|
|
|
# non-garbage derivations. If `false' (default), outputs will be
|
|
|
|
# deleted unless they are GC roots themselves (or reachable from other
|
|
|
|
# roots).
|
|
|
|
#
|
|
|
|
# In general, outputs must be registered as roots separately.
|
|
|
|
# However, even if the output of a derivation is registered as a root,
|
2005-02-14 14:07:09 +01:00
|
|
|
# the collector will still delete store paths that are used only at
|
2005-02-01 21:53:14 +01:00
|
|
|
# build time (e.g., the C compiler, or source tarballs downloaded from
|
|
|
|
# the network). To prevent it from doing so, set this option to
|
|
|
|
# `true'.
|
2006-02-16 14:58:10 +01:00
|
|
|
#gc-keep-outputs = false
|
2005-02-01 21:53:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
### Option `gc-keep-derivations'
|
|
|
|
#
|
|
|
|
# If `true' (default), the garbage collector will keep the derivations
|
|
|
|
# from which non-garbage store paths were built. If `false', they
|
|
|
|
# will be deleted unless explicitly registered as a root (or reachable
|
|
|
|
# from other roots).
|
|
|
|
#
|
|
|
|
# Keeping derivation around is useful for querying and traceability
|
|
|
|
# (e.g., it allows you to ask with what dependencies or options a
|
|
|
|
# store path was built), so by default this option is on. Turn it off
|
|
|
|
# to safe a bit of disk space (or a lot if `gc-keep-outputs' is also
|
|
|
|
# turned on).
|
2006-02-16 14:58:10 +01:00
|
|
|
#gc-keep-derivations = true
|
|
|
|
|
|
|
|
|
|
|
|
### Option `gc-reserved-space'
|
|
|
|
#
|
|
|
|
# This option specifies how much space should be reserved in normal
|
|
|
|
# use so that the garbage collector can run succesfully. Since the
|
|
|
|
# garbage collector must perform Berkeley DB transactions, it needs
|
|
|
|
# some disk space for itself. However, when the disk is full, this
|
|
|
|
# space is not available, so the collector would not be able to run
|
|
|
|
# precisely when it is most needed.
|
|
|
|
#
|
|
|
|
# For this reason, when Nix is run, it allocates a file
|
|
|
|
# /nix/var/nix/db/reserved of the size specified by this option. When
|
|
|
|
# the garbage collector is run, this file is deleted before the
|
|
|
|
# Berkeley DB environment is opened. This should give it enough room
|
|
|
|
# to proceed.
|
|
|
|
#
|
|
|
|
# The default is "1048576" (1 MiB).
|
|
|
|
#gc-reserved-space = 1048576
|
2005-02-01 21:53:14 +01:00
|
|
|
|
2005-02-14 14:07:09 +01:00
|
|
|
|
|
|
|
### Option `env-keep-derivations'
|
|
|
|
#
|
|
|
|
# If `false' (default), derivations are not stored in Nix user
|
|
|
|
# environments. That is, the derivation any build-time-only
|
|
|
|
# dependencies may be garbage-collected.
|
|
|
|
#
|
|
|
|
# If `true', when you add a Nix derivation to a user environment, the
|
|
|
|
# path of the derivation is stored in the user environment. Thus, the
|
|
|
|
# derivation will not be garbage-collected until the user environment
|
|
|
|
# generation is deleted (`nix-env --delete-generations'). To prevent
|
|
|
|
# build-time-only dependencies from being collected, you should also
|
|
|
|
# turn on `gc-keep-outputs'.
|
|
|
|
#
|
|
|
|
# The difference between this option and `gc-keep-derivations' is that
|
|
|
|
# this one is `sticky': it applies to any user environment created
|
|
|
|
# while this option was enabled, while `gc-keep-derivations' only
|
|
|
|
# applies at the moment the garbage collector is run.
|
2006-02-16 14:58:10 +01:00
|
|
|
#env-keep-derivations = false
|
2005-09-21 14:19:39 +02:00
|
|
|
|
|
|
|
|
2006-08-10 22:19:13 +02:00
|
|
|
### Option `build-max-jobs'
|
|
|
|
#
|
|
|
|
# This option defines the maximum number of jobs that Nix will try to
|
|
|
|
# build in parallel. The default is 1. You should generally set it
|
|
|
|
# to the number of CPUs in your system (e.g., 2 on a Athlon 64 X2).
|
|
|
|
# It can be overriden using the `--max-jobs' / `-j' command line
|
|
|
|
# switch.
|
|
|
|
#build-max-jobs = 1
|
|
|
|
|
|
|
|
|
2005-09-21 14:19:39 +02:00
|
|
|
### Option `build-allow-root'
|
|
|
|
#
|
|
|
|
# This option controls Nix's behaviour when it is invoked under the
|
|
|
|
# `root' user (or setuid-root). If `true' (default), builds are
|
|
|
|
# performed under the `root' user. If `false', builds are performed
|
|
|
|
# under one of the users listed in the `build-users' option (see
|
|
|
|
# below).
|
2006-02-16 14:58:10 +01:00
|
|
|
#build-allow-root = true
|
2005-09-21 14:19:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
### Option `build-users'
|
|
|
|
#
|
|
|
|
# This option is only applicable if `build-allow-root' is `false' and
|
|
|
|
# Nix is invoked under the `root' user (or setuid-root). It contains
|
|
|
|
# a list of user names under which Nix can execute builds. Builds
|
|
|
|
# cannot be performed by root since that would allow users to take
|
|
|
|
# over the system by supplying specially crafted builders; and they
|
|
|
|
# cannot be performed by the calling user since that would allow
|
|
|
|
# him/her to influence the build result.
|
|
|
|
#
|
|
|
|
# Thus this list should contain a number of `special' user accounts
|
|
|
|
# created specifically for Nix, e.g., `nix-builder-1',
|
|
|
|
# `nix-builder-2', and so on. The more users the better, since at
|
|
|
|
# most a number of builds equal to the number of build users can be
|
|
|
|
# started.
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
# build-users = nix-builder-1 nix-builder-2 nix-builder-3
|
2006-02-16 14:58:10 +01:00
|
|
|
#build-users =
|
2006-07-06 17:30:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
### Option `system'
|
|
|
|
#
|
|
|
|
# This option specifies the canonical Nix system name of the current
|
|
|
|
# installation, such as `i686-linux' or `powerpc-darwin'. Nix can
|
|
|
|
# only build derivations whose `system' attribute equals the value
|
|
|
|
# specified here. In general, it never makes sense to modify this
|
|
|
|
# value from its default, since you can use it to `lie' about the
|
|
|
|
# platform you are building on (e.g., perform a Mac OS build on a
|
|
|
|
# Linux machine; the result would obviously be wrong). It only makes
|
|
|
|
# sense if the Nix binaries can run on multiple platforms, e.g.,
|
|
|
|
# `universal binaries' that run on `powerpc-darwin' and `i686-darwin'.
|
|
|
|
#
|
|
|
|
# It defaults to the canonical Nix system name detected by `configure'
|
|
|
|
# at build time.
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
# system = i686-darwin
|
|
|
|
#system =
|