forked from lix-project/lix
Merge remote-tracking branch 'origin/master' into cross-jobs
This commit is contained in:
Matthew Bauer
commit
c6d878609d
|
|
@ -1,6 +1,7 @@
|
|||
((c++-mode . (
|
||||
(c-file-style . "k&r")
|
||||
(c-basic-offset . 4)
|
||||
(c-block-comment-prefix . " ")
|
||||
(indent-tabs-mode . nil)
|
||||
(tab-width . 4)
|
||||
(show-trailing-whitespace . t)
|
||||
|
|
@ -13,4 +14,5 @@
|
|||
(eval . (c-set-offset 'arglist-cont-nonempty '+))
|
||||
(eval . (c-set-offset 'substatement-open 0))
|
||||
(eval . (c-set-offset 'access-label '-))
|
||||
(eval . (c-set-offset 'inlambda 0))
|
||||
)))
|
||||
|
|
|
|||
27
.github/ISSUE_TEMPLATE.md
vendored
27
.github/ISSUE_TEMPLATE.md
vendored
|
|
@ -1,27 +0,0 @@
|
|||
<!--
|
||||
|
||||
# Filing a Nix issue
|
||||
|
||||
*WAIT* Are you sure you're filing your issue in the right repository?
|
||||
|
||||
We appreciate you taking the time to tell us about issues you encounter, but routing the issue to the right place will get you help sooner and save everyone time.
|
||||
|
||||
This is the Nix repository, and issues here should be about Nix the build and package management *_tool_*.
|
||||
|
||||
If you have a problem with a specific package on NixOS or when using Nix, you probably want to file an issue with _nixpkgs_, whose issue tracker is over at https://github.com/NixOS/nixpkgs/issues.
|
||||
|
||||
Examples of _Nix_ issues:
|
||||
|
||||
- Nix segfaults when I run `nix-build -A blahblah`
|
||||
- The Nix language needs a new builtin: `builtins.foobar`
|
||||
- Regression in the behavior of `nix-env` in Nix 2.0
|
||||
|
||||
Examples of _nixpkgs_ issues:
|
||||
|
||||
- glibc is b0rked on aarch64
|
||||
- chromium in NixOS doesn't support U2F but google-chrome does!
|
||||
- The OpenJDK package on macOS is missing a key component
|
||||
|
||||
Chances are if you're a newcomer to the Nix world, you'll probably want the [nixpkgs tracker](https://github.com/NixOS/nixpkgs/issues). It also gets a lot more eyeball traffic so you'll probably get a response a lot more quickly.
|
||||
|
||||
-->
|
||||
32
.github/ISSUE_TEMPLATE/bug_report.md
vendored
Normal file
32
.github/ISSUE_TEMPLATE/bug_report.md
vendored
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
---
|
||||
name: Bug report
|
||||
about: Create a report to help us improve
|
||||
title: ''
|
||||
labels: bug
|
||||
assignees: ''
|
||||
|
||||
---
|
||||
|
||||
**Describe the bug**
|
||||
|
||||
A clear and concise description of what the bug is.
|
||||
|
||||
If you have a problem with a specific package or NixOS,
|
||||
you probably want to file an issue at https://github.com/NixOS/nixpkgs/issues.
|
||||
|
||||
**Steps To Reproduce**
|
||||
|
||||
1. Go to '...'
|
||||
2. Click on '....'
|
||||
3. Scroll down to '....'
|
||||
4. See error
|
||||
|
||||
**Expected behavior**
|
||||
|
||||
A clear and concise description of what you expected to happen.
|
||||
|
||||
**`nix-env --version` output**
|
||||
|
||||
**Additional context**
|
||||
|
||||
Add any other context about the problem here.
|
||||
20
.github/ISSUE_TEMPLATE/feature_request.md
vendored
Normal file
20
.github/ISSUE_TEMPLATE/feature_request.md
vendored
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
name: Feature request
|
||||
about: Suggest an idea for this project
|
||||
title: ''
|
||||
labels: improvement
|
||||
assignees: ''
|
||||
|
||||
---
|
||||
|
||||
**Is your feature request related to a problem? Please describe.**
|
||||
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
|
||||
|
||||
**Describe the solution you'd like**
|
||||
A clear and concise description of what you want to happen.
|
||||
|
||||
**Describe alternatives you've considered**
|
||||
A clear and concise description of any alternative solutions or features you've considered.
|
||||
|
||||
**Additional context**
|
||||
Add any other context or screenshots about the feature request here.
|
||||
6
.github/dependabot.yml
vendored
Normal file
6
.github/dependabot.yml
vendored
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "github-actions"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
17
.github/workflows/test.yml
vendored
Normal file
17
.github/workflows/test.yml
vendored
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
name: "Test"
|
||||
on:
|
||||
pull_request:
|
||||
push:
|
||||
jobs:
|
||||
tests:
|
||||
strategy:
|
||||
matrix:
|
||||
os: [ubuntu-latest, macos-latest]
|
||||
runs-on: ${{ matrix.os }}
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
with:
|
||||
fetch-depth: 0
|
||||
- uses: cachix/install-nix-action@v12
|
||||
#- run: nix flake check
|
||||
- run: nix-build -A checks.$(if [[ `uname` = Linux ]]; then echo x86_64-linux; else echo x86_64-darwin; fi)
|
||||
45
.gitignore
vendored
45
.gitignore
vendored
|
|
@ -4,35 +4,27 @@ perl/Makefile.config
|
|||
# /
|
||||
/aclocal.m4
|
||||
/autom4te.cache
|
||||
/precompiled-headers.h.gch
|
||||
/config.*
|
||||
/configure
|
||||
/nix.spec
|
||||
/stamp-h1
|
||||
/svn-revision
|
||||
/libtool
|
||||
|
||||
/corepkgs/config.nix
|
||||
|
||||
# /corepkgs/channels/
|
||||
/corepkgs/channels/unpack.sh
|
||||
|
||||
# /corepkgs/nar/
|
||||
/corepkgs/nar/nar.sh
|
||||
/corepkgs/nar/unnar.sh
|
||||
|
||||
# /doc/manual/
|
||||
/doc/manual/manual.html
|
||||
/doc/manual/manual.xmli
|
||||
/doc/manual/manual.pdf
|
||||
/doc/manual/manual.is-valid
|
||||
/doc/manual/*.1
|
||||
/doc/manual/*.5
|
||||
/doc/manual/*.8
|
||||
/doc/manual/version.txt
|
||||
/doc/manual/nix.json
|
||||
/doc/manual/conf-file.json
|
||||
/doc/manual/builtins.json
|
||||
/doc/manual/src/SUMMARY.md
|
||||
/doc/manual/src/command-ref/new-cli
|
||||
/doc/manual/src/command-ref/conf-file.md
|
||||
/doc/manual/src/expressions/builtins.md
|
||||
|
||||
# /scripts/
|
||||
/scripts/nix-profile.sh
|
||||
/scripts/nix-copy-closure
|
||||
/scripts/nix-reduce-build
|
||||
/scripts/nix-http-export.cgi
|
||||
/scripts/nix-profile-daemon.sh
|
||||
|
|
@ -46,7 +38,10 @@ perl/Makefile.config
|
|||
/src/libexpr/nix.tbl
|
||||
|
||||
# /src/libstore/
|
||||
/src/libstore/*.gen.hh
|
||||
*.gen.*
|
||||
|
||||
# /src/libutil/
|
||||
/src/libutil/tests/libutil-tests
|
||||
|
||||
/src/nix/nix
|
||||
|
||||
|
|
@ -74,6 +69,8 @@ perl/Makefile.config
|
|||
|
||||
/src/nix-copy-closure/nix-copy-closure
|
||||
|
||||
/src/error-demo/error-demo
|
||||
|
||||
/src/build-remote/build-remote
|
||||
|
||||
# /tests/
|
||||
|
|
@ -81,6 +78,10 @@ perl/Makefile.config
|
|||
/tests/common.sh
|
||||
/tests/dummy
|
||||
/tests/result*
|
||||
/tests/restricted-innocent
|
||||
/tests/shell
|
||||
/tests/shell.drv
|
||||
/tests/config.nix
|
||||
|
||||
# /tests/lang/
|
||||
/tests/lang/*.out
|
||||
|
|
@ -96,7 +97,7 @@ perl/Makefile.config
|
|||
|
||||
/src/resolve-system-dependencies/resolve-system-dependencies
|
||||
|
||||
inst/
|
||||
outputs/
|
||||
|
||||
*.a
|
||||
*.o
|
||||
|
|
@ -114,3 +115,11 @@ GPATH
|
|||
GRTAGS
|
||||
GSYMS
|
||||
GTAGS
|
||||
|
||||
# ccls
|
||||
/.ccls-cache
|
||||
|
||||
# auto-generated compilation database
|
||||
compile_commands.json
|
||||
|
||||
nix-rust/target
|
||||
|
|
|
|||
|
|
@ -1,2 +0,0 @@
|
|||
os: osx
|
||||
script: ./tests/install-darwin.sh
|
||||
13
Makefile
13
Makefile
|
|
@ -1,13 +1,17 @@
|
|||
makefiles = \
|
||||
mk/precompiled-headers.mk \
|
||||
local.mk \
|
||||
src/libutil/local.mk \
|
||||
src/libutil/tests/local.mk \
|
||||
src/libstore/local.mk \
|
||||
src/libfetchers/local.mk \
|
||||
src/libmain/local.mk \
|
||||
src/libexpr/local.mk \
|
||||
src/libcmd/local.mk \
|
||||
src/nix/local.mk \
|
||||
src/resolve-system-dependencies/local.mk \
|
||||
scripts/local.mk \
|
||||
corepkgs/local.mk \
|
||||
misc/bash/local.mk \
|
||||
misc/systemd/local.mk \
|
||||
misc/launchd/local.mk \
|
||||
misc/upstart/local.mk \
|
||||
|
|
@ -15,15 +19,16 @@ makefiles = \
|
|||
tests/local.mk \
|
||||
tests/plugins/local.mk
|
||||
|
||||
GLOBAL_CXXFLAGS += -g -Wall -include config.h
|
||||
|
||||
-include Makefile.config
|
||||
|
||||
OPTIMIZE = 1
|
||||
|
||||
ifeq ($(OPTIMIZE), 1)
|
||||
GLOBAL_CFLAGS += -O3
|
||||
GLOBAL_CXXFLAGS += -O3
|
||||
else
|
||||
GLOBAL_CXXFLAGS += -O0 -U_FORTIFY_SOURCE
|
||||
endif
|
||||
|
||||
include mk/lib.mk
|
||||
|
||||
GLOBAL_CXXFLAGS += -g -Wall -include config.h -std=c++17
|
||||
|
|
|
|||
|
|
@ -1,38 +1,42 @@
|
|||
AR = @AR@
|
||||
BDW_GC_LIBS = @BDW_GC_LIBS@
|
||||
BOOST_LDFLAGS = @BOOST_LDFLAGS@
|
||||
BUILD_SHARED_LIBS = @BUILD_SHARED_LIBS@
|
||||
CC = @CC@
|
||||
CFLAGS = @CFLAGS@
|
||||
CXX = @CXX@
|
||||
CXXFLAGS = @CXXFLAGS@
|
||||
EDITLINE_LIBS = @EDITLINE_LIBS@
|
||||
ENABLE_S3 = @ENABLE_S3@
|
||||
HAVE_SODIUM = @HAVE_SODIUM@
|
||||
HAVE_READLINE = @HAVE_READLINE@
|
||||
GTEST_LIBS = @GTEST_LIBS@
|
||||
HAVE_SECCOMP = @HAVE_SECCOMP@
|
||||
LDFLAGS = @LDFLAGS@
|
||||
LIBARCHIVE_LIBS = @LIBARCHIVE_LIBS@
|
||||
LIBBROTLI_LIBS = @LIBBROTLI_LIBS@
|
||||
LIBCURL_LIBS = @LIBCURL_LIBS@
|
||||
LIBLZMA_LIBS = @LIBLZMA_LIBS@
|
||||
OPENSSL_LIBS = @OPENSSL_LIBS@
|
||||
PACKAGE_NAME = @PACKAGE_NAME@
|
||||
PACKAGE_VERSION = @PACKAGE_VERSION@
|
||||
SHELL = @bash@
|
||||
SODIUM_LIBS = @SODIUM_LIBS@
|
||||
LIBLZMA_LIBS = @LIBLZMA_LIBS@
|
||||
SQLITE3_LIBS = @SQLITE3_LIBS@
|
||||
LIBBROTLI_LIBS = @LIBBROTLI_LIBS@
|
||||
EDITLINE_LIBS = @EDITLINE_LIBS@
|
||||
bash = @bash@
|
||||
bindir = @bindir@
|
||||
lsof = @lsof@
|
||||
datadir = @datadir@
|
||||
datarootdir = @datarootdir@
|
||||
doc_generate = @doc_generate@
|
||||
docdir = @docdir@
|
||||
exec_prefix = @exec_prefix@
|
||||
includedir = @includedir@
|
||||
libdir = @libdir@
|
||||
libexecdir = @libexecdir@
|
||||
localstatedir = @localstatedir@
|
||||
lsof = @lsof@
|
||||
mandir = @mandir@
|
||||
pkglibdir = $(libdir)/$(PACKAGE_NAME)
|
||||
prefix = @prefix@
|
||||
sandbox_shell = @sandbox_shell@
|
||||
storedir = @storedir@
|
||||
sysconfdir = @sysconfdir@
|
||||
doc_generate = @doc_generate@
|
||||
xmllint = @xmllint@
|
||||
xsltproc = @xsltproc@
|
||||
system = @system@
|
||||
|
|
|
|||
43
README.md
43
README.md
|
|
@ -1,22 +1,35 @@
|
|||
Nix, the purely functional package manager
|
||||
------------------------------------------
|
||||
# Nix
|
||||
|
||||
Nix is a new take on package management that is fairly unique. Because of its
|
||||
purity aspects, a lot of issues found in traditional package managers don't
|
||||
appear with Nix.
|
||||
[](https://opencollective.com/nixos)
|
||||
[](https://github.com/NixOS/nix/actions)
|
||||
|
||||
To find out more about the tool, usage and installation instructions, please
|
||||
read the manual, which is available on the Nix website at
|
||||
<http://nixos.org/nix/manual>.
|
||||
Nix is a powerful package manager for Linux and other Unix systems that makes package
|
||||
management reliable and reproducible. Please refer to the [Nix manual](https://nixos.org/nix/manual)
|
||||
for more details.
|
||||
|
||||
## Contributing
|
||||
## Installation
|
||||
|
||||
Take a look at the [Hacking Section](http://nixos.org/nix/manual/#chap-hacking)
|
||||
of the manual. It helps you to get started with building Nix from source.
|
||||
On Linux and macOS the easiest way to install Nix is to run the following shell command
|
||||
(as a user other than root):
|
||||
|
||||
```console
|
||||
$ curl -L https://nixos.org/nix/install | sh
|
||||
```
|
||||
|
||||
Information on additional installation methods is available on the [Nix download page](https://nixos.org/download.html).
|
||||
|
||||
## Building And Developing
|
||||
|
||||
See our [Hacking guide](https://hydra.nixos.org/job/nix/master/build.x86_64-linux/latest/download-by-type/doc/manual/contributing/hacking.html) in our manual for instruction on how to
|
||||
build nix from source with nix-build or how to get a development environment.
|
||||
|
||||
## Additional Resources
|
||||
|
||||
- [Nix manual](https://nixos.org/nix/manual)
|
||||
- [Nix jobsets on hydra.nixos.org](https://hydra.nixos.org/project/nix)
|
||||
- [NixOS Discourse](https://discourse.nixos.org/)
|
||||
- [IRC - #nixos on freenode.net](irc://irc.freenode.net/#nixos)
|
||||
|
||||
## License
|
||||
|
||||
Nix is released under the LGPL v2.1
|
||||
|
||||
This product includes software developed by the OpenSSL Project for
|
||||
use in the [OpenSSL Toolkit](http://www.OpenSSL.org/).
|
||||
Nix is released under the [LGPL v2.1](./COPYING).
|
||||
|
|
|
|||
500
config/config.guess
vendored
500
config/config.guess
vendored
|
|
@ -1,8 +1,8 @@
|
|||
#! /bin/sh
|
||||
# Attempt to guess a canonical system name.
|
||||
# Copyright 1992-2018 Free Software Foundation, Inc.
|
||||
# Copyright 1992-2020 Free Software Foundation, Inc.
|
||||
|
||||
timestamp='2018-08-02'
|
||||
timestamp='2020-11-19'
|
||||
|
||||
# This file is free software; you can redistribute it and/or modify it
|
||||
# under the terms of the GNU General Public License as published by
|
||||
|
|
@ -27,12 +27,12 @@ timestamp='2018-08-02'
|
|||
# Originally written by Per Bothner; maintained since 2000 by Ben Elliston.
|
||||
#
|
||||
# You can get the latest version of this script from:
|
||||
# https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess
|
||||
# https://git.savannah.gnu.org/cgit/config.git/plain/config.guess
|
||||
#
|
||||
# Please send patches to <config-patches@gnu.org>.
|
||||
|
||||
|
||||
me=`echo "$0" | sed -e 's,.*/,,'`
|
||||
me=$(echo "$0" | sed -e 's,.*/,,')
|
||||
|
||||
usage="\
|
||||
Usage: $0 [OPTION]
|
||||
|
|
@ -50,7 +50,7 @@ version="\
|
|||
GNU config.guess ($timestamp)
|
||||
|
||||
Originally written by Per Bothner.
|
||||
Copyright 1992-2018 Free Software Foundation, Inc.
|
||||
Copyright 1992-2020 Free Software Foundation, Inc.
|
||||
|
||||
This is free software; see the source for copying conditions. There is NO
|
||||
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
|
||||
|
|
@ -96,13 +96,14 @@ fi
|
|||
|
||||
tmp=
|
||||
# shellcheck disable=SC2172
|
||||
trap 'test -z "$tmp" || rm -fr "$tmp"' 1 2 13 15
|
||||
trap 'exitcode=$?; test -z "$tmp" || rm -fr "$tmp"; exit $exitcode' 0
|
||||
trap 'test -z "$tmp" || rm -fr "$tmp"' 0 1 2 13 15
|
||||
|
||||
set_cc_for_build() {
|
||||
# prevent multiple calls if $tmp is already set
|
||||
test "$tmp" && return 0
|
||||
: "${TMPDIR=/tmp}"
|
||||
# shellcheck disable=SC2039
|
||||
{ tmp=`(umask 077 && mktemp -d "$TMPDIR/cgXXXXXX") 2>/dev/null` && test -n "$tmp" && test -d "$tmp" ; } ||
|
||||
{ tmp=$( (umask 077 && mktemp -d "$TMPDIR/cgXXXXXX") 2>/dev/null) && test -n "$tmp" && test -d "$tmp" ; } ||
|
||||
{ test -n "$RANDOM" && tmp=$TMPDIR/cg$$-$RANDOM && (umask 077 && mkdir "$tmp" 2>/dev/null) ; } ||
|
||||
{ tmp=$TMPDIR/cg-$$ && (umask 077 && mkdir "$tmp" 2>/dev/null) && echo "Warning: creating insecure temp directory" >&2 ; } ||
|
||||
{ echo "$me: cannot create a temporary directory in $TMPDIR" >&2 ; exit 1 ; }
|
||||
|
|
@ -130,16 +131,14 @@ if test -f /.attbin/uname ; then
|
|||
PATH=$PATH:/.attbin ; export PATH
|
||||
fi
|
||||
|
||||
UNAME_MACHINE=`(uname -m) 2>/dev/null` || UNAME_MACHINE=unknown
|
||||
UNAME_RELEASE=`(uname -r) 2>/dev/null` || UNAME_RELEASE=unknown
|
||||
UNAME_SYSTEM=`(uname -s) 2>/dev/null` || UNAME_SYSTEM=unknown
|
||||
UNAME_VERSION=`(uname -v) 2>/dev/null` || UNAME_VERSION=unknown
|
||||
UNAME_MACHINE=$( (uname -m) 2>/dev/null) || UNAME_MACHINE=unknown
|
||||
UNAME_RELEASE=$( (uname -r) 2>/dev/null) || UNAME_RELEASE=unknown
|
||||
UNAME_SYSTEM=$( (uname -s) 2>/dev/null) || UNAME_SYSTEM=unknown
|
||||
UNAME_VERSION=$( (uname -v) 2>/dev/null) || UNAME_VERSION=unknown
|
||||
|
||||
case "$UNAME_SYSTEM" in
|
||||
Linux|GNU|GNU/*)
|
||||
# If the system lacks a compiler, then just pick glibc.
|
||||
# We could probably try harder.
|
||||
LIBC=gnu
|
||||
LIBC=unknown
|
||||
|
||||
set_cc_for_build
|
||||
cat <<-EOF > "$dummy.c"
|
||||
|
|
@ -148,18 +147,30 @@ Linux|GNU|GNU/*)
|
|||
LIBC=uclibc
|
||||
#elif defined(__dietlibc__)
|
||||
LIBC=dietlibc
|
||||
#else
|
||||
#elif defined(__GLIBC__)
|
||||
LIBC=gnu
|
||||
#else
|
||||
#include <stdarg.h>
|
||||
/* First heuristic to detect musl libc. */
|
||||
#ifdef __DEFINED_va_list
|
||||
LIBC=musl
|
||||
#endif
|
||||
#endif
|
||||
EOF
|
||||
eval "`$CC_FOR_BUILD -E "$dummy.c" 2>/dev/null | grep '^LIBC' | sed 's, ,,g'`"
|
||||
eval "$($CC_FOR_BUILD -E "$dummy.c" 2>/dev/null | grep '^LIBC' | sed 's, ,,g')"
|
||||
|
||||
# If ldd exists, use it to detect musl libc.
|
||||
if command -v ldd >/dev/null && \
|
||||
ldd --version 2>&1 | grep -q ^musl
|
||||
then
|
||||
# Second heuristic to detect musl libc.
|
||||
if [ "$LIBC" = unknown ] &&
|
||||
command -v ldd >/dev/null &&
|
||||
ldd --version 2>&1 | grep -q ^musl; then
|
||||
LIBC=musl
|
||||
fi
|
||||
|
||||
# If the system lacks a compiler, then just pick glibc.
|
||||
# We could probably try harder.
|
||||
if [ "$LIBC" = unknown ]; then
|
||||
LIBC=gnu
|
||||
fi
|
||||
;;
|
||||
esac
|
||||
|
||||
|
|
@ -178,19 +189,20 @@ case "$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
|
|||
# Note: NetBSD doesn't particularly care about the vendor
|
||||
# portion of the name. We always set it to "unknown".
|
||||
sysctl="sysctl -n hw.machine_arch"
|
||||
UNAME_MACHINE_ARCH=`(uname -p 2>/dev/null || \
|
||||
UNAME_MACHINE_ARCH=$( (uname -p 2>/dev/null || \
|
||||
"/sbin/$sysctl" 2>/dev/null || \
|
||||
"/usr/sbin/$sysctl" 2>/dev/null || \
|
||||
echo unknown)`
|
||||
echo unknown))
|
||||
case "$UNAME_MACHINE_ARCH" in
|
||||
aarch64eb) machine=aarch64_be-unknown ;;
|
||||
armeb) machine=armeb-unknown ;;
|
||||
arm*) machine=arm-unknown ;;
|
||||
sh3el) machine=shl-unknown ;;
|
||||
sh3eb) machine=sh-unknown ;;
|
||||
sh5el) machine=sh5le-unknown ;;
|
||||
earmv*)
|
||||
arch=`echo "$UNAME_MACHINE_ARCH" | sed -e 's,^e\(armv[0-9]\).*$,\1,'`
|
||||
endian=`echo "$UNAME_MACHINE_ARCH" | sed -ne 's,^.*\(eb\)$,\1,p'`
|
||||
arch=$(echo "$UNAME_MACHINE_ARCH" | sed -e 's,^e\(armv[0-9]\).*$,\1,')
|
||||
endian=$(echo "$UNAME_MACHINE_ARCH" | sed -ne 's,^.*\(eb\)$,\1,p')
|
||||
machine="${arch}${endian}"-unknown
|
||||
;;
|
||||
*) machine="$UNAME_MACHINE_ARCH"-unknown ;;
|
||||
|
|
@ -221,7 +233,7 @@ case "$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
|
|||
case "$UNAME_MACHINE_ARCH" in
|
||||
earm*)
|
||||
expr='s/^earmv[0-9]/-eabi/;s/eb$//'
|
||||
abi=`echo "$UNAME_MACHINE_ARCH" | sed -e "$expr"`
|
||||
abi=$(echo "$UNAME_MACHINE_ARCH" | sed -e "$expr")
|
||||
;;
|
||||
esac
|
||||
# The OS release
|
||||
|
|
@ -234,7 +246,7 @@ case "$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
|
|||
release='-gnu'
|
||||
;;
|
||||
*)
|
||||
release=`echo "$UNAME_RELEASE" | sed -e 's/[-_].*//' | cut -d. -f1,2`
|
||||
release=$(echo "$UNAME_RELEASE" | sed -e 's/[-_].*//' | cut -d. -f1,2)
|
||||
;;
|
||||
esac
|
||||
# Since CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM:
|
||||
|
|
@ -243,15 +255,15 @@ case "$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
|
|||
echo "$machine-${os}${release}${abi-}"
|
||||
exit ;;
|
||||
*:Bitrig:*:*)
|
||||
UNAME_MACHINE_ARCH=`arch | sed 's/Bitrig.//'`
|
||||
UNAME_MACHINE_ARCH=$(arch | sed 's/Bitrig.//')
|
||||
echo "$UNAME_MACHINE_ARCH"-unknown-bitrig"$UNAME_RELEASE"
|
||||
exit ;;
|
||||
*:OpenBSD:*:*)
|
||||
UNAME_MACHINE_ARCH=`arch | sed 's/OpenBSD.//'`
|
||||
UNAME_MACHINE_ARCH=$(arch | sed 's/OpenBSD.//')
|
||||
echo "$UNAME_MACHINE_ARCH"-unknown-openbsd"$UNAME_RELEASE"
|
||||
exit ;;
|
||||
*:LibertyBSD:*:*)
|
||||
UNAME_MACHINE_ARCH=`arch | sed 's/^.*BSD\.//'`
|
||||
UNAME_MACHINE_ARCH=$(arch | sed 's/^.*BSD\.//')
|
||||
echo "$UNAME_MACHINE_ARCH"-unknown-libertybsd"$UNAME_RELEASE"
|
||||
exit ;;
|
||||
*:MidnightBSD:*:*)
|
||||
|
|
@ -263,6 +275,9 @@ case "$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
|
|||
*:SolidBSD:*:*)
|
||||
echo "$UNAME_MACHINE"-unknown-solidbsd"$UNAME_RELEASE"
|
||||
exit ;;
|
||||
*:OS108:*:*)
|
||||
echo "$UNAME_MACHINE"-unknown-os108_"$UNAME_RELEASE"
|
||||
exit ;;
|
||||
macppc:MirBSD:*:*)
|
||||
echo powerpc-unknown-mirbsd"$UNAME_RELEASE"
|
||||
exit ;;
|
||||
|
|
@ -272,6 +287,9 @@ case "$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
|
|||
*:Sortix:*:*)
|
||||
echo "$UNAME_MACHINE"-unknown-sortix
|
||||
exit ;;
|
||||
*:Twizzler:*:*)
|
||||
echo "$UNAME_MACHINE"-unknown-twizzler
|
||||
exit ;;
|
||||
*:Redox:*:*)
|
||||
echo "$UNAME_MACHINE"-unknown-redox
|
||||
exit ;;
|
||||
|
|
@ -281,17 +299,17 @@ case "$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
|
|||
alpha:OSF1:*:*)
|
||||
case $UNAME_RELEASE in
|
||||
*4.0)
|
||||
UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $3}'`
|
||||
UNAME_RELEASE=$(/usr/sbin/sizer -v | awk '{print $3}')
|
||||
;;
|
||||
*5.*)
|
||||
UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $4}'`
|
||||
UNAME_RELEASE=$(/usr/sbin/sizer -v | awk '{print $4}')
|
||||
;;
|
||||
esac
|
||||
# According to Compaq, /usr/sbin/psrinfo has been available on
|
||||
# OSF/1 and Tru64 systems produced since 1995. I hope that
|
||||
# covers most systems running today. This code pipes the CPU
|
||||
# types through head -n 1, so we only detect the type of CPU 0.
|
||||
ALPHA_CPU_TYPE=`/usr/sbin/psrinfo -v | sed -n -e 's/^ The alpha \(.*\) processor.*$/\1/p' | head -n 1`
|
||||
ALPHA_CPU_TYPE=$(/usr/sbin/psrinfo -v | sed -n -e 's/^ The alpha \(.*\) processor.*$/\1/p' | head -n 1)
|
||||
case "$ALPHA_CPU_TYPE" in
|
||||
"EV4 (21064)")
|
||||
UNAME_MACHINE=alpha ;;
|
||||
|
|
@ -329,7 +347,7 @@ case "$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
|
|||
# A Tn.n version is a released field test version.
|
||||
# A Xn.n version is an unreleased experimental baselevel.
|
||||
# 1.2 uses "1.2" for uname -r.
|
||||
echo "$UNAME_MACHINE"-dec-osf"`echo "$UNAME_RELEASE" | sed -e 's/^[PVTX]//' | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz`"
|
||||
echo "$UNAME_MACHINE"-dec-osf"$(echo "$UNAME_RELEASE" | sed -e 's/^[PVTX]//' | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz)"
|
||||
# Reset EXIT trap before exiting to avoid spurious non-zero exit code.
|
||||
exitcode=$?
|
||||
trap '' 0
|
||||
|
|
@ -363,7 +381,7 @@ case "$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
|
|||
exit ;;
|
||||
Pyramid*:OSx*:*:* | MIS*:OSx*:*:* | MIS*:SMP_DC-OSx*:*:*)
|
||||
# akee@wpdis03.wpafb.af.mil (Earle F. Ake) contributed MIS and NILE.
|
||||
if test "`(/bin/universe) 2>/dev/null`" = att ; then
|
||||
if test "$( (/bin/universe) 2>/dev/null)" = att ; then
|
||||
echo pyramid-pyramid-sysv3
|
||||
else
|
||||
echo pyramid-pyramid-bsd
|
||||
|
|
@ -376,54 +394,59 @@ case "$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
|
|||
echo sparc-icl-nx6
|
||||
exit ;;
|
||||
DRS?6000:UNIX_SV:4.2*:7* | DRS?6000:isis:4.2*:7*)
|
||||
case `/usr/bin/uname -p` in
|
||||
case $(/usr/bin/uname -p) in
|
||||
sparc) echo sparc-icl-nx7; exit ;;
|
||||
esac ;;
|
||||
s390x:SunOS:*:*)
|
||||
echo "$UNAME_MACHINE"-ibm-solaris2"`echo "$UNAME_RELEASE" | sed -e 's/[^.]*//'`"
|
||||
echo "$UNAME_MACHINE"-ibm-solaris2"$(echo "$UNAME_RELEASE" | sed -e 's/[^.]*//')"
|
||||
exit ;;
|
||||
sun4H:SunOS:5.*:*)
|
||||
echo sparc-hal-solaris2"`echo "$UNAME_RELEASE"|sed -e 's/[^.]*//'`"
|
||||
echo sparc-hal-solaris2"$(echo "$UNAME_RELEASE"|sed -e 's/[^.]*//')"
|
||||
exit ;;
|
||||
sun4*:SunOS:5.*:* | tadpole*:SunOS:5.*:*)
|
||||
echo sparc-sun-solaris2"`echo "$UNAME_RELEASE" | sed -e 's/[^.]*//'`"
|
||||
echo sparc-sun-solaris2"$(echo "$UNAME_RELEASE" | sed -e 's/[^.]*//')"
|
||||
exit ;;
|
||||
i86pc:AuroraUX:5.*:* | i86xen:AuroraUX:5.*:*)
|
||||
echo i386-pc-auroraux"$UNAME_RELEASE"
|
||||
exit ;;
|
||||
i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*)
|
||||
UNAME_REL="`echo "$UNAME_RELEASE" | sed -e 's/[^.]*//'`"
|
||||
case `isainfo -b` in
|
||||
32)
|
||||
echo i386-pc-solaris2"$UNAME_REL"
|
||||
;;
|
||||
64)
|
||||
echo x86_64-pc-solaris2"$UNAME_REL"
|
||||
;;
|
||||
esac
|
||||
set_cc_for_build
|
||||
SUN_ARCH=i386
|
||||
# If there is a compiler, see if it is configured for 64-bit objects.
|
||||
# Note that the Sun cc does not turn __LP64__ into 1 like gcc does.
|
||||
# This test works for both compilers.
|
||||
if test "$CC_FOR_BUILD" != no_compiler_found; then
|
||||
if (echo '#ifdef __amd64'; echo IS_64BIT_ARCH; echo '#endif') | \
|
||||
(CCOPTS="" $CC_FOR_BUILD -E - 2>/dev/null) | \
|
||||
grep IS_64BIT_ARCH >/dev/null
|
||||
then
|
||||
SUN_ARCH=x86_64
|
||||
fi
|
||||
fi
|
||||
echo "$SUN_ARCH"-pc-solaris2"$(echo "$UNAME_RELEASE"|sed -e 's/[^.]*//')"
|
||||
exit ;;
|
||||
sun4*:SunOS:6*:*)
|
||||
# According to config.sub, this is the proper way to canonicalize
|
||||
# SunOS6. Hard to guess exactly what SunOS6 will be like, but
|
||||
# it's likely to be more like Solaris than SunOS4.
|
||||
echo sparc-sun-solaris3"`echo "$UNAME_RELEASE"|sed -e 's/[^.]*//'`"
|
||||
echo sparc-sun-solaris3"$(echo "$UNAME_RELEASE"|sed -e 's/[^.]*//')"
|
||||
exit ;;
|
||||
sun4*:SunOS:*:*)
|
||||
case "`/usr/bin/arch -k`" in
|
||||
case "$(/usr/bin/arch -k)" in
|
||||
Series*|S4*)
|
||||
UNAME_RELEASE=`uname -v`
|
||||
UNAME_RELEASE=$(uname -v)
|
||||
;;
|
||||
esac
|
||||
# Japanese Language versions have a version number like `4.1.3-JL'.
|
||||
echo sparc-sun-sunos"`echo "$UNAME_RELEASE"|sed -e 's/-/_/'`"
|
||||
echo sparc-sun-sunos"$(echo "$UNAME_RELEASE"|sed -e 's/-/_/')"
|
||||
exit ;;
|
||||
sun3*:SunOS:*:*)
|
||||
echo m68k-sun-sunos"$UNAME_RELEASE"
|
||||
exit ;;
|
||||
sun*:*:4.2BSD:*)
|
||||
UNAME_RELEASE=`(sed 1q /etc/motd | awk '{print substr($5,1,3)}') 2>/dev/null`
|
||||
UNAME_RELEASE=$( (sed 1q /etc/motd | awk '{print substr($5,1,3)}') 2>/dev/null)
|
||||
test "x$UNAME_RELEASE" = x && UNAME_RELEASE=3
|
||||
case "`/bin/arch`" in
|
||||
case "$(/bin/arch)" in
|
||||
sun3)
|
||||
echo m68k-sun-sunos"$UNAME_RELEASE"
|
||||
;;
|
||||
|
|
@ -503,8 +526,8 @@ case "$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
|
|||
}
|
||||
EOF
|
||||
$CC_FOR_BUILD -o "$dummy" "$dummy.c" &&
|
||||
dummyarg=`echo "$UNAME_RELEASE" | sed -n 's/\([0-9]*\).*/\1/p'` &&
|
||||
SYSTEM_NAME=`"$dummy" "$dummyarg"` &&
|
||||
dummyarg=$(echo "$UNAME_RELEASE" | sed -n 's/\([0-9]*\).*/\1/p') &&
|
||||
SYSTEM_NAME=$("$dummy" "$dummyarg") &&
|
||||
{ echo "$SYSTEM_NAME"; exit; }
|
||||
echo mips-mips-riscos"$UNAME_RELEASE"
|
||||
exit ;;
|
||||
|
|
@ -531,11 +554,11 @@ EOF
|
|||
exit ;;
|
||||
AViiON:dgux:*:*)
|
||||
# DG/UX returns AViiON for all architectures
|
||||
UNAME_PROCESSOR=`/usr/bin/uname -p`
|
||||
if [ "$UNAME_PROCESSOR" = mc88100 ] || [ "$UNAME_PROCESSOR" = mc88110 ]
|
||||
UNAME_PROCESSOR=$(/usr/bin/uname -p)
|
||||
if test "$UNAME_PROCESSOR" = mc88100 || test "$UNAME_PROCESSOR" = mc88110
|
||||
then
|
||||
if [ "$TARGET_BINARY_INTERFACE"x = m88kdguxelfx ] || \
|
||||
[ "$TARGET_BINARY_INTERFACE"x = x ]
|
||||
if test "$TARGET_BINARY_INTERFACE"x = m88kdguxelfx || \
|
||||
test "$TARGET_BINARY_INTERFACE"x = x
|
||||
then
|
||||
echo m88k-dg-dgux"$UNAME_RELEASE"
|
||||
else
|
||||
|
|
@ -559,17 +582,17 @@ EOF
|
|||
echo m68k-tektronix-bsd
|
||||
exit ;;
|
||||
*:IRIX*:*:*)
|
||||
echo mips-sgi-irix"`echo "$UNAME_RELEASE"|sed -e 's/-/_/g'`"
|
||||
echo mips-sgi-irix"$(echo "$UNAME_RELEASE"|sed -e 's/-/_/g')"
|
||||
exit ;;
|
||||
????????:AIX?:[12].1:2) # AIX 2.2.1 or AIX 2.1.1 is RT/PC AIX.
|
||||
echo romp-ibm-aix # uname -m gives an 8 hex-code CPU id
|
||||
exit ;; # Note that: echo "'`uname -s`'" gives 'AIX '
|
||||
exit ;; # Note that: echo "'$(uname -s)'" gives 'AIX '
|
||||
i*86:AIX:*:*)
|
||||
echo i386-ibm-aix
|
||||
exit ;;
|
||||
ia64:AIX:*:*)
|
||||
if [ -x /usr/bin/oslevel ] ; then
|
||||
IBM_REV=`/usr/bin/oslevel`
|
||||
if test -x /usr/bin/oslevel ; then
|
||||
IBM_REV=$(/usr/bin/oslevel)
|
||||
else
|
||||
IBM_REV="$UNAME_VERSION.$UNAME_RELEASE"
|
||||
fi
|
||||
|
|
@ -589,7 +612,7 @@ EOF
|
|||
exit(0);
|
||||
}
|
||||
EOF
|
||||
if $CC_FOR_BUILD -o "$dummy" "$dummy.c" && SYSTEM_NAME=`"$dummy"`
|
||||
if $CC_FOR_BUILD -o "$dummy" "$dummy.c" && SYSTEM_NAME=$("$dummy")
|
||||
then
|
||||
echo "$SYSTEM_NAME"
|
||||
else
|
||||
|
|
@ -602,15 +625,15 @@ EOF
|
|||
fi
|
||||
exit ;;
|
||||
*:AIX:*:[4567])
|
||||
IBM_CPU_ID=`/usr/sbin/lsdev -C -c processor -S available | sed 1q | awk '{ print $1 }'`
|
||||
IBM_CPU_ID=$(/usr/sbin/lsdev -C -c processor -S available | sed 1q | awk '{ print $1 }')
|
||||
if /usr/sbin/lsattr -El "$IBM_CPU_ID" | grep ' POWER' >/dev/null 2>&1; then
|
||||
IBM_ARCH=rs6000
|
||||
else
|
||||
IBM_ARCH=powerpc
|
||||
fi
|
||||
if [ -x /usr/bin/lslpp ] ; then
|
||||
IBM_REV=`/usr/bin/lslpp -Lqc bos.rte.libc |
|
||||
awk -F: '{ print $3 }' | sed s/[0-9]*$/0/`
|
||||
if test -x /usr/bin/lslpp ; then
|
||||
IBM_REV=$(/usr/bin/lslpp -Lqc bos.rte.libc |
|
||||
awk -F: '{ print $3 }' | sed s/[0-9]*$/0/)
|
||||
else
|
||||
IBM_REV="$UNAME_VERSION.$UNAME_RELEASE"
|
||||
fi
|
||||
|
|
@ -638,14 +661,14 @@ EOF
|
|||
echo m68k-hp-bsd4.4
|
||||
exit ;;
|
||||
9000/[34678]??:HP-UX:*:*)
|
||||
HPUX_REV=`echo "$UNAME_RELEASE"|sed -e 's/[^.]*.[0B]*//'`
|
||||
HPUX_REV=$(echo "$UNAME_RELEASE"|sed -e 's/[^.]*.[0B]*//')
|
||||
case "$UNAME_MACHINE" in
|
||||
9000/31?) HP_ARCH=m68000 ;;
|
||||
9000/[34]??) HP_ARCH=m68k ;;
|
||||
9000/[678][0-9][0-9])
|
||||
if [ -x /usr/bin/getconf ]; then
|
||||
sc_cpu_version=`/usr/bin/getconf SC_CPU_VERSION 2>/dev/null`
|
||||
sc_kernel_bits=`/usr/bin/getconf SC_KERNEL_BITS 2>/dev/null`
|
||||
if test -x /usr/bin/getconf; then
|
||||
sc_cpu_version=$(/usr/bin/getconf SC_CPU_VERSION 2>/dev/null)
|
||||
sc_kernel_bits=$(/usr/bin/getconf SC_KERNEL_BITS 2>/dev/null)
|
||||
case "$sc_cpu_version" in
|
||||
523) HP_ARCH=hppa1.0 ;; # CPU_PA_RISC1_0
|
||||
528) HP_ARCH=hppa1.1 ;; # CPU_PA_RISC1_1
|
||||
|
|
@ -657,7 +680,7 @@ EOF
|
|||
esac ;;
|
||||
esac
|
||||
fi
|
||||
if [ "$HP_ARCH" = "" ]; then
|
||||
if test "$HP_ARCH" = ""; then
|
||||
set_cc_for_build
|
||||
sed 's/^ //' << EOF > "$dummy.c"
|
||||
|
||||
|
|
@ -692,11 +715,11 @@ EOF
|
|||
exit (0);
|
||||
}
|
||||
EOF
|
||||
(CCOPTS="" $CC_FOR_BUILD -o "$dummy" "$dummy.c" 2>/dev/null) && HP_ARCH=`"$dummy"`
|
||||
(CCOPTS="" $CC_FOR_BUILD -o "$dummy" "$dummy.c" 2>/dev/null) && HP_ARCH=$("$dummy")
|
||||
test -z "$HP_ARCH" && HP_ARCH=hppa
|
||||
fi ;;
|
||||
esac
|
||||
if [ "$HP_ARCH" = hppa2.0w ]
|
||||
if test "$HP_ARCH" = hppa2.0w
|
||||
then
|
||||
set_cc_for_build
|
||||
|
||||
|
|
@ -720,7 +743,7 @@ EOF
|
|||
echo "$HP_ARCH"-hp-hpux"$HPUX_REV"
|
||||
exit ;;
|
||||
ia64:HP-UX:*:*)
|
||||
HPUX_REV=`echo "$UNAME_RELEASE"|sed -e 's/[^.]*.[0B]*//'`
|
||||
HPUX_REV=$(echo "$UNAME_RELEASE"|sed -e 's/[^.]*.[0B]*//')
|
||||
echo ia64-hp-hpux"$HPUX_REV"
|
||||
exit ;;
|
||||
3050*:HI-UX:*:*)
|
||||
|
|
@ -750,7 +773,7 @@ EOF
|
|||
exit (0);
|
||||
}
|
||||
EOF
|
||||
$CC_FOR_BUILD -o "$dummy" "$dummy.c" && SYSTEM_NAME=`"$dummy"` &&
|
||||
$CC_FOR_BUILD -o "$dummy" "$dummy.c" && SYSTEM_NAME=$("$dummy") &&
|
||||
{ echo "$SYSTEM_NAME"; exit; }
|
||||
echo unknown-hitachi-hiuxwe2
|
||||
exit ;;
|
||||
|
|
@ -770,7 +793,7 @@ EOF
|
|||
echo hppa1.0-hp-osf
|
||||
exit ;;
|
||||
i*86:OSF1:*:*)
|
||||
if [ -x /usr/sbin/sysversion ] ; then
|
||||
if test -x /usr/sbin/sysversion ; then
|
||||
echo "$UNAME_MACHINE"-unknown-osf1mk
|
||||
else
|
||||
echo "$UNAME_MACHINE"-unknown-osf1
|
||||
|
|
@ -819,14 +842,14 @@ EOF
|
|||
echo craynv-cray-unicosmp"$UNAME_RELEASE" | sed -e 's/\.[^.]*$/.X/'
|
||||
exit ;;
|
||||
F30[01]:UNIX_System_V:*:* | F700:UNIX_System_V:*:*)
|
||||
FUJITSU_PROC=`uname -m | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz`
|
||||
FUJITSU_SYS=`uname -p | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz | sed -e 's/\///'`
|
||||
FUJITSU_REL=`echo "$UNAME_RELEASE" | sed -e 's/ /_/'`
|
||||
FUJITSU_PROC=$(uname -m | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz)
|
||||
FUJITSU_SYS=$(uname -p | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz | sed -e 's/\///')
|
||||
FUJITSU_REL=$(echo "$UNAME_RELEASE" | sed -e 's/ /_/')
|
||||
echo "${FUJITSU_PROC}-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
|
||||
exit ;;
|
||||
5000:UNIX_System_V:4.*:*)
|
||||
FUJITSU_SYS=`uname -p | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz | sed -e 's/\///'`
|
||||
FUJITSU_REL=`echo "$UNAME_RELEASE" | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz | sed -e 's/ /_/'`
|
||||
FUJITSU_SYS=$(uname -p | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz | sed -e 's/\///')
|
||||
FUJITSU_REL=$(echo "$UNAME_RELEASE" | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz | sed -e 's/ /_/')
|
||||
echo "sparc-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
|
||||
exit ;;
|
||||
i*86:BSD/386:*:* | i*86:BSD/OS:*:* | *:Ascend\ Embedded/OS:*:*)
|
||||
|
|
@ -838,26 +861,26 @@ EOF
|
|||
*:BSD/OS:*:*)
|
||||
echo "$UNAME_MACHINE"-unknown-bsdi"$UNAME_RELEASE"
|
||||
exit ;;
|
||||
arm*:FreeBSD:*:*)
|
||||
UNAME_PROCESSOR=`uname -p`
|
||||
arm:FreeBSD:*:*)
|
||||
UNAME_PROCESSOR=$(uname -p)
|
||||
set_cc_for_build
|
||||
if echo __ARM_PCS_VFP | $CC_FOR_BUILD -E - 2>/dev/null \
|
||||
| grep -q __ARM_PCS_VFP
|
||||
then
|
||||
echo "${UNAME_PROCESSOR}"-unknown-freebsd"`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`"-gnueabi
|
||||
echo "${UNAME_PROCESSOR}"-unknown-freebsd"$(echo ${UNAME_RELEASE}|sed -e 's/[-(].*//')"-gnueabi
|
||||
else
|
||||
echo "${UNAME_PROCESSOR}"-unknown-freebsd"`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`"-gnueabihf
|
||||
echo "${UNAME_PROCESSOR}"-unknown-freebsd"$(echo ${UNAME_RELEASE}|sed -e 's/[-(].*//')"-gnueabihf
|
||||
fi
|
||||
exit ;;
|
||||
*:FreeBSD:*:*)
|
||||
UNAME_PROCESSOR=`/usr/bin/uname -p`
|
||||
UNAME_PROCESSOR=$(/usr/bin/uname -p)
|
||||
case "$UNAME_PROCESSOR" in
|
||||
amd64)
|
||||
UNAME_PROCESSOR=x86_64 ;;
|
||||
i386)
|
||||
UNAME_PROCESSOR=i586 ;;
|
||||
esac
|
||||
echo "$UNAME_PROCESSOR"-unknown-freebsd"`echo "$UNAME_RELEASE"|sed -e 's/[-(].*//'`"
|
||||
echo "$UNAME_PROCESSOR"-unknown-freebsd"$(echo "$UNAME_RELEASE"|sed -e 's/[-(].*//')"
|
||||
exit ;;
|
||||
i*:CYGWIN*:*)
|
||||
echo "$UNAME_MACHINE"-pc-cygwin
|
||||
|
|
@ -890,18 +913,18 @@ EOF
|
|||
echo "$UNAME_MACHINE"-pc-uwin
|
||||
exit ;;
|
||||
amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*)
|
||||
echo x86_64-unknown-cygwin
|
||||
echo x86_64-pc-cygwin
|
||||
exit ;;
|
||||
prep*:SunOS:5.*:*)
|
||||
echo powerpcle-unknown-solaris2"`echo "$UNAME_RELEASE"|sed -e 's/[^.]*//'`"
|
||||
echo powerpcle-unknown-solaris2"$(echo "$UNAME_RELEASE"|sed -e 's/[^.]*//')"
|
||||
exit ;;
|
||||
*:GNU:*:*)
|
||||
# the GNU system
|
||||
echo "`echo "$UNAME_MACHINE"|sed -e 's,[-/].*$,,'`-unknown-$LIBC`echo "$UNAME_RELEASE"|sed -e 's,/.*$,,'`"
|
||||
echo "$(echo "$UNAME_MACHINE"|sed -e 's,[-/].*$,,')-unknown-$LIBC$(echo "$UNAME_RELEASE"|sed -e 's,/.*$,,')"
|
||||
exit ;;
|
||||
*:GNU/*:*:*)
|
||||
# other systems with GNU libc and userland
|
||||
echo "$UNAME_MACHINE-unknown-`echo "$UNAME_SYSTEM" | sed 's,^[^/]*/,,' | tr "[:upper:]" "[:lower:]"``echo "$UNAME_RELEASE"|sed -e 's/[-(].*//'`-$LIBC"
|
||||
echo "$UNAME_MACHINE-unknown-$(echo "$UNAME_SYSTEM" | sed 's,^[^/]*/,,' | tr "[:upper:]" "[:lower:]")$(echo "$UNAME_RELEASE"|sed -e 's/[-(].*//')-$LIBC"
|
||||
exit ;;
|
||||
*:Minix:*:*)
|
||||
echo "$UNAME_MACHINE"-unknown-minix
|
||||
|
|
@ -914,7 +937,7 @@ EOF
|
|||
echo "$UNAME_MACHINE"-unknown-linux-"$LIBC"
|
||||
exit ;;
|
||||
alpha:Linux:*:*)
|
||||
case `sed -n '/^cpu model/s/^.*: \(.*\)/\1/p' < /proc/cpuinfo` in
|
||||
case $(sed -n '/^cpu model/s/^.*: \(.*\)/\1/p' /proc/cpuinfo 2>/dev/null) in
|
||||
EV5) UNAME_MACHINE=alphaev5 ;;
|
||||
EV56) UNAME_MACHINE=alphaev56 ;;
|
||||
PCA56) UNAME_MACHINE=alphapca56 ;;
|
||||
|
|
@ -981,22 +1004,50 @@ EOF
|
|||
exit ;;
|
||||
mips:Linux:*:* | mips64:Linux:*:*)
|
||||
set_cc_for_build
|
||||
IS_GLIBC=0
|
||||
test x"${LIBC}" = xgnu && IS_GLIBC=1
|
||||
sed 's/^ //' << EOF > "$dummy.c"
|
||||
#undef CPU
|
||||
#undef ${UNAME_MACHINE}
|
||||
#undef ${UNAME_MACHINE}el
|
||||
#undef mips
|
||||
#undef mipsel
|
||||
#undef mips64
|
||||
#undef mips64el
|
||||
#if ${IS_GLIBC} && defined(_ABI64)
|
||||
LIBCABI=gnuabi64
|
||||
#else
|
||||
#if ${IS_GLIBC} && defined(_ABIN32)
|
||||
LIBCABI=gnuabin32
|
||||
#else
|
||||
LIBCABI=${LIBC}
|
||||
#endif
|
||||
#endif
|
||||
|
||||
#if ${IS_GLIBC} && defined(__mips64) && defined(__mips_isa_rev) && __mips_isa_rev>=6
|
||||
CPU=mipsisa64r6
|
||||
#else
|
||||
#if ${IS_GLIBC} && !defined(__mips64) && defined(__mips_isa_rev) && __mips_isa_rev>=6
|
||||
CPU=mipsisa32r6
|
||||
#else
|
||||
#if defined(__mips64)
|
||||
CPU=mips64
|
||||
#else
|
||||
CPU=mips
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
|
||||
#if defined(__MIPSEL__) || defined(__MIPSEL) || defined(_MIPSEL) || defined(MIPSEL)
|
||||
CPU=${UNAME_MACHINE}el
|
||||
MIPS_ENDIAN=el
|
||||
#else
|
||||
#if defined(__MIPSEB__) || defined(__MIPSEB) || defined(_MIPSEB) || defined(MIPSEB)
|
||||
CPU=${UNAME_MACHINE}
|
||||
MIPS_ENDIAN=
|
||||
#else
|
||||
CPU=
|
||||
MIPS_ENDIAN=
|
||||
#endif
|
||||
#endif
|
||||
EOF
|
||||
eval "`$CC_FOR_BUILD -E "$dummy.c" 2>/dev/null | grep '^CPU'`"
|
||||
test "x$CPU" != x && { echo "$CPU-unknown-linux-$LIBC"; exit; }
|
||||
eval "$($CC_FOR_BUILD -E "$dummy.c" 2>/dev/null | grep '^CPU\|^MIPS_ENDIAN\|^LIBCABI')"
|
||||
test "x$CPU" != x && { echo "$CPU${MIPS_ENDIAN}-unknown-linux-$LIBCABI"; exit; }
|
||||
;;
|
||||
mips64el:Linux:*:*)
|
||||
echo "$UNAME_MACHINE"-unknown-linux-"$LIBC"
|
||||
|
|
@ -1015,7 +1066,7 @@ EOF
|
|||
exit ;;
|
||||
parisc:Linux:*:* | hppa:Linux:*:*)
|
||||
# Look for CPU level
|
||||
case `grep '^cpu[^a-z]*:' /proc/cpuinfo 2>/dev/null | cut -d' ' -f2` in
|
||||
case $(grep '^cpu[^a-z]*:' /proc/cpuinfo 2>/dev/null | cut -d' ' -f2) in
|
||||
PA7*) echo hppa1.1-unknown-linux-"$LIBC" ;;
|
||||
PA8*) echo hppa2.0-unknown-linux-"$LIBC" ;;
|
||||
*) echo hppa-unknown-linux-"$LIBC" ;;
|
||||
|
|
@ -1055,7 +1106,17 @@ EOF
|
|||
echo "$UNAME_MACHINE"-dec-linux-"$LIBC"
|
||||
exit ;;
|
||||
x86_64:Linux:*:*)
|
||||
echo "$UNAME_MACHINE"-pc-linux-"$LIBC"
|
||||
set_cc_for_build
|
||||
LIBCABI=$LIBC
|
||||
if test "$CC_FOR_BUILD" != no_compiler_found; then
|
||||
if (echo '#ifdef __ILP32__'; echo IS_X32; echo '#endif') | \
|
||||
(CCOPTS="" $CC_FOR_BUILD -E - 2>/dev/null) | \
|
||||
grep IS_X32 >/dev/null
|
||||
then
|
||||
LIBCABI="$LIBC"x32
|
||||
fi
|
||||
fi
|
||||
echo "$UNAME_MACHINE"-pc-linux-"$LIBCABI"
|
||||
exit ;;
|
||||
xtensa*:Linux:*:*)
|
||||
echo "$UNAME_MACHINE"-unknown-linux-"$LIBC"
|
||||
|
|
@ -1095,7 +1156,7 @@ EOF
|
|||
echo "$UNAME_MACHINE"-pc-msdosdjgpp
|
||||
exit ;;
|
||||
i*86:*:4.*:*)
|
||||
UNAME_REL=`echo "$UNAME_RELEASE" | sed 's/\/MP$//'`
|
||||
UNAME_REL=$(echo "$UNAME_RELEASE" | sed 's/\/MP$//')
|
||||
if grep Novell /usr/include/link.h >/dev/null 2>/dev/null; then
|
||||
echo "$UNAME_MACHINE"-univel-sysv"$UNAME_REL"
|
||||
else
|
||||
|
|
@ -1104,19 +1165,19 @@ EOF
|
|||
exit ;;
|
||||
i*86:*:5:[678]*)
|
||||
# UnixWare 7.x, OpenUNIX and OpenServer 6.
|
||||
case `/bin/uname -X | grep "^Machine"` in
|
||||
case $(/bin/uname -X | grep "^Machine") in
|
||||
*486*) UNAME_MACHINE=i486 ;;
|
||||
*Pentium) UNAME_MACHINE=i586 ;;
|
||||
*Pent*|*Celeron) UNAME_MACHINE=i686 ;;
|
||||
esac
|
||||
echo "$UNAME_MACHINE-unknown-sysv${UNAME_RELEASE}${UNAME_SYSTEM}{$UNAME_VERSION}"
|
||||
echo "$UNAME_MACHINE-unknown-sysv${UNAME_RELEASE}${UNAME_SYSTEM}${UNAME_VERSION}"
|
||||
exit ;;
|
||||
i*86:*:3.2:*)
|
||||
if test -f /usr/options/cb.name; then
|
||||
UNAME_REL=`sed -n 's/.*Version //p' </usr/options/cb.name`
|
||||
UNAME_REL=$(sed -n 's/.*Version //p' </usr/options/cb.name)
|
||||
echo "$UNAME_MACHINE"-pc-isc"$UNAME_REL"
|
||||
elif /bin/uname -X 2>/dev/null >/dev/null ; then
|
||||
UNAME_REL=`(/bin/uname -X|grep Release|sed -e 's/.*= //')`
|
||||
UNAME_REL=$( (/bin/uname -X|grep Release|sed -e 's/.*= //'))
|
||||
(/bin/uname -X|grep i80486 >/dev/null) && UNAME_MACHINE=i486
|
||||
(/bin/uname -X|grep '^Machine.*Pentium' >/dev/null) \
|
||||
&& UNAME_MACHINE=i586
|
||||
|
|
@ -1166,7 +1227,7 @@ EOF
|
|||
3[345]??:*:4.0:3.0 | 3[34]??A:*:4.0:3.0 | 3[34]??,*:*:4.0:3.0 | 3[34]??/*:*:4.0:3.0 | 4400:*:4.0:3.0 | 4850:*:4.0:3.0 | SKA40:*:4.0:3.0 | SDS2:*:4.0:3.0 | SHG2:*:4.0:3.0 | S7501*:*:4.0:3.0)
|
||||
OS_REL=''
|
||||
test -r /etc/.relid \
|
||||
&& OS_REL=.`sed -n 's/[^ ]* [^ ]* \([0-9][0-9]\).*/\1/p' < /etc/.relid`
|
||||
&& OS_REL=.$(sed -n 's/[^ ]* [^ ]* \([0-9][0-9]\).*/\1/p' < /etc/.relid)
|
||||
/bin/uname -p 2>/dev/null | grep 86 >/dev/null \
|
||||
&& { echo i486-ncr-sysv4.3"$OS_REL"; exit; }
|
||||
/bin/uname -p 2>/dev/null | /bin/grep entium >/dev/null \
|
||||
|
|
@ -1177,7 +1238,7 @@ EOF
|
|||
NCR*:*:4.2:* | MPRAS*:*:4.2:*)
|
||||
OS_REL='.3'
|
||||
test -r /etc/.relid \
|
||||
&& OS_REL=.`sed -n 's/[^ ]* [^ ]* \([0-9][0-9]\).*/\1/p' < /etc/.relid`
|
||||
&& OS_REL=.$(sed -n 's/[^ ]* [^ ]* \([0-9][0-9]\).*/\1/p' < /etc/.relid)
|
||||
/bin/uname -p 2>/dev/null | grep 86 >/dev/null \
|
||||
&& { echo i486-ncr-sysv4.3"$OS_REL"; exit; }
|
||||
/bin/uname -p 2>/dev/null | /bin/grep entium >/dev/null \
|
||||
|
|
@ -1210,7 +1271,7 @@ EOF
|
|||
exit ;;
|
||||
*:SINIX-*:*:*)
|
||||
if uname -p 2>/dev/null >/dev/null ; then
|
||||
UNAME_MACHINE=`(uname -p) 2>/dev/null`
|
||||
UNAME_MACHINE=$( (uname -p) 2>/dev/null)
|
||||
echo "$UNAME_MACHINE"-sni-sysv4
|
||||
else
|
||||
echo ns32k-sni-sysv
|
||||
|
|
@ -1244,7 +1305,7 @@ EOF
|
|||
echo mips-sony-newsos6
|
||||
exit ;;
|
||||
R[34]000:*System_V*:*:* | R4000:UNIX_SYSV:*:* | R*000:UNIX_SV:*:*)
|
||||
if [ -d /usr/nec ]; then
|
||||
if test -d /usr/nec; then
|
||||
echo mips-nec-sysv"$UNAME_RELEASE"
|
||||
else
|
||||
echo mips-unknown-sysv"$UNAME_RELEASE"
|
||||
|
|
@ -1292,14 +1353,24 @@ EOF
|
|||
*:Rhapsody:*:*)
|
||||
echo "$UNAME_MACHINE"-apple-rhapsody"$UNAME_RELEASE"
|
||||
exit ;;
|
||||
arm64:Darwin:*:*)
|
||||
echo aarch64-apple-darwin"$UNAME_RELEASE"
|
||||
exit ;;
|
||||
*:Darwin:*:*)
|
||||
UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown
|
||||
UNAME_PROCESSOR=$(uname -p)
|
||||
case $UNAME_PROCESSOR in
|
||||
unknown) UNAME_PROCESSOR=powerpc ;;
|
||||
esac
|
||||
if command -v xcode-select > /dev/null 2> /dev/null && \
|
||||
! xcode-select --print-path > /dev/null 2> /dev/null ; then
|
||||
# Avoid executing cc if there is no toolchain installed as
|
||||
# cc will be a stub that puts up a graphical alert
|
||||
# prompting the user to install developer tools.
|
||||
CC_FOR_BUILD=no_compiler_found
|
||||
else
|
||||
set_cc_for_build
|
||||
if test "$UNAME_PROCESSOR" = unknown ; then
|
||||
UNAME_PROCESSOR=powerpc
|
||||
fi
|
||||
if test "`echo "$UNAME_RELEASE" | sed -e 's/\..*//'`" -le 10 ; then
|
||||
if [ "$CC_FOR_BUILD" != no_compiler_found ]; then
|
||||
if test "$CC_FOR_BUILD" != no_compiler_found; then
|
||||
if (echo '#ifdef __LP64__'; echo IS_64BIT_ARCH; echo '#endif') | \
|
||||
(CCOPTS="" $CC_FOR_BUILD -E - 2>/dev/null) | \
|
||||
grep IS_64BIT_ARCH >/dev/null
|
||||
|
|
@ -1316,20 +1387,14 @@ EOF
|
|||
then
|
||||
UNAME_PROCESSOR=powerpc
|
||||
fi
|
||||
fi
|
||||
elif test "$UNAME_PROCESSOR" = i386 ; then
|
||||
# Avoid executing cc on OS X 10.9, as it ships with a stub
|
||||
# that puts up a graphical alert prompting to install
|
||||
# developer tools. Any system running Mac OS X 10.7 or
|
||||
# later (Darwin 11 and later) is required to have a 64-bit
|
||||
# processor. This is not true of the ARM version of Darwin
|
||||
# that Apple uses in portable devices.
|
||||
UNAME_PROCESSOR=x86_64
|
||||
# uname -m returns i386 or x86_64
|
||||
UNAME_PROCESSOR=$UNAME_MACHINE
|
||||
fi
|
||||
echo "$UNAME_PROCESSOR"-apple-darwin"$UNAME_RELEASE"
|
||||
exit ;;
|
||||
*:procnto*:*:* | *:QNX:[0123456789]*:*)
|
||||
UNAME_PROCESSOR=`uname -p`
|
||||
UNAME_PROCESSOR=$(uname -p)
|
||||
if test "$UNAME_PROCESSOR" = x86; then
|
||||
UNAME_PROCESSOR=i386
|
||||
UNAME_MACHINE=pc
|
||||
|
|
@ -1397,10 +1462,10 @@ EOF
|
|||
echo mips-sei-seiux"$UNAME_RELEASE"
|
||||
exit ;;
|
||||
*:DragonFly:*:*)
|
||||
echo "$UNAME_MACHINE"-unknown-dragonfly"`echo "$UNAME_RELEASE"|sed -e 's/[-(].*//'`"
|
||||
echo "$UNAME_MACHINE"-unknown-dragonfly"$(echo "$UNAME_RELEASE"|sed -e 's/[-(].*//')"
|
||||
exit ;;
|
||||
*:*VMS:*:*)
|
||||
UNAME_MACHINE=`(uname -p) 2>/dev/null`
|
||||
UNAME_MACHINE=$( (uname -p) 2>/dev/null)
|
||||
case "$UNAME_MACHINE" in
|
||||
A*) echo alpha-dec-vms ; exit ;;
|
||||
I*) echo ia64-dec-vms ; exit ;;
|
||||
|
|
@ -1410,7 +1475,7 @@ EOF
|
|||
echo i386-pc-xenix
|
||||
exit ;;
|
||||
i*86:skyos:*:*)
|
||||
echo "$UNAME_MACHINE"-pc-skyos"`echo "$UNAME_RELEASE" | sed -e 's/ .*$//'`"
|
||||
echo "$UNAME_MACHINE"-pc-skyos"$(echo "$UNAME_RELEASE" | sed -e 's/ .*$//')"
|
||||
exit ;;
|
||||
i*86:rdos:*:*)
|
||||
echo "$UNAME_MACHINE"-pc-rdos
|
||||
|
|
@ -1424,8 +1489,148 @@ EOF
|
|||
amd64:Isilon\ OneFS:*:*)
|
||||
echo x86_64-unknown-onefs
|
||||
exit ;;
|
||||
*:Unleashed:*:*)
|
||||
echo "$UNAME_MACHINE"-unknown-unleashed"$UNAME_RELEASE"
|
||||
exit ;;
|
||||
esac
|
||||
|
||||
# No uname command or uname output not recognized.
|
||||
set_cc_for_build
|
||||
cat > "$dummy.c" <<EOF
|
||||
#ifdef _SEQUENT_
|
||||
#include <sys/types.h>
|
||||
#include <sys/utsname.h>
|
||||
#endif
|
||||
#if defined(ultrix) || defined(_ultrix) || defined(__ultrix) || defined(__ultrix__)
|
||||
#if defined (vax) || defined (__vax) || defined (__vax__) || defined(mips) || defined(__mips) || defined(__mips__) || defined(MIPS) || defined(__MIPS__)
|
||||
#include <signal.h>
|
||||
#if defined(_SIZE_T_) || defined(SIGLOST)
|
||||
#include <sys/utsname.h>
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
main ()
|
||||
{
|
||||
#if defined (sony)
|
||||
#if defined (MIPSEB)
|
||||
/* BFD wants "bsd" instead of "newsos". Perhaps BFD should be changed,
|
||||
I don't know.... */
|
||||
printf ("mips-sony-bsd\n"); exit (0);
|
||||
#else
|
||||
#include <sys/param.h>
|
||||
printf ("m68k-sony-newsos%s\n",
|
||||
#ifdef NEWSOS4
|
||||
"4"
|
||||
#else
|
||||
""
|
||||
#endif
|
||||
); exit (0);
|
||||
#endif
|
||||
#endif
|
||||
|
||||
#if defined (NeXT)
|
||||
#if !defined (__ARCHITECTURE__)
|
||||
#define __ARCHITECTURE__ "m68k"
|
||||
#endif
|
||||
int version;
|
||||
version=$( (hostinfo | sed -n 's/.*NeXT Mach \([0-9]*\).*/\1/p') 2>/dev/null);
|
||||
if (version < 4)
|
||||
printf ("%s-next-nextstep%d\n", __ARCHITECTURE__, version);
|
||||
else
|
||||
printf ("%s-next-openstep%d\n", __ARCHITECTURE__, version);
|
||||
exit (0);
|
||||
#endif
|
||||
|
||||
#if defined (MULTIMAX) || defined (n16)
|
||||
#if defined (UMAXV)
|
||||
printf ("ns32k-encore-sysv\n"); exit (0);
|
||||
#else
|
||||
#if defined (CMU)
|
||||
printf ("ns32k-encore-mach\n"); exit (0);
|
||||
#else
|
||||
printf ("ns32k-encore-bsd\n"); exit (0);
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
|
||||
#if defined (__386BSD__)
|
||||
printf ("i386-pc-bsd\n"); exit (0);
|
||||
#endif
|
||||
|
||||
#if defined (sequent)
|
||||
#if defined (i386)
|
||||
printf ("i386-sequent-dynix\n"); exit (0);
|
||||
#endif
|
||||
#if defined (ns32000)
|
||||
printf ("ns32k-sequent-dynix\n"); exit (0);
|
||||
#endif
|
||||
#endif
|
||||
|
||||
#if defined (_SEQUENT_)
|
||||
struct utsname un;
|
||||
|
||||
uname(&un);
|
||||
if (strncmp(un.version, "V2", 2) == 0) {
|
||||
printf ("i386-sequent-ptx2\n"); exit (0);
|
||||
}
|
||||
if (strncmp(un.version, "V1", 2) == 0) { /* XXX is V1 correct? */
|
||||
printf ("i386-sequent-ptx1\n"); exit (0);
|
||||
}
|
||||
printf ("i386-sequent-ptx\n"); exit (0);
|
||||
#endif
|
||||
|
||||
#if defined (vax)
|
||||
#if !defined (ultrix)
|
||||
#include <sys/param.h>
|
||||
#if defined (BSD)
|
||||
#if BSD == 43
|
||||
printf ("vax-dec-bsd4.3\n"); exit (0);
|
||||
#else
|
||||
#if BSD == 199006
|
||||
printf ("vax-dec-bsd4.3reno\n"); exit (0);
|
||||
#else
|
||||
printf ("vax-dec-bsd\n"); exit (0);
|
||||
#endif
|
||||
#endif
|
||||
#else
|
||||
printf ("vax-dec-bsd\n"); exit (0);
|
||||
#endif
|
||||
#else
|
||||
#if defined(_SIZE_T_) || defined(SIGLOST)
|
||||
struct utsname un;
|
||||
uname (&un);
|
||||
printf ("vax-dec-ultrix%s\n", un.release); exit (0);
|
||||
#else
|
||||
printf ("vax-dec-ultrix\n"); exit (0);
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
#if defined(ultrix) || defined(_ultrix) || defined(__ultrix) || defined(__ultrix__)
|
||||
#if defined(mips) || defined(__mips) || defined(__mips__) || defined(MIPS) || defined(__MIPS__)
|
||||
#if defined(_SIZE_T_) || defined(SIGLOST)
|
||||
struct utsname *un;
|
||||
uname (&un);
|
||||
printf ("mips-dec-ultrix%s\n", un.release); exit (0);
|
||||
#else
|
||||
printf ("mips-dec-ultrix\n"); exit (0);
|
||||
#endif
|
||||
#endif
|
||||
#endif
|
||||
|
||||
#if defined (alliant) && defined (i860)
|
||||
printf ("i860-alliant-bsd\n"); exit (0);
|
||||
#endif
|
||||
|
||||
exit (1);
|
||||
}
|
||||
EOF
|
||||
|
||||
$CC_FOR_BUILD -o "$dummy" "$dummy.c" 2>/dev/null && SYSTEM_NAME=$($dummy) &&
|
||||
{ echo "$SYSTEM_NAME"; exit; }
|
||||
|
||||
# Apollos put the system type in the environment.
|
||||
test -d /usr/apollo && { echo "$ISP-apollo-$SYSTYPE"; exit; }
|
||||
|
||||
echo "$0: unable to guess system type" >&2
|
||||
|
||||
case "$UNAME_MACHINE:$UNAME_SYSTEM" in
|
||||
|
|
@ -1445,9 +1650,15 @@ This script (version $timestamp), has failed to recognize the
|
|||
operating system you are using. If your script is old, overwrite *all*
|
||||
copies of config.guess and config.sub with the latest versions from:
|
||||
|
||||
https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess
|
||||
https://git.savannah.gnu.org/cgit/config.git/plain/config.guess
|
||||
and
|
||||
https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub
|
||||
https://git.savannah.gnu.org/cgit/config.git/plain/config.sub
|
||||
EOF
|
||||
|
||||
year=$(echo $timestamp | sed 's,-.*,,')
|
||||
# shellcheck disable=SC2003
|
||||
if test "$(expr "$(date +%Y)" - "$year")" -lt 3 ; then
|
||||
cat >&2 <<EOF
|
||||
|
||||
If $0 has already been updated, send the following data and any
|
||||
information you think might be pertinent to config-patches@gnu.org to
|
||||
|
|
@ -1455,26 +1666,27 @@ provide the necessary information to handle your system.
|
|||
|
||||
config.guess timestamp = $timestamp
|
||||
|
||||
uname -m = `(uname -m) 2>/dev/null || echo unknown`
|
||||
uname -r = `(uname -r) 2>/dev/null || echo unknown`
|
||||
uname -s = `(uname -s) 2>/dev/null || echo unknown`
|
||||
uname -v = `(uname -v) 2>/dev/null || echo unknown`
|
||||
uname -m = $( (uname -m) 2>/dev/null || echo unknown)
|
||||
uname -r = $( (uname -r) 2>/dev/null || echo unknown)
|
||||
uname -s = $( (uname -s) 2>/dev/null || echo unknown)
|
||||
uname -v = $( (uname -v) 2>/dev/null || echo unknown)
|
||||
|
||||
/usr/bin/uname -p = `(/usr/bin/uname -p) 2>/dev/null`
|
||||
/bin/uname -X = `(/bin/uname -X) 2>/dev/null`
|
||||
/usr/bin/uname -p = $( (/usr/bin/uname -p) 2>/dev/null)
|
||||
/bin/uname -X = $( (/bin/uname -X) 2>/dev/null)
|
||||
|
||||
hostinfo = `(hostinfo) 2>/dev/null`
|
||||
/bin/universe = `(/bin/universe) 2>/dev/null`
|
||||
/usr/bin/arch -k = `(/usr/bin/arch -k) 2>/dev/null`
|
||||
/bin/arch = `(/bin/arch) 2>/dev/null`
|
||||
/usr/bin/oslevel = `(/usr/bin/oslevel) 2>/dev/null`
|
||||
/usr/convex/getsysinfo = `(/usr/convex/getsysinfo) 2>/dev/null`
|
||||
hostinfo = $( (hostinfo) 2>/dev/null)
|
||||
/bin/universe = $( (/bin/universe) 2>/dev/null)
|
||||
/usr/bin/arch -k = $( (/usr/bin/arch -k) 2>/dev/null)
|
||||
/bin/arch = $( (/bin/arch) 2>/dev/null)
|
||||
/usr/bin/oslevel = $( (/usr/bin/oslevel) 2>/dev/null)
|
||||
/usr/convex/getsysinfo = $( (/usr/convex/getsysinfo) 2>/dev/null)
|
||||
|
||||
UNAME_MACHINE = "$UNAME_MACHINE"
|
||||
UNAME_RELEASE = "$UNAME_RELEASE"
|
||||
UNAME_SYSTEM = "$UNAME_SYSTEM"
|
||||
UNAME_VERSION = "$UNAME_VERSION"
|
||||
EOF
|
||||
fi
|
||||
|
||||
exit 1
|
||||
|
||||
|
|
|
|||
1750
config/config.sub
vendored
1750
config/config.sub
vendored
File diff suppressed because it is too large
Load diff
126
configure.ac
126
configure.ac
|
|
@ -1,4 +1,5 @@
|
|||
AC_INIT(nix, m4_esyscmd([bash -c "echo -n $(cat ./version)$VERSION_SUFFIX"]))
|
||||
AC_INIT(nix, m4_esyscmd([bash -c "echo -n $(cat ./.version)$VERSION_SUFFIX"]))
|
||||
AC_CONFIG_MACRO_DIRS([m4])
|
||||
AC_CONFIG_SRCDIR(README.md)
|
||||
AC_CONFIG_AUX_DIR(config)
|
||||
|
||||
|
|
@ -42,13 +43,25 @@ esac
|
|||
|
||||
AC_MSG_RESULT($system)
|
||||
AC_SUBST(system)
|
||||
AC_DEFINE_UNQUOTED(SYSTEM, ["$system"], [platform identifier (`cpu-os')])
|
||||
AC_DEFINE_UNQUOTED(SYSTEM, ["$system"], [platform identifier ('cpu-os')])
|
||||
|
||||
|
||||
# State should be stored in /nix/var, unless the user overrides it explicitly.
|
||||
test "$localstatedir" = '${prefix}/var' && localstatedir=/nix/var
|
||||
|
||||
|
||||
CFLAGS=
|
||||
CXXFLAGS=
|
||||
AC_PROG_CC
|
||||
AC_PROG_CXX
|
||||
AC_PROG_CPP
|
||||
|
||||
AC_CHECK_TOOL([AR], [ar])
|
||||
|
||||
# Use 64-bit file system calls so that we can support files > 2 GiB.
|
||||
AC_SYS_LARGEFILE
|
||||
|
||||
|
||||
# Solaris-specific stuff.
|
||||
AC_STRUCT_DIRENT_D_TYPE
|
||||
if test "$sys_name" = sunos; then
|
||||
|
|
@ -57,18 +70,6 @@ if test "$sys_name" = sunos; then
|
|||
fi
|
||||
|
||||
|
||||
CFLAGS=
|
||||
CXXFLAGS=
|
||||
AC_PROG_CC
|
||||
AC_PROG_CXX
|
||||
AC_PROG_CPP
|
||||
AX_CXX_COMPILE_STDCXX_14
|
||||
|
||||
|
||||
# Use 64-bit file system calls so that we can support files > 2 GiB.
|
||||
AC_SYS_LARGEFILE
|
||||
|
||||
|
||||
# Check for pubsetbuf.
|
||||
AC_MSG_CHECKING([for pubsetbuf])
|
||||
AC_LANG_PUSH(C++)
|
||||
|
|
@ -116,26 +117,14 @@ fi
|
|||
])
|
||||
|
||||
NEED_PROG(bash, bash)
|
||||
NEED_PROG(patch, patch)
|
||||
AC_PATH_PROG(xmllint, xmllint, false)
|
||||
AC_PATH_PROG(xsltproc, xsltproc, false)
|
||||
AC_PATH_PROG(flex, flex, false)
|
||||
AC_PATH_PROG(bison, bison, false)
|
||||
NEED_PROG(sed, sed)
|
||||
NEED_PROG(tar, tar)
|
||||
NEED_PROG(bzip2, bzip2)
|
||||
NEED_PROG(gzip, gzip)
|
||||
NEED_PROG(xz, xz)
|
||||
AC_PATH_PROG(dot, dot)
|
||||
AC_PATH_PROG(lsof, lsof, lsof)
|
||||
NEED_PROG(jq, jq)
|
||||
|
||||
|
||||
NEED_PROG(cat, cat)
|
||||
NEED_PROG(tr, tr)
|
||||
AC_ARG_WITH(coreutils-bin, AC_HELP_STRING([--with-coreutils-bin=PATH],
|
||||
[path of cat, mkdir, etc.]),
|
||||
coreutils=$withval, coreutils=$(dirname $cat))
|
||||
AC_SUBST(coreutils)
|
||||
AC_SUBST(coreutils, [$(dirname $(type -p cat))])
|
||||
|
||||
|
||||
AC_ARG_WITH(store-dir, AC_HELP_STRING([--with-store-dir=PATH],
|
||||
|
|
@ -144,40 +133,87 @@ AC_ARG_WITH(store-dir, AC_HELP_STRING([--with-store-dir=PATH],
|
|||
AC_SUBST(storedir)
|
||||
|
||||
|
||||
# Look for OpenSSL, a required dependency.
|
||||
# Look for boost, a required dependency.
|
||||
# Note that AX_BOOST_BASE only exports *CPP* BOOST_CPPFLAGS, no CXX flags,
|
||||
# and CPPFLAGS are not passed to the C++ compiler automatically.
|
||||
# Thus we append the returned CPPFLAGS to the CXXFLAGS here.
|
||||
AX_BOOST_BASE([1.66], [CXXFLAGS="$BOOST_CPPFLAGS $CXXFLAGS"], [AC_MSG_ERROR([Nix requires boost.])])
|
||||
# For unknown reasons, setting this directly in the ACTION-IF-FOUND above
|
||||
# ends up with LDFLAGS being empty, so we set it afterwards.
|
||||
LDFLAGS="$BOOST_LDFLAGS $LDFLAGS"
|
||||
|
||||
# On some platforms, new-style atomics need a helper library
|
||||
AC_MSG_CHECKING(whether -latomic is needed)
|
||||
AC_LINK_IFELSE([AC_LANG_SOURCE([[
|
||||
#include <stdint.h>
|
||||
uint64_t v;
|
||||
int main() {
|
||||
return (int)__atomic_load_n(&v, __ATOMIC_ACQUIRE);
|
||||
}]])], GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC=no, GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC=yes)
|
||||
AC_MSG_RESULT($GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC)
|
||||
if test "x$GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC" = xyes; then
|
||||
LIBS="-latomic $LIBS"
|
||||
fi
|
||||
|
||||
PKG_PROG_PKG_CONFIG
|
||||
|
||||
AC_ARG_ENABLE(shared, AC_HELP_STRING([--enable-shared],
|
||||
[Build shared libraries for Nix [default=yes]]),
|
||||
shared=$enableval, shared=yes)
|
||||
if test "$shared" = yes; then
|
||||
AC_SUBST(BUILD_SHARED_LIBS, 1, [Whether to build shared libraries.])
|
||||
else
|
||||
AC_SUBST(BUILD_SHARED_LIBS, 0, [Whether to build shared libraries.])
|
||||
PKG_CONFIG="$PKG_CONFIG --static"
|
||||
fi
|
||||
|
||||
# Look for OpenSSL, a required dependency. FIXME: this is only (maybe)
|
||||
# used by S3BinaryCacheStore.
|
||||
PKG_CHECK_MODULES([OPENSSL], [libcrypto], [CXXFLAGS="$OPENSSL_CFLAGS $CXXFLAGS"])
|
||||
|
||||
|
||||
# Look for libbz2, a required dependency.
|
||||
AC_CHECK_LIB([bz2], [BZ2_bzWriteOpen], [true],
|
||||
[AC_MSG_ERROR([Nix requires libbz2, which is part of bzip2. See https://web.archive.org/web/20180624184756/http://www.bzip.org/.])])
|
||||
[AC_MSG_ERROR([Nix requires libbz2, which is part of bzip2. See https://sourceware.org/bzip2/.])])
|
||||
AC_CHECK_HEADERS([bzlib.h], [true],
|
||||
[AC_MSG_ERROR([Nix requires libbz2, which is part of bzip2. See https://web.archive.org/web/20180624184756/http://www.bzip.org/.])])
|
||||
|
||||
[AC_MSG_ERROR([Nix requires libbz2, which is part of bzip2. See https://sourceware.org/bzip2/.])])
|
||||
# Checks for libarchive
|
||||
PKG_CHECK_MODULES([LIBARCHIVE], [libarchive >= 3.1.2], [CXXFLAGS="$LIBARCHIVE_CFLAGS $CXXFLAGS"])
|
||||
# Workaround until https://github.com/libarchive/libarchive/issues/1446 is fixed
|
||||
if test "$shared" != yes; then
|
||||
LIBARCHIVE_LIBS+=' -lz'
|
||||
fi
|
||||
|
||||
# Look for SQLite, a required dependency.
|
||||
PKG_CHECK_MODULES([SQLITE3], [sqlite3 >= 3.6.19], [CXXFLAGS="$SQLITE3_CFLAGS $CXXFLAGS"])
|
||||
|
||||
|
||||
# Look for libcurl, a required dependency.
|
||||
PKG_CHECK_MODULES([LIBCURL], [libcurl], [CXXFLAGS="$LIBCURL_CFLAGS $CXXFLAGS"])
|
||||
|
||||
# Look for editline, a required dependency.
|
||||
PKG_CHECK_MODULES([EDITLINE], [libeditline], [CXXFLAGS="$EDITLINE_CFLAGS $CXXFLAGS"])
|
||||
# The the libeditline.pc file was added only in libeditline >= 1.15.2,
|
||||
# see https://github.com/troglobit/editline/commit/0a8f2ef4203c3a4a4726b9dd1336869cd0da8607,
|
||||
# but e.g. Ubuntu 16.04 has an older version, so we fall back to searching for
|
||||
# editline.h when the pkg-config approach fails.
|
||||
PKG_CHECK_MODULES([EDITLINE], [libeditline], [CXXFLAGS="$EDITLINE_CFLAGS $CXXFLAGS"], [
|
||||
AC_CHECK_HEADERS([editline.h], [true],
|
||||
[AC_MSG_ERROR([Nix requires libeditline; it was found neither via pkg-config nor its normal header.])])
|
||||
AC_SEARCH_LIBS([readline read_history], [editline], [],
|
||||
[AC_MSG_ERROR([Nix requires libeditline; it was not found via pkg-config, but via its header, but required functions do not work. Maybe it is too old? >= 1.14 is required.])])
|
||||
])
|
||||
|
||||
# Look for libsodium, an optional dependency.
|
||||
PKG_CHECK_MODULES([SODIUM], [libsodium],
|
||||
[AC_DEFINE([HAVE_SODIUM], [1], [Whether to use libsodium for cryptography.])
|
||||
CXXFLAGS="$SODIUM_CFLAGS $CXXFLAGS"
|
||||
have_sodium=1], [have_sodium=])
|
||||
AC_SUBST(HAVE_SODIUM, [$have_sodium])
|
||||
|
||||
PKG_CHECK_MODULES([SODIUM], [libsodium], [CXXFLAGS="$SODIUM_CFLAGS $CXXFLAGS"])
|
||||
|
||||
# Look for liblzma, a required dependency.
|
||||
PKG_CHECK_MODULES([LIBLZMA], [liblzma], [CXXFLAGS="$LIBLZMA_CFLAGS $CXXFLAGS"])
|
||||
AC_CHECK_LIB([lzma], [lzma_stream_encoder_mt],
|
||||
[AC_DEFINE([HAVE_LZMA_MT], [1], [xz multithreaded compression support])])
|
||||
|
||||
# Look for zlib, a required dependency.
|
||||
PKG_CHECK_MODULES([ZLIB], [zlib], [CXXFLAGS="$ZLIB_CFLAGS $CXXFLAGS"])
|
||||
AC_CHECK_HEADER([zlib.h],[:],[AC_MSG_ERROR([could not find the zlib.h header])])
|
||||
LDFLAGS="-lz $LDFLAGS"
|
||||
|
||||
# Look for libbrotli{enc,dec}.
|
||||
PKG_CHECK_MODULES([LIBBROTLI], [libbrotlienc libbrotlidec], [CXXFLAGS="$LIBBROTLI_CFLAGS $CXXFLAGS"])
|
||||
|
|
@ -215,13 +251,14 @@ if test -n "$enable_s3"; then
|
|||
declare -a aws_version_tokens=($(printf '#include <aws/core/VersionConfig.h>\nAWS_SDK_VERSION_STRING' | $CPP $CPPFLAGS - | grep -v '^#.*' | sed 's/"//g' | tr '.' ' '))
|
||||
AC_DEFINE_UNQUOTED([AWS_VERSION_MAJOR], ${aws_version_tokens@<:@0@:>@}, [Major version of aws-sdk-cpp.])
|
||||
AC_DEFINE_UNQUOTED([AWS_VERSION_MINOR], ${aws_version_tokens@<:@1@:>@}, [Minor version of aws-sdk-cpp.])
|
||||
AC_DEFINE_UNQUOTED([AWS_VERSION_PATCH], ${aws_version_tokens@<:@2@:>@}, [Patch version of aws-sdk-cpp.])
|
||||
fi
|
||||
|
||||
|
||||
# Whether to use the Boehm garbage collector.
|
||||
AC_ARG_ENABLE(gc, AC_HELP_STRING([--enable-gc],
|
||||
[enable garbage collection in the Nix expression evaluator (requires Boehm GC) [default=no]]),
|
||||
gc=$enableval, gc=no)
|
||||
[enable garbage collection in the Nix expression evaluator (requires Boehm GC) [default=yes]]),
|
||||
gc=$enableval, gc=yes)
|
||||
if test "$gc" = yes; then
|
||||
PKG_CHECK_MODULES([BDW_GC], [bdw-gc])
|
||||
CXXFLAGS="$BDW_GC_CFLAGS $CXXFLAGS"
|
||||
|
|
@ -229,6 +266,10 @@ if test "$gc" = yes; then
|
|||
fi
|
||||
|
||||
|
||||
# Look for gtest.
|
||||
PKG_CHECK_MODULES([GTEST], [gtest_main])
|
||||
|
||||
|
||||
# documentation generation switch
|
||||
AC_ARG_ENABLE(doc-gen, AC_HELP_STRING([--disable-doc-gen],
|
||||
[disable documentation generation]),
|
||||
|
|
@ -267,7 +308,6 @@ AC_ARG_WITH(sandbox-shell, AC_HELP_STRING([--with-sandbox-shell=PATH],
|
|||
sandbox_shell=$withval)
|
||||
AC_SUBST(sandbox_shell)
|
||||
|
||||
|
||||
# Expand all variables in config.status.
|
||||
test "$prefix" = NONE && prefix=$ac_default_prefix
|
||||
test "$exec_prefix" = NONE && exec_prefix='${prefix}'
|
||||
|
|
|
|||
38
contrib/stack-collapse.py
Executable file
38
contrib/stack-collapse.py
Executable file
|
|
@ -0,0 +1,38 @@
|
|||
#!/usr/bin/env nix-shell
|
||||
#!nix-shell -i python3 -p python3 --pure
|
||||
|
||||
# To be used with `--trace-function-calls` and `flamegraph.pl`.
|
||||
#
|
||||
# For example:
|
||||
#
|
||||
# nix-instantiate --trace-function-calls '<nixpkgs>' -A hello 2> nix-function-calls.trace
|
||||
# ./contrib/stack-collapse.py nix-function-calls.trace > nix-function-calls.folded
|
||||
# nix-shell -p flamegraph --run "flamegraph.pl nix-function-calls.folded > nix-function-calls.svg"
|
||||
|
||||
import sys
|
||||
from pprint import pprint
|
||||
import fileinput
|
||||
|
||||
stack = []
|
||||
timestack = []
|
||||
|
||||
for line in fileinput.input():
|
||||
components = line.strip().split(" ", 2)
|
||||
if components[0] != "function-trace":
|
||||
continue
|
||||
|
||||
direction = components[1]
|
||||
components = components[2].rsplit(" ", 2)
|
||||
|
||||
loc = components[0]
|
||||
_at = components[1]
|
||||
time = int(components[2])
|
||||
|
||||
if direction == "entered":
|
||||
stack.append(loc)
|
||||
timestack.append(time)
|
||||
elif direction == "exited":
|
||||
dur = time - timestack.pop()
|
||||
vst = ";".join(stack)
|
||||
print(f"{vst} {dur}")
|
||||
stack.pop()
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
let
|
||||
fromEnv = var: def:
|
||||
let val = builtins.getEnv var; in
|
||||
if val != "" then val else def;
|
||||
in rec {
|
||||
shell = "@bash@";
|
||||
coreutils = "@coreutils@";
|
||||
bzip2 = "@bzip2@";
|
||||
gzip = "@gzip@";
|
||||
xz = "@xz@";
|
||||
tar = "@tar@";
|
||||
tarFlags = "@tarFlags@";
|
||||
tr = "@tr@";
|
||||
nixBinDir = fromEnv "NIX_BIN_DIR" "@bindir@";
|
||||
nixPrefix = "@prefix@";
|
||||
nixLibexecDir = fromEnv "NIX_LIBEXEC_DIR" "@libexecdir@";
|
||||
nixLocalstateDir = "@localstatedir@";
|
||||
nixSysconfDir = "@sysconfdir@";
|
||||
nixStoreDir = fromEnv "NIX_STORE_DIR" "@storedir@";
|
||||
|
||||
# If Nix is installed in the Nix store, then automatically add it as
|
||||
# a dependency to the core packages. This ensures that they work
|
||||
# properly in a chroot.
|
||||
chrootDeps =
|
||||
if dirOf nixPrefix == builtins.storeDir then
|
||||
[ (builtins.storePath nixPrefix) ]
|
||||
else
|
||||
[ ];
|
||||
}
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
corepkgs_FILES = buildenv.nix unpack-channel.nix derivation.nix fetchurl.nix imported-drv-to-derivation.nix
|
||||
|
||||
$(foreach file,config.nix $(corepkgs_FILES),$(eval $(call install-data-in,$(d)/$(file),$(datadir)/nix/corepkgs)))
|
||||
|
||||
template-files += $(d)/config.nix
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
with import <nix/config.nix>;
|
||||
|
||||
let
|
||||
|
||||
builder = builtins.toFile "unpack-channel.sh"
|
||||
''
|
||||
mkdir $out
|
||||
cd $out
|
||||
xzpat="\.xz\$"
|
||||
gzpat="\.gz\$"
|
||||
if [[ "$src" =~ $xzpat ]]; then
|
||||
${xz} -d < $src | ${tar} xf - ${tarFlags}
|
||||
elif [[ "$src" =~ $gzpat ]]; then
|
||||
${gzip} -d < $src | ${tar} xf - ${tarFlags}
|
||||
else
|
||||
${bzip2} -d < $src | ${tar} xf - ${tarFlags}
|
||||
fi
|
||||
if [ * != $channelName ]; then
|
||||
mv * $out/$channelName
|
||||
fi
|
||||
if [ -n "$binaryCacheURL" ]; then
|
||||
mkdir $out/binary-caches
|
||||
echo -n "$binaryCacheURL" > $out/binary-caches/$channelName
|
||||
fi
|
||||
'';
|
||||
|
||||
in
|
||||
|
||||
{ name, channelName, src, binaryCacheURL ? "" }:
|
||||
|
||||
derivation {
|
||||
system = builtins.currentSystem;
|
||||
builder = shell;
|
||||
args = [ "-e" builder ];
|
||||
inherit name channelName src binaryCacheURL;
|
||||
|
||||
PATH = "${nixBinDir}:${coreutils}";
|
||||
|
||||
# No point in doing this remotely.
|
||||
preferLocalBuild = true;
|
||||
|
||||
inherit chrootDeps;
|
||||
}
|
||||
3
default.nix
Normal file
3
default.nix
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
(import (fetchTarball https://github.com/edolstra/flake-compat/archive/master.tar.gz) {
|
||||
src = ./.;
|
||||
}).defaultNix
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
<part xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="part-advanced-topics"
|
||||
version="5.0">
|
||||
|
||||
<title>Advanced Topics</title>
|
||||
|
||||
<xi:include href="distributed-builds.xml" />
|
||||
|
||||
</part>
|
||||
|
|
@ -1,183 +0,0 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='chap-distributed-builds'>
|
||||
|
||||
<title>Remote Builds</title>
|
||||
|
||||
<para>Nix supports remote builds, where a local Nix installation can
|
||||
forward Nix builds to other machines. This allows multiple builds to
|
||||
be performed in parallel and allows Nix to perform multi-platform
|
||||
builds in a semi-transparent way. For instance, if you perform a
|
||||
build for a <literal>x86_64-darwin</literal> on an
|
||||
<literal>i686-linux</literal> machine, Nix can automatically forward
|
||||
the build to a <literal>x86_64-darwin</literal> machine, if
|
||||
available.</para>
|
||||
|
||||
<para>To forward a build to a remote machine, it’s required that the
|
||||
remote machine is accessible via SSH and that it has Nix
|
||||
installed. You can test whether connecting to the remote Nix instance
|
||||
works, e.g.
|
||||
|
||||
<screen>
|
||||
$ nix ping-store --store ssh://mac
|
||||
</screen>
|
||||
|
||||
will try to connect to the machine named <literal>mac</literal>. It is
|
||||
possible to specify an SSH identity file as part of the remote store
|
||||
URI, e.g.
|
||||
|
||||
<screen>
|
||||
$ nix ping-store --store ssh://mac?ssh-key=/home/alice/my-key
|
||||
</screen>
|
||||
|
||||
Since builds should be non-interactive, the key should not have a
|
||||
passphrase. Alternatively, you can load identities ahead of time into
|
||||
<command>ssh-agent</command> or <command>gpg-agent</command>.</para>
|
||||
|
||||
<para>If you get the error
|
||||
|
||||
<screen>
|
||||
bash: nix-store: command not found
|
||||
error: cannot connect to 'mac'
|
||||
</screen>
|
||||
|
||||
then you need to ensure that the <envar>PATH</envar> of
|
||||
non-interactive login shells contains Nix.</para>
|
||||
|
||||
<warning><para>If you are building via the Nix daemon, it is the Nix
|
||||
daemon user account (that is, <literal>root</literal>) that should
|
||||
have SSH access to the remote machine. If you can’t or don’t want to
|
||||
configure <literal>root</literal> to be able to access to remote
|
||||
machine, you can use a private Nix store instead by passing
|
||||
e.g. <literal>--store ~/my-nix</literal>.</para></warning>
|
||||
|
||||
<para>The list of remote machines can be specified on the command line
|
||||
or in the Nix configuration file. The former is convenient for
|
||||
testing. For example, the following command allows you to build a
|
||||
derivation for <literal>x86_64-darwin</literal> on a Linux machine:
|
||||
|
||||
<screen>
|
||||
$ uname
|
||||
Linux
|
||||
|
||||
$ nix build \
|
||||
'(with import <nixpkgs> { system = "x86_64-darwin"; }; runCommand "foo" {} "uname > $out")' \
|
||||
--builders 'ssh://mac x86_64-darwin'
|
||||
[1/0/1 built, 0.0 MiB DL] building foo on ssh://mac
|
||||
|
||||
$ cat ./result
|
||||
Darwin
|
||||
</screen>
|
||||
|
||||
It is possible to specify multiple builders separated by a semicolon
|
||||
or a newline, e.g.
|
||||
|
||||
<screen>
|
||||
--builders 'ssh://mac x86_64-darwin ; ssh://beastie x86_64-freebsd'
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>Each machine specification consists of the following elements,
|
||||
separated by spaces. Only the first element is required.
|
||||
To leave a field at its default, set it to <literal>-</literal>.
|
||||
|
||||
<orderedlist>
|
||||
|
||||
<listitem><para>The URI of the remote store in the format
|
||||
<literal>ssh://[<replaceable>username</replaceable>@]<replaceable>hostname</replaceable></literal>,
|
||||
e.g. <literal>ssh://nix@mac</literal> or
|
||||
<literal>ssh://mac</literal>. For backward compatibility,
|
||||
<literal>ssh://</literal> may be omitted. The hostname may be an
|
||||
alias defined in your
|
||||
<filename>~/.ssh/config</filename>.</para></listitem>
|
||||
|
||||
<listitem><para>A comma-separated list of Nix platform type
|
||||
identifiers, such as <literal>x86_64-darwin</literal>. It is
|
||||
possible for a machine to support multiple platform types, e.g.,
|
||||
<literal>i686-linux,x86_64-linux</literal>. If omitted, this
|
||||
defaults to the local platform type.</para></listitem>
|
||||
|
||||
<listitem><para>The SSH identity file to be used to log in to the
|
||||
remote machine. If omitted, SSH will use its regular
|
||||
identities.</para></listitem>
|
||||
|
||||
<listitem><para>The maximum number of builds that Nix will execute
|
||||
in parallel on the machine. Typically this should be equal to the
|
||||
number of CPU cores. For instance, the machine
|
||||
<literal>itchy</literal> in the example will execute up to 8 builds
|
||||
in parallel.</para></listitem>
|
||||
|
||||
<listitem><para>The “speed factor”, indicating the relative speed of
|
||||
the machine. If there are multiple machines of the right type, Nix
|
||||
will prefer the fastest, taking load into account.</para></listitem>
|
||||
|
||||
<listitem><para>A comma-separated list of <emphasis>supported
|
||||
features</emphasis>. If a derivation has the
|
||||
<varname>requiredSystemFeatures</varname> attribute, then Nix will
|
||||
only perform the derivation on a machine that has the specified
|
||||
features. For instance, the attribute
|
||||
|
||||
<programlisting>
|
||||
requiredSystemFeatures = [ "kvm" ];
|
||||
</programlisting>
|
||||
|
||||
will cause the build to be performed on a machine that has the
|
||||
<literal>kvm</literal> feature.</para></listitem>
|
||||
|
||||
<listitem><para>A comma-separated list of <emphasis>mandatory
|
||||
features</emphasis>. A machine will only be used to build a
|
||||
derivation if all of the machine’s mandatory features appear in the
|
||||
derivation’s <varname>requiredSystemFeatures</varname>
|
||||
attribute..</para></listitem>
|
||||
|
||||
</orderedlist>
|
||||
|
||||
For example, the machine specification
|
||||
|
||||
<programlisting>
|
||||
nix@scratchy.labs.cs.uu.nl i686-linux /home/nix/.ssh/id_scratchy_auto 8 1 kvm
|
||||
nix@itchy.labs.cs.uu.nl i686-linux /home/nix/.ssh/id_scratchy_auto 8 2
|
||||
nix@poochie.labs.cs.uu.nl i686-linux /home/nix/.ssh/id_scratchy_auto 1 2 kvm benchmark
|
||||
</programlisting>
|
||||
|
||||
specifies several machines that can perform
|
||||
<literal>i686-linux</literal> builds. However,
|
||||
<literal>poochie</literal> will only do builds that have the attribute
|
||||
|
||||
<programlisting>
|
||||
requiredSystemFeatures = [ "benchmark" ];
|
||||
</programlisting>
|
||||
|
||||
or
|
||||
|
||||
<programlisting>
|
||||
requiredSystemFeatures = [ "benchmark" "kvm" ];
|
||||
</programlisting>
|
||||
|
||||
<literal>itchy</literal> cannot do builds that require
|
||||
<literal>kvm</literal>, but <literal>scratchy</literal> does support
|
||||
such builds. For regular builds, <literal>itchy</literal> will be
|
||||
preferred over <literal>scratchy</literal> because it has a higher
|
||||
speed factor.</para>
|
||||
|
||||
<para>Remote builders can also be configured in
|
||||
<filename>nix.conf</filename>, e.g.
|
||||
|
||||
<programlisting>
|
||||
builders = ssh://mac x86_64-darwin ; ssh://beastie x86_64-freebsd
|
||||
</programlisting>
|
||||
|
||||
Finally, remote builders can be configured in a separate configuration
|
||||
file included in <option>builders</option> via the syntax
|
||||
<literal>@<replaceable>file</replaceable></literal>. For example,
|
||||
|
||||
<programlisting>
|
||||
builders = @/etc/nix/machines
|
||||
</programlisting>
|
||||
|
||||
causes the list of machines in <filename>/etc/nix/machines</filename>
|
||||
to be included. (This is the default.)</para>
|
||||
|
||||
</chapter>
|
||||
2
doc/manual/book.toml
Normal file
2
doc/manual/book.toml
Normal file
|
|
@ -0,0 +1,2 @@
|
|||
[output.html]
|
||||
additional-css = ["custom.css"]
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
<part xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='part-command-ref'>
|
||||
|
||||
<title>Command Reference</title>
|
||||
|
||||
<partintro>
|
||||
<para>This section lists commands and options that you can use when you
|
||||
work with Nix.</para>
|
||||
</partintro>
|
||||
|
||||
<xi:include href="opt-common.xml" />
|
||||
<xi:include href="env-common.xml" />
|
||||
<xi:include href="main-commands.xml" />
|
||||
<xi:include href="utilities.xml" />
|
||||
<xi:include href="files.xml" />
|
||||
|
||||
</part>
|
||||
File diff suppressed because it is too large
Load diff
|
|
@ -1,196 +0,0 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-common-env">
|
||||
|
||||
<title>Common Environment Variables</title>
|
||||
|
||||
|
||||
<para>Most Nix commands interpret the following environment variables:</para>
|
||||
|
||||
<variablelist xml:id="env-common">
|
||||
|
||||
<varlistentry><term><envar>IN_NIX_SHELL</envar></term>
|
||||
|
||||
<listitem><para>Indicator that tells if the current environment was set up by
|
||||
<command>nix-shell</command>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry xml:id="env-NIX_PATH"><term><envar>NIX_PATH</envar></term>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para>A colon-separated list of directories used to look up Nix
|
||||
expressions enclosed in angle brackets (i.e.,
|
||||
<literal><<replaceable>path</replaceable>></literal>). For
|
||||
instance, the value
|
||||
|
||||
<screen>
|
||||
/home/eelco/Dev:/etc/nixos</screen>
|
||||
|
||||
will cause Nix to look for paths relative to
|
||||
<filename>/home/eelco/Dev</filename> and
|
||||
<filename>/etc/nixos</filename>, in that order. It is also
|
||||
possible to match paths against a prefix. For example, the value
|
||||
|
||||
<screen>
|
||||
nixpkgs=/home/eelco/Dev/nixpkgs-branch:/etc/nixos</screen>
|
||||
|
||||
will cause Nix to search for
|
||||
<literal><nixpkgs/<replaceable>path</replaceable>></literal> in
|
||||
<filename>/home/eelco/Dev/nixpkgs-branch/<replaceable>path</replaceable></filename>
|
||||
and
|
||||
<filename>/etc/nixos/nixpkgs/<replaceable>path</replaceable></filename>.</para>
|
||||
|
||||
<para>If a path in the Nix search path starts with
|
||||
<literal>http://</literal> or <literal>https://</literal>, it is
|
||||
interpreted as the URL of a tarball that will be downloaded and
|
||||
unpacked to a temporary location. The tarball must consist of a
|
||||
single top-level directory. For example, setting
|
||||
<envar>NIX_PATH</envar> to
|
||||
|
||||
<screen>
|
||||
nixpkgs=https://github.com/NixOS/nixpkgs-channels/archive/nixos-14.12.tar.gz</screen>
|
||||
|
||||
tells Nix to download the latest revision in the Nixpkgs/NixOS
|
||||
14.12 channel.</para>
|
||||
|
||||
<para>The search path can be extended using the <option
|
||||
linkend="opt-I">-I</option> option, which takes precedence over
|
||||
<envar>NIX_PATH</envar>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_IGNORE_SYMLINK_STORE</envar></term>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para>Normally, the Nix store directory (typically
|
||||
<filename>/nix/store</filename>) is not allowed to contain any
|
||||
symlink components. This is to prevent “impure” builds. Builders
|
||||
sometimes “canonicalise” paths by resolving all symlink components.
|
||||
Thus, builds on different machines (with
|
||||
<filename>/nix/store</filename> resolving to different locations)
|
||||
could yield different results. This is generally not a problem,
|
||||
except when builds are deployed to machines where
|
||||
<filename>/nix/store</filename> resolves differently. If you are
|
||||
sure that you’re not going to do that, you can set
|
||||
<envar>NIX_IGNORE_SYMLINK_STORE</envar> to <envar>1</envar>.</para>
|
||||
|
||||
<para>Note that if you’re symlinking the Nix store so that you can
|
||||
put it on another file system than the root file system, on Linux
|
||||
you’re better off using <literal>bind</literal> mount points, e.g.,
|
||||
|
||||
<screen>
|
||||
$ mkdir /nix
|
||||
$ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
||||
|
||||
Consult the <citerefentry><refentrytitle>mount</refentrytitle>
|
||||
<manvolnum>8</manvolnum></citerefentry> manual page for details.</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_STORE_DIR</envar></term>
|
||||
|
||||
<listitem><para>Overrides the location of the Nix store (default
|
||||
<filename><replaceable>prefix</replaceable>/store</filename>).</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_DATA_DIR</envar></term>
|
||||
|
||||
<listitem><para>Overrides the location of the Nix static data
|
||||
directory (default
|
||||
<filename><replaceable>prefix</replaceable>/share</filename>).</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_LOG_DIR</envar></term>
|
||||
|
||||
<listitem><para>Overrides the location of the Nix log directory
|
||||
(default <filename><replaceable>prefix</replaceable>/log/nix</filename>).</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_STATE_DIR</envar></term>
|
||||
|
||||
<listitem><para>Overrides the location of the Nix state directory
|
||||
(default <filename><replaceable>prefix</replaceable>/var/nix</filename>).</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_CONF_DIR</envar></term>
|
||||
|
||||
<listitem><para>Overrides the location of the Nix configuration
|
||||
directory (default
|
||||
<filename><replaceable>prefix</replaceable>/etc/nix</filename>).</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>TMPDIR</envar></term>
|
||||
|
||||
<listitem><para>Use the specified directory to store temporary
|
||||
files. In particular, this includes temporary build directories;
|
||||
these can take up substantial amounts of disk space. The default is
|
||||
<filename>/tmp</filename>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="envar-remote"><term><envar>NIX_REMOTE</envar></term>
|
||||
|
||||
<listitem><para>This variable should be set to
|
||||
<literal>daemon</literal> if you want to use the Nix daemon to
|
||||
execute Nix operations. This is necessary in <link
|
||||
linkend="ssec-multi-user">multi-user Nix installations</link>.
|
||||
If the Nix daemon's Unix socket is at some non-standard path,
|
||||
this variable should be set to <literal>unix://path/to/socket</literal>.
|
||||
Otherwise, it should be left unset.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_SHOW_STATS</envar></term>
|
||||
|
||||
<listitem><para>If set to <literal>1</literal>, Nix will print some
|
||||
evaluation statistics, such as the number of values
|
||||
allocated.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_COUNT_CALLS</envar></term>
|
||||
|
||||
<listitem><para>If set to <literal>1</literal>, Nix will print how
|
||||
often functions were called during Nix expression evaluation. This
|
||||
is useful for profiling your Nix expressions.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>GC_INITIAL_HEAP_SIZE</envar></term>
|
||||
|
||||
<listitem><para>If Nix has been configured to use the Boehm garbage
|
||||
collector, this variable sets the initial size of the heap in bytes.
|
||||
It defaults to 384 MiB. Setting it to a low value reduces memory
|
||||
consumption, but will increase runtime due to the overhead of
|
||||
garbage collection.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
</variablelist>
|
||||
|
||||
|
||||
</chapter>
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='ch-files'>
|
||||
|
||||
<title>Files</title>
|
||||
|
||||
<para>This section lists configuration files that you can use when you
|
||||
work with Nix.</para>
|
||||
|
||||
<xi:include href="conf-file.xml" />
|
||||
|
||||
</chapter>
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='ch-main-commands'>
|
||||
|
||||
<title>Main Commands</title>
|
||||
|
||||
<para>This section lists commands and options that you can use when you
|
||||
work with Nix.</para>
|
||||
|
||||
<xi:include href="nix-env.xml" />
|
||||
<xi:include href="nix-build.xml" />
|
||||
<xi:include href="nix-shell.xml" />
|
||||
<xi:include href="nix-store.xml" />
|
||||
|
||||
</chapter>
|
||||
|
|
@ -1,185 +0,0 @@
|
|||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-build">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-build</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>nix-build</refname>
|
||||
<refpurpose>build a Nix expression</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<cmdsynopsis>
|
||||
<command>nix-build</command>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="opt-common-syn.xml#xmlns(db=http://docbook.org/ns/docbook)xpointer(/db:nop/*)" />
|
||||
<arg><option>--arg</option> <replaceable>name</replaceable> <replaceable>value</replaceable></arg>
|
||||
<arg><option>--argstr</option> <replaceable>name</replaceable> <replaceable>value</replaceable></arg>
|
||||
<arg>
|
||||
<group choice='req'>
|
||||
<arg choice='plain'><option>--attr</option></arg>
|
||||
<arg choice='plain'><option>-A</option></arg>
|
||||
</group>
|
||||
<replaceable>attrPath</replaceable>
|
||||
</arg>
|
||||
<arg><option>--no-out-link</option></arg>
|
||||
<arg>
|
||||
<group choice='req'>
|
||||
<arg choice='plain'><option>--out-link</option></arg>
|
||||
<arg choice='plain'><option>-o</option></arg>
|
||||
</group>
|
||||
<replaceable>outlink</replaceable>
|
||||
</arg>
|
||||
<arg choice='plain' rep='repeat'><replaceable>paths</replaceable></arg>
|
||||
</cmdsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
<para>The <command>nix-build</command> command builds the derivations
|
||||
described by the Nix expressions in <replaceable>paths</replaceable>.
|
||||
If the build succeeds, it places a symlink to the result in the
|
||||
current directory. The symlink is called <filename>result</filename>.
|
||||
If there are multiple Nix expressions, or the Nix expressions evaluate
|
||||
to multiple derivations, multiple sequentially numbered symlinks are
|
||||
created (<filename>result</filename>, <filename>result-2</filename>,
|
||||
and so on).</para>
|
||||
|
||||
<para>If no <replaceable>paths</replaceable> are specified, then
|
||||
<command>nix-build</command> will use <filename>default.nix</filename>
|
||||
in the current directory, if it exists.</para>
|
||||
|
||||
<para>If an element of <replaceable>paths</replaceable> starts with
|
||||
<literal>http://</literal> or <literal>https://</literal>, it is
|
||||
interpreted as the URL of a tarball that will be downloaded and
|
||||
unpacked to a temporary location. The tarball must include a single
|
||||
top-level directory containing at least a file named
|
||||
<filename>default.nix</filename>.</para>
|
||||
|
||||
<para><command>nix-build</command> is essentially a wrapper around
|
||||
<link
|
||||
linkend="sec-nix-instantiate"><command>nix-instantiate</command></link>
|
||||
(to translate a high-level Nix expression to a low-level store
|
||||
derivation) and <link
|
||||
linkend="rsec-nix-store-realise"><command>nix-store
|
||||
--realise</command></link> (to build the store derivation).</para>
|
||||
|
||||
<warning><para>The result of the build is automatically registered as
|
||||
a root of the Nix garbage collector. This root disappears
|
||||
automatically when the <filename>result</filename> symlink is deleted
|
||||
or renamed. So don’t rename the symlink.</para></warning>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Options</title>
|
||||
|
||||
<para>All options not listed here are passed to <command>nix-store
|
||||
--realise</command>, except for <option>--arg</option> and
|
||||
<option>--attr</option> / <option>-A</option> which are passed to
|
||||
<command>nix-instantiate</command>. <phrase condition="manual">See
|
||||
also <xref linkend="sec-common-options" />.</phrase></para>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><option>--no-out-link</option></term>
|
||||
|
||||
<listitem><para>Do not create a symlink to the output path. Note
|
||||
that as a result the output does not become a root of the garbage
|
||||
collector, and so might be deleted by <command>nix-store
|
||||
--gc</command>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry xml:id='opt-out-link'><term><option>--out-link</option> /
|
||||
<option>-o</option> <replaceable>outlink</replaceable></term>
|
||||
|
||||
<listitem><para>Change the name of the symlink to the output path
|
||||
created from <filename>result</filename> to
|
||||
<replaceable>outlink</replaceable>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
<para>The following common options are supported:</para>
|
||||
|
||||
<variablelist condition="manpage">
|
||||
<xi:include href="opt-common.xml#xmlns(db=http://docbook.org/ns/docbook)xpointer(//db:variablelist[@xml:id='opt-common']/*)" />
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Examples</title>
|
||||
|
||||
<screen>
|
||||
$ nix-build '<nixpkgs>' -A firefox
|
||||
store derivation is /nix/store/qybprl8sz2lc...-firefox-1.5.0.7.drv
|
||||
/nix/store/d18hyl92g30l...-firefox-1.5.0.7
|
||||
|
||||
$ ls -l result
|
||||
lrwxrwxrwx <replaceable>...</replaceable> result -> /nix/store/d18hyl92g30l...-firefox-1.5.0.7
|
||||
|
||||
$ ls ./result/bin/
|
||||
firefox firefox-config</screen>
|
||||
|
||||
<para>If a derivation has multiple outputs,
|
||||
<command>nix-build</command> will build the default (first) output.
|
||||
You can also build all outputs:
|
||||
<screen>
|
||||
$ nix-build '<nixpkgs>' -A openssl.all
|
||||
</screen>
|
||||
This will create a symlink for each output named
|
||||
<filename>result-<replaceable>outputname</replaceable></filename>.
|
||||
The suffix is omitted if the output name is <literal>out</literal>.
|
||||
So if <literal>openssl</literal> has outputs <literal>out</literal>,
|
||||
<literal>bin</literal> and <literal>man</literal>,
|
||||
<command>nix-build</command> will create symlinks
|
||||
<literal>result</literal>, <literal>result-bin</literal> and
|
||||
<literal>result-man</literal>. It’s also possible to build a specific
|
||||
output:
|
||||
<screen>
|
||||
$ nix-build '<nixpkgs>' -A openssl.man
|
||||
</screen>
|
||||
This will create a symlink <literal>result-man</literal>.</para>
|
||||
|
||||
<para>Build a Nix expression given on the command line:
|
||||
|
||||
<screen>
|
||||
$ nix-build -E 'with import <nixpkgs> { }; runCommand "foo" { } "echo bar > $out"'
|
||||
$ cat ./result
|
||||
bar
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Build the GNU Hello package from the latest revision of the
|
||||
master branch of Nixpkgs:
|
||||
|
||||
<screen>
|
||||
$ nix-build https://github.com/NixOS/nixpkgs/archive/master.tar.gz -A hello
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection condition="manpage"><title>Environment variables</title>
|
||||
|
||||
<variablelist>
|
||||
<xi:include href="env-common.xml#xmlns(db=http://docbook.org/ns/docbook)xpointer(//db:variablelist[@xml:id='env-common']/*)" />
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
</refentry>
|
||||
|
|
@ -1,191 +0,0 @@
|
|||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-channel">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-channel</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>nix-channel</refname>
|
||||
<refpurpose>manage Nix channels</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<cmdsynopsis>
|
||||
<command>nix-channel</command>
|
||||
<group choice='req'>
|
||||
<arg choice='plain'><option>--add</option> <replaceable>url</replaceable> <arg choice='opt'><replaceable>name</replaceable></arg></arg>
|
||||
<arg choice='plain'><option>--remove</option> <replaceable>name</replaceable></arg>
|
||||
<arg choice='plain'><option>--list</option></arg>
|
||||
<arg choice='plain'><option>--update</option> <arg rep='repeat'><replaceable>names</replaceable></arg></arg>
|
||||
<arg choice='plain'><option>--rollback</option> <arg choice='opt'><replaceable>generation</replaceable></arg></arg>
|
||||
</group>
|
||||
</cmdsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
<para>A Nix channel is a mechanism that allows you to automatically stay
|
||||
up-to-date with a set of pre-built Nix expressions. A Nix channel is
|
||||
just a URL that points to a place containing both a set of Nix
|
||||
expressions and a pointer to a binary cache. <phrase
|
||||
condition="manual">See also <xref linkend="sec-channels"
|
||||
/>.</phrase></para>
|
||||
|
||||
<para>This command has the following operations:
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><option>--add</option> <replaceable>url</replaceable> [<replaceable>name</replaceable>]</term>
|
||||
|
||||
<listitem><para>Adds a channel named
|
||||
<replaceable>name</replaceable> with URL
|
||||
<replaceable>url</replaceable> to the list of subscribed channels.
|
||||
If <replaceable>name</replaceable> is omitted, it defaults to the
|
||||
last component of <replaceable>url</replaceable>, with the
|
||||
suffixes <literal>-stable</literal> or
|
||||
<literal>-unstable</literal> removed.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--remove</option> <replaceable>name</replaceable></term>
|
||||
|
||||
<listitem><para>Removes the channel named
|
||||
<replaceable>name</replaceable> from the list of subscribed
|
||||
channels.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--list</option></term>
|
||||
|
||||
<listitem><para>Prints the names and URLs of all subscribed
|
||||
channels on standard output.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--update</option> [<replaceable>names</replaceable>…]</term>
|
||||
|
||||
<listitem><para>Downloads the Nix expressions of all subscribed
|
||||
channels (or only those included in
|
||||
<replaceable>names</replaceable> if specified) and makes them the
|
||||
default for <command>nix-env</command> operations (by symlinking
|
||||
them from the directory
|
||||
<filename>~/.nix-defexpr</filename>).</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--rollback</option> [<replaceable>generation</replaceable>]</term>
|
||||
|
||||
<listitem><para>Reverts the previous call to <command>nix-channel
|
||||
--update</command>. Optionally, you can specify a specific channel
|
||||
generation number to restore.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Note that <option>--add</option> does not automatically perform
|
||||
an update.</para>
|
||||
|
||||
<para>The list of subscribed channels is stored in
|
||||
<filename>~/.nix-channels</filename>.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Examples</title>
|
||||
|
||||
<para>To subscribe to the Nixpkgs channel and install the GNU Hello package:</para>
|
||||
|
||||
<screen>
|
||||
$ nix-channel --add https://nixos.org/channels/nixpkgs-unstable
|
||||
$ nix-channel --update
|
||||
$ nix-env -iA nixpkgs.hello</screen>
|
||||
|
||||
<para>You can revert channel updates using <option>--rollback</option>:</para>
|
||||
|
||||
<screen>
|
||||
$ nix-instantiate --eval -E '(import <nixpkgs> {}).lib.nixpkgsVersion'
|
||||
"14.04.527.0e935f1"
|
||||
|
||||
$ nix-channel --rollback
|
||||
switching from generation 483 to 482
|
||||
|
||||
$ nix-instantiate --eval -E '(import <nixpkgs> {}).lib.nixpkgsVersion'
|
||||
"14.04.526.dbadfad"
|
||||
</screen>
|
||||
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Files</title>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><filename>/nix/var/nix/profiles/per-user/<replaceable>username</replaceable>/channels</filename></term>
|
||||
|
||||
<listitem><para><command>nix-channel</command> uses a
|
||||
<command>nix-env</command> profile to keep track of previous
|
||||
versions of the subscribed channels. Every time you run
|
||||
<command>nix-channel --update</command>, a new channel generation
|
||||
(that is, a symlink to the channel Nix expressions in the Nix store)
|
||||
is created. This enables <command>nix-channel --rollback</command>
|
||||
to revert to previous versions.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><filename>~/.nix-defexpr/channels</filename></term>
|
||||
|
||||
<listitem><para>This is a symlink to
|
||||
<filename>/nix/var/nix/profiles/per-user/<replaceable>username</replaceable>/channels</filename>. It
|
||||
ensures that <command>nix-env</command> can find your channels. In
|
||||
a multi-user installation, you may also have
|
||||
<filename>~/.nix-defexpr/channels_root</filename>, which links to
|
||||
the channels of the root user.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Channel format</title>
|
||||
|
||||
<para>A channel URL should point to a directory containing the
|
||||
following files:</para>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><filename>nixexprs.tar.xz</filename></term>
|
||||
|
||||
<listitem><para>A tarball containing Nix expressions and files
|
||||
referenced by them (such as build scripts and patches). At the
|
||||
top level, the tarball should contain a single directory. That
|
||||
directory must contain a file <filename>default.nix</filename>
|
||||
that serves as the channel’s “entry point”.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><filename>binary-cache-url</filename></term>
|
||||
|
||||
<listitem><para>A file containing the URL to a binary cache (such
|
||||
as <uri>https://cache.nixos.org</uri>). Nix will automatically
|
||||
check this cache for pre-built binaries, if the user has
|
||||
sufficient rights to add binary caches. For instance, in a
|
||||
multi-user Nix setup, the binary caches provided by the channels
|
||||
of the root user are used automatically, but caches corresponding
|
||||
to the channels of non-root users are ignored.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
</refentry>
|
||||
|
|
@ -1,63 +0,0 @@
|
|||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-collect-garbage">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-collect-garbage</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>nix-collect-garbage</refname>
|
||||
<refpurpose>delete unreachable store paths</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<cmdsynopsis>
|
||||
<command>nix-collect-garbage</command>
|
||||
<arg><option>--delete-old</option></arg>
|
||||
<arg><option>-d</option></arg>
|
||||
<arg><option>--delete-older-than</option> <replaceable>period</replaceable></arg>
|
||||
<arg><option>--max-freed</option> <replaceable>bytes</replaceable></arg>
|
||||
<arg><option>--dry-run</option></arg>
|
||||
</cmdsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
<para>The command <command>nix-collect-garbage</command> is mostly an
|
||||
alias of <link linkend="rsec-nix-store-gc"><command>nix-store
|
||||
--gc</command></link>, that is, it deletes all unreachable paths in
|
||||
the Nix store to clean up your system. However, it provides two
|
||||
additional options: <option>-d</option> (<option>--delete-old</option>),
|
||||
which deletes all old generations of all profiles in
|
||||
<filename>/nix/var/nix/profiles</filename> by invoking
|
||||
<literal>nix-env --delete-generations old</literal> on all profiles
|
||||
(of course, this makes rollbacks to previous configurations
|
||||
impossible); and
|
||||
<option>--delete-older-than</option> <replaceable>period</replaceable>,
|
||||
where period is a value such as <literal>30d</literal>, which deletes
|
||||
all generations older than the specified number of days in all profiles
|
||||
in <filename>/nix/var/nix/profiles</filename> (except for the generations
|
||||
that were active at that point in time).
|
||||
</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Example</title>
|
||||
|
||||
<para>To delete from the Nix store everything that is not used by the
|
||||
current generations of each profile, do
|
||||
|
||||
<screen>
|
||||
$ nix-collect-garbage -d</screen>
|
||||
|
||||
</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
</refentry>
|
||||
|
|
@ -1,169 +0,0 @@
|
|||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-nix-copy-closure">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-copy-closure</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>nix-copy-closure</refname>
|
||||
<refpurpose>copy a closure to or from a remote machine via SSH</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<cmdsynopsis>
|
||||
<command>nix-copy-closure</command>
|
||||
<group>
|
||||
<arg choice='plain'><option>--to</option></arg>
|
||||
<arg choice='plain'><option>--from</option></arg>
|
||||
</group>
|
||||
<arg><option>--gzip</option></arg>
|
||||
<!--
|
||||
<arg><option>- -show-progress</option></arg>
|
||||
-->
|
||||
<arg><option>--include-outputs</option></arg>
|
||||
<group>
|
||||
<arg choice='plain'><option>--use-substitutes</option></arg>
|
||||
<arg choice='plain'><option>-s</option></arg>
|
||||
</group>
|
||||
<arg><option>-v</option></arg>
|
||||
<arg choice='plain'>
|
||||
<replaceable>user@</replaceable><replaceable>machine</replaceable>
|
||||
</arg>
|
||||
<arg choice='plain'><replaceable>paths</replaceable></arg>
|
||||
</cmdsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
<para><command>nix-copy-closure</command> gives you an easy and
|
||||
efficient way to exchange software between machines. Given one or
|
||||
more Nix store <replaceable>paths</replaceable> on the local
|
||||
machine, <command>nix-copy-closure</command> computes the closure of
|
||||
those paths (i.e. all their dependencies in the Nix store), and copies
|
||||
all paths in the closure to the remote machine via the
|
||||
<command>ssh</command> (Secure Shell) command. With the
|
||||
<option>--from</option>, the direction is reversed:
|
||||
the closure of <replaceable>paths</replaceable> on a remote machine is
|
||||
copied to the Nix store on the local machine.</para>
|
||||
|
||||
<para>This command is efficient because it only sends the store paths
|
||||
that are missing on the target machine.</para>
|
||||
|
||||
<para>Since <command>nix-copy-closure</command> calls
|
||||
<command>ssh</command>, you may be asked to type in the appropriate
|
||||
password or passphrase. In fact, you may be asked
|
||||
<emphasis>twice</emphasis> because <command>nix-copy-closure</command>
|
||||
currently connects twice to the remote machine, first to get the set
|
||||
of paths missing on the target machine, and second to send the dump of
|
||||
those paths. If this bothers you, use
|
||||
<command>ssh-agent</command>.</para>
|
||||
|
||||
|
||||
<refsection><title>Options</title>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><option>--to</option></term>
|
||||
|
||||
<listitem><para>Copy the closure of
|
||||
<replaceable>paths</replaceable> from the local Nix store to the
|
||||
Nix store on <replaceable>machine</replaceable>. This is the
|
||||
default.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--from</option></term>
|
||||
|
||||
<listitem><para>Copy the closure of
|
||||
<replaceable>paths</replaceable> from the Nix store on
|
||||
<replaceable>machine</replaceable> to the local Nix
|
||||
store.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--gzip</option></term>
|
||||
|
||||
<listitem><para>Enable compression of the SSH
|
||||
connection.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--include-outputs</option></term>
|
||||
|
||||
<listitem><para>Also copy the outputs of store derivations
|
||||
included in the closure.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--use-substitutes</option> / <option>-s</option></term>
|
||||
|
||||
<listitem><para>Attempt to download missing paths on the target
|
||||
machine using Nix’s substitute mechanism. Any paths that cannot
|
||||
be substituted on the target are still copied normally from the
|
||||
source. This is useful, for instance, if the connection between
|
||||
the source and target machine is slow, but the connection between
|
||||
the target machine and <literal>nixos.org</literal> (the default
|
||||
binary cache server) is fast.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>-v</option></term>
|
||||
|
||||
<listitem><para>Show verbose output.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Environment variables</title>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><envar>NIX_SSHOPTS</envar></term>
|
||||
|
||||
<listitem><para>Additional options to be passed to
|
||||
<command>ssh</command> on the command line.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Examples</title>
|
||||
|
||||
<para>Copy Firefox with all its dependencies to a remote machine:
|
||||
|
||||
<screen>
|
||||
$ nix-copy-closure --to alice@itchy.labs $(type -tP firefox)</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Copy Subversion from a remote machine and then install it into a
|
||||
user environment:
|
||||
|
||||
<screen>
|
||||
$ nix-copy-closure --from alice@itchy.labs \
|
||||
/nix/store/0dj0503hjxy5mbwlafv1rsbdiyx1gkdy-subversion-1.4.4
|
||||
$ nix-env -i /nix/store/0dj0503hjxy5mbwlafv1rsbdiyx1gkdy-subversion-1.4.4
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
</refsection>
|
||||
|
||||
</refentry>
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-daemon">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-daemon</refentrytitle>
|
||||
<manvolnum>8</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>nix-daemon</refname>
|
||||
<refpurpose>Nix multi-user support daemon</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<cmdsynopsis>
|
||||
<command>nix-daemon</command>
|
||||
</cmdsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
<para>The Nix daemon is necessary in multi-user Nix installations. It
|
||||
performs build actions and other operations on the Nix store on behalf
|
||||
of unprivileged users.</para>
|
||||
|
||||
|
||||
</refsection>
|
||||
|
||||
</refentry>
|
||||
File diff suppressed because it is too large
Load diff
|
|
@ -1,176 +0,0 @@
|
|||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-hash">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-hash</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>nix-hash</refname>
|
||||
<refpurpose>compute the cryptographic hash of a path</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<cmdsynopsis>
|
||||
<command>nix-hash</command>
|
||||
<arg><option>--flat</option></arg>
|
||||
<arg><option>--base32</option></arg>
|
||||
<arg><option>--truncate</option></arg>
|
||||
<arg><option>--type</option> <replaceable>hashAlgo</replaceable></arg>
|
||||
<arg choice='plain' rep='repeat'><replaceable>path</replaceable></arg>
|
||||
</cmdsynopsis>
|
||||
<cmdsynopsis>
|
||||
<command>nix-hash</command>
|
||||
<arg choice='plain'><option>--to-base16</option></arg>
|
||||
<arg choice='plain' rep='repeat'><replaceable>hash</replaceable></arg>
|
||||
</cmdsynopsis>
|
||||
<cmdsynopsis>
|
||||
<command>nix-hash</command>
|
||||
<arg choice='plain'><option>--to-base32</option></arg>
|
||||
<arg choice='plain' rep='repeat'><replaceable>hash</replaceable></arg>
|
||||
</cmdsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
<para>The command <command>nix-hash</command> computes the
|
||||
cryptographic hash of the contents of each
|
||||
<replaceable>path</replaceable> and prints it on standard output. By
|
||||
default, it computes an MD5 hash, but other hash algorithms are
|
||||
available as well. The hash is printed in hexadecimal. To generate
|
||||
the same hash as <command>nix-prefetch-url</command> you have to
|
||||
specify multiple arguments, see below for an example.</para>
|
||||
|
||||
<para>The hash is computed over a <emphasis>serialisation</emphasis>
|
||||
of each path: a dump of the file system tree rooted at the path. This
|
||||
allows directories and symlinks to be hashed as well as regular files.
|
||||
The dump is in the <emphasis>NAR format</emphasis> produced by <link
|
||||
linkend="refsec-nix-store-dump"><command>nix-store</command>
|
||||
<option>--dump</option></link>. Thus, <literal>nix-hash
|
||||
<replaceable>path</replaceable></literal> yields the same
|
||||
cryptographic hash as <literal>nix-store --dump
|
||||
<replaceable>path</replaceable> | md5sum</literal>.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Options</title>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><option>--flat</option></term>
|
||||
|
||||
<listitem><para>Print the cryptographic hash of the contents of
|
||||
each regular file <replaceable>path</replaceable>. That is, do
|
||||
not compute the hash over the dump of
|
||||
<replaceable>path</replaceable>. The result is identical to that
|
||||
produced by the GNU commands <command>md5sum</command> and
|
||||
<command>sha1sum</command>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--base32</option></term>
|
||||
|
||||
<listitem><para>Print the hash in a base-32 representation rather
|
||||
than hexadecimal. This base-32 representation is more compact and
|
||||
can be used in Nix expressions (such as in calls to
|
||||
<function>fetchurl</function>).</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--truncate</option></term>
|
||||
|
||||
<listitem><para>Truncate hashes longer than 160 bits (such as
|
||||
SHA-256) to 160 bits.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--type</option> <replaceable>hashAlgo</replaceable></term>
|
||||
|
||||
<listitem><para>Use the specified cryptographic hash algorithm,
|
||||
which can be one of <literal>md5</literal>,
|
||||
<literal>sha1</literal>, and
|
||||
<literal>sha256</literal>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--to-base16</option></term>
|
||||
|
||||
<listitem><para>Don’t hash anything, but convert the base-32 hash
|
||||
representation <replaceable>hash</replaceable> to
|
||||
hexadecimal.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--to-base32</option></term>
|
||||
|
||||
<listitem><para>Don’t hash anything, but convert the hexadecimal
|
||||
hash representation <replaceable>hash</replaceable> to
|
||||
base-32.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Examples</title>
|
||||
|
||||
<para>Computing the same hash as <command>nix-prefetch-url</command>:
|
||||
<screen>
|
||||
$ nix-prefetch-url file://<(echo test)
|
||||
1lkgqb6fclns49861dwk9rzb6xnfkxbpws74mxnx01z9qyv1pjpj
|
||||
$ nix-hash --type sha256 --flat --base32 <(echo test)
|
||||
1lkgqb6fclns49861dwk9rzb6xnfkxbpws74mxnx01z9qyv1pjpj
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>Computing hashes:
|
||||
|
||||
<screen>
|
||||
$ mkdir test
|
||||
$ echo "hello" > test/world
|
||||
|
||||
$ nix-hash test/ <lineannotation>(MD5 hash; default)</lineannotation>
|
||||
8179d3caeff1869b5ba1744e5a245c04
|
||||
|
||||
$ nix-store --dump test/ | md5sum <lineannotation>(for comparison)</lineannotation>
|
||||
8179d3caeff1869b5ba1744e5a245c04 -
|
||||
|
||||
$ nix-hash --type sha1 test/
|
||||
e4fd8ba5f7bbeaea5ace89fe10255536cd60dab6
|
||||
|
||||
$ nix-hash --type sha1 --base32 test/
|
||||
nvd61k9nalji1zl9rrdfmsmvyyjqpzg4
|
||||
|
||||
$ nix-hash --type sha256 --flat test/
|
||||
error: reading file `test/': Is a directory
|
||||
|
||||
$ nix-hash --type sha256 --flat test/world
|
||||
5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Converting between hexadecimal and base-32:
|
||||
|
||||
<screen>
|
||||
$ nix-hash --type sha1 --to-base32 e4fd8ba5f7bbeaea5ace89fe10255536cd60dab6
|
||||
nvd61k9nalji1zl9rrdfmsmvyyjqpzg4
|
||||
|
||||
$ nix-hash --type sha1 --to-base16 nvd61k9nalji1zl9rrdfmsmvyyjqpzg4
|
||||
e4fd8ba5f7bbeaea5ace89fe10255536cd60dab6</screen>
|
||||
|
||||
</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
</refentry>
|
||||
|
|
@ -1,266 +0,0 @@
|
|||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-instantiate">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-instantiate</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>nix-instantiate</refname>
|
||||
<refpurpose>instantiate store derivations from Nix expressions</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<cmdsynopsis>
|
||||
<command>nix-instantiate</command>
|
||||
<group>
|
||||
<arg choice='plain'><option>--parse</option></arg>
|
||||
<arg choice='plain'>
|
||||
<option>--eval</option>
|
||||
<arg><option>--strict</option></arg>
|
||||
<arg><option>--json</option></arg>
|
||||
<arg><option>--xml</option></arg>
|
||||
</arg>
|
||||
</group>
|
||||
<arg><option>--read-write-mode</option></arg>
|
||||
<arg><option>--arg</option> <replaceable>name</replaceable> <replaceable>value</replaceable></arg>
|
||||
<arg>
|
||||
<group choice='req'>
|
||||
<arg choice='plain'><option>--attr</option></arg>
|
||||
<arg choice='plain'><option>-A</option></arg>
|
||||
</group>
|
||||
<replaceable>attrPath</replaceable>
|
||||
</arg>
|
||||
<arg><option>--add-root</option> <replaceable>path</replaceable></arg>
|
||||
<arg><option>--indirect</option></arg>
|
||||
<group>
|
||||
<arg choice='plain'><option>--expr</option></arg>
|
||||
<arg choice='plain'><option>-E</option></arg>
|
||||
</group>
|
||||
<arg choice='plain' rep='repeat'><replaceable>files</replaceable></arg>
|
||||
</cmdsynopsis>
|
||||
<cmdsynopsis>
|
||||
<command>nix-instantiate</command>
|
||||
<arg choice='plain'><option>--find-file</option></arg>
|
||||
<arg choice='plain' rep='repeat'><replaceable>files</replaceable></arg>
|
||||
</cmdsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
<para>The command <command>nix-instantiate</command> generates <link
|
||||
linkend="gloss-derivation">store derivations</link> from (high-level)
|
||||
Nix expressions. It evaluates the Nix expressions in each of
|
||||
<replaceable>files</replaceable> (which defaults to
|
||||
<replaceable>./default.nix</replaceable>). Each top-level expression
|
||||
should evaluate to a derivation, a list of derivations, or a set of
|
||||
derivations. The paths of the resulting store derivations are printed
|
||||
on standard output.</para>
|
||||
|
||||
<para>If <replaceable>files</replaceable> is the character
|
||||
<literal>-</literal>, then a Nix expression will be read from standard
|
||||
input.</para>
|
||||
|
||||
<para condition="manual">See also <xref linkend="sec-common-options"
|
||||
/> for a list of common options.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Options</title>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>--add-root</option> <replaceable>path</replaceable></term>
|
||||
<term><option>--indirect</option></term>
|
||||
|
||||
<listitem><para>See the <link linkend="opt-add-root">corresponding
|
||||
options</link> in <command>nix-store</command>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--parse</option></term>
|
||||
|
||||
<listitem><para>Just parse the input files, and print their
|
||||
abstract syntax trees on standard output in ATerm
|
||||
format.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--eval</option></term>
|
||||
|
||||
<listitem><para>Just parse and evaluate the input files, and print
|
||||
the resulting values on standard output. No instantiation of
|
||||
store derivations takes place.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--find-file</option></term>
|
||||
|
||||
<listitem><para>Look up the given files in Nix’s search path (as
|
||||
specified by the <envar linkend="env-NIX_PATH">NIX_PATH</envar>
|
||||
environment variable). If found, print the corresponding absolute
|
||||
paths on standard output. For instance, if
|
||||
<envar>NIX_PATH</envar> is
|
||||
<literal>nixpkgs=/home/alice/nixpkgs</literal>, then
|
||||
<literal>nix-instantiate --find-file nixpkgs/default.nix</literal>
|
||||
will print
|
||||
<literal>/home/alice/nixpkgs/default.nix</literal>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--strict</option></term>
|
||||
|
||||
<listitem><para>When used with <option>--eval</option>,
|
||||
recursively evaluate list elements and attributes. Normally, such
|
||||
sub-expressions are left unevaluated (since the Nix expression
|
||||
language is lazy).</para>
|
||||
|
||||
<warning><para>This option can cause non-termination, because lazy
|
||||
data structures can be infinitely large.</para></warning>
|
||||
|
||||
</listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--json</option></term>
|
||||
|
||||
<listitem><para>When used with <option>--eval</option>, print the resulting
|
||||
value as an JSON representation of the abstract syntax tree rather
|
||||
than as an ATerm.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--xml</option></term>
|
||||
|
||||
<listitem><para>When used with <option>--eval</option>, print the resulting
|
||||
value as an XML representation of the abstract syntax tree rather than as
|
||||
an ATerm. The schema is the same as that used by the <link
|
||||
linkend="builtin-toXML"><function>toXML</function> built-in</link>.
|
||||
</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--read-write-mode</option></term>
|
||||
|
||||
<listitem><para>When used with <option>--eval</option>, perform
|
||||
evaluation in read/write mode so nix language features that
|
||||
require it will still work (at the cost of needing to do
|
||||
instantiation of every evaluated derivation). If this option is
|
||||
not enabled, there may be uninstantiated store paths in the final
|
||||
output.</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
<variablelist condition="manpage">
|
||||
<xi:include href="opt-common.xml#xmlns(db=http://docbook.org/ns/docbook)xpointer(//db:variablelist[@xml:id='opt-common']/*)" />
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Examples</title>
|
||||
|
||||
<para>Instantiating store derivations from a Nix expression, and
|
||||
building them using <command>nix-store</command>:
|
||||
|
||||
<screen>
|
||||
$ nix-instantiate test.nix <lineannotation>(instantiate)</lineannotation>
|
||||
/nix/store/cigxbmvy6dzix98dxxh9b6shg7ar5bvs-perl-BerkeleyDB-0.26.drv
|
||||
|
||||
$ nix-store -r $(nix-instantiate test.nix) <lineannotation>(build)</lineannotation>
|
||||
<replaceable>...</replaceable>
|
||||
/nix/store/qhqk4n8ci095g3sdp93x7rgwyh9rdvgk-perl-BerkeleyDB-0.26 <lineannotation>(output path)</lineannotation>
|
||||
|
||||
$ ls -l /nix/store/qhqk4n8ci095g3sdp93x7rgwyh9rdvgk-perl-BerkeleyDB-0.26
|
||||
dr-xr-xr-x 2 eelco users 4096 1970-01-01 01:00 lib
|
||||
...</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>You can also give a Nix expression on the command line:
|
||||
|
||||
<screen>
|
||||
$ nix-instantiate -E 'with import <nixpkgs> { }; hello'
|
||||
/nix/store/j8s4zyv75a724q38cb0r87rlczaiag4y-hello-2.8.drv
|
||||
</screen>
|
||||
|
||||
This is equivalent to:
|
||||
|
||||
<screen>
|
||||
$ nix-instantiate '<nixpkgs>' -A hello
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Parsing and evaluating Nix expressions:
|
||||
|
||||
<screen>
|
||||
$ nix-instantiate --parse -E '1 + 2'
|
||||
1 + 2
|
||||
|
||||
$ nix-instantiate --eval -E '1 + 2'
|
||||
3
|
||||
|
||||
$ nix-instantiate --eval --xml -E '1 + 2'
|
||||
<![CDATA[<?xml version='1.0' encoding='utf-8'?>
|
||||
<expr>
|
||||
<int value="3" />
|
||||
</expr>]]></screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>The difference between non-strict and strict evaluation:
|
||||
|
||||
<screen>
|
||||
$ nix-instantiate --eval --xml -E 'rec { x = "foo"; y = x; }'
|
||||
<replaceable>...</replaceable><![CDATA[
|
||||
<attr name="x">
|
||||
<string value="foo" />
|
||||
</attr>
|
||||
<attr name="y">
|
||||
<unevaluated />
|
||||
</attr>]]>
|
||||
<replaceable>...</replaceable></screen>
|
||||
|
||||
Note that <varname>y</varname> is left unevaluated (the XML
|
||||
representation doesn’t attempt to show non-normal forms).
|
||||
|
||||
<screen>
|
||||
$ nix-instantiate --eval --xml --strict -E 'rec { x = "foo"; y = x; }'
|
||||
<replaceable>...</replaceable><![CDATA[
|
||||
<attr name="x">
|
||||
<string value="foo" />
|
||||
</attr>
|
||||
<attr name="y">
|
||||
<string value="foo" />
|
||||
</attr>]]>
|
||||
<replaceable>...</replaceable></screen>
|
||||
|
||||
</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection condition="manpage"><title>Environment variables</title>
|
||||
|
||||
<variablelist>
|
||||
<xi:include href="env-common.xml#xmlns(db=http://docbook.org/ns/docbook)xpointer(//db:variablelist[@xml:id='env-common']/*)" />
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
</refentry>
|
||||
|
|
@ -1,131 +0,0 @@
|
|||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-prefetch-url">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-prefetch-url</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>nix-prefetch-url</refname>
|
||||
<refpurpose>copy a file from a URL into the store and print its hash</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<cmdsynopsis>
|
||||
<command>nix-prefetch-url</command>
|
||||
<arg><option>--version</option></arg>
|
||||
<arg><option>--type</option> <replaceable>hashAlgo</replaceable></arg>
|
||||
<arg><option>--print-path</option></arg>
|
||||
<arg><option>--unpack</option></arg>
|
||||
<arg><option>--name</option> <replaceable>name</replaceable></arg>
|
||||
<arg choice='plain'><replaceable>url</replaceable></arg>
|
||||
<arg><replaceable>hash</replaceable></arg>
|
||||
</cmdsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
<para>The command <command>nix-prefetch-url</command> downloads the
|
||||
file referenced by the URL <replaceable>url</replaceable>, prints its
|
||||
cryptographic hash, and copies it into the Nix store. The file name
|
||||
in the store is
|
||||
<filename><replaceable>hash</replaceable>-<replaceable>baseName</replaceable></filename>,
|
||||
where <replaceable>baseName</replaceable> is everything following the
|
||||
final slash in <replaceable>url</replaceable>.</para>
|
||||
|
||||
<para>This command is just a convenience for Nix expression writers.
|
||||
Often a Nix expression fetches some source distribution from the
|
||||
network using the <literal>fetchurl</literal> expression contained in
|
||||
Nixpkgs. However, <literal>fetchurl</literal> requires a
|
||||
cryptographic hash. If you don't know the hash, you would have to
|
||||
download the file first, and then <literal>fetchurl</literal> would
|
||||
download it again when you build your Nix expression. Since
|
||||
<literal>fetchurl</literal> uses the same name for the downloaded file
|
||||
as <command>nix-prefetch-url</command>, the redundant download can be
|
||||
avoided.</para>
|
||||
|
||||
<para>If <replaceable>hash</replaceable> is specified, then a download
|
||||
is not performed if the Nix store already contains a file with the
|
||||
same hash and base name. Otherwise, the file is downloaded, and an
|
||||
error if signaled if the actual hash of the file does not match the
|
||||
specified hash.</para>
|
||||
|
||||
<para>This command prints the hash on standard output. Additionally,
|
||||
if the option <option>--print-path</option> is used, the path of the
|
||||
downloaded file in the Nix store is also printed.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Options</title>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><option>--type</option> <replaceable>hashAlgo</replaceable></term>
|
||||
|
||||
<listitem><para>Use the specified cryptographic hash algorithm,
|
||||
which can be one of <literal>md5</literal>,
|
||||
<literal>sha1</literal>, and
|
||||
<literal>sha256</literal>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--print-path</option></term>
|
||||
|
||||
<listitem><para>Print the store path of the downloaded file on
|
||||
standard output.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--unpack</option></term>
|
||||
|
||||
<listitem><para>Unpack the archive (which must be a tarball or zip
|
||||
file) and add the result to the Nix store. The resulting hash can
|
||||
be used with functions such as Nixpkgs’s
|
||||
<varname>fetchzip</varname> or
|
||||
<varname>fetchFromGitHub</varname>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--name</option> <replaceable>name</replaceable></term>
|
||||
|
||||
<listitem><para>Override the name of the file in the Nix store. By
|
||||
default, this is
|
||||
<literal><replaceable>hash</replaceable>-<replaceable>basename</replaceable></literal>,
|
||||
where <replaceable>basename</replaceable> is the last component of
|
||||
<replaceable>url</replaceable>. Overriding the name is necessary
|
||||
when <replaceable>basename</replaceable> contains characters that
|
||||
are not allowed in Nix store paths.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Examples</title>
|
||||
|
||||
<screen>
|
||||
$ nix-prefetch-url ftp://ftp.gnu.org/pub/gnu/hello/hello-2.10.tar.gz
|
||||
0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i
|
||||
|
||||
$ nix-prefetch-url --print-path mirror://gnu/hello/hello-2.10.tar.gz
|
||||
0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i
|
||||
/nix/store/3x7dwzq014bblazs7kq20p9hyzz0qh8g-hello-2.10.tar.gz
|
||||
|
||||
$ nix-prefetch-url --unpack --print-path https://github.com/NixOS/patchelf/archive/0.8.tar.gz
|
||||
079agjlv0hrv7fxnx9ngipx14gyncbkllxrp9cccnh3a50fxcmy7
|
||||
/nix/store/19zrmhm3m40xxaw81c8cqm6aljgrnwj2-0.8.tar.gz
|
||||
</screen>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
</refentry>
|
||||
|
|
@ -1,397 +0,0 @@
|
|||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-shell">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-shell</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>nix-shell</refname>
|
||||
<refpurpose>start an interactive shell based on a Nix expression</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<cmdsynopsis>
|
||||
<command>nix-shell</command>
|
||||
<arg><option>--arg</option> <replaceable>name</replaceable> <replaceable>value</replaceable></arg>
|
||||
<arg><option>--argstr</option> <replaceable>name</replaceable> <replaceable>value</replaceable></arg>
|
||||
<arg>
|
||||
<group choice='req'>
|
||||
<arg choice='plain'><option>--attr</option></arg>
|
||||
<arg choice='plain'><option>-A</option></arg>
|
||||
</group>
|
||||
<replaceable>attrPath</replaceable>
|
||||
</arg>
|
||||
<arg><option>--command</option> <replaceable>cmd</replaceable></arg>
|
||||
<arg><option>--run</option> <replaceable>cmd</replaceable></arg>
|
||||
<arg><option>--exclude</option> <replaceable>regexp</replaceable></arg>
|
||||
<arg><option>--pure</option></arg>
|
||||
<arg><option>--keep</option> <replaceable>name</replaceable></arg>
|
||||
<group choice='req'>
|
||||
<arg choice='plain'>
|
||||
<group choice='req'>
|
||||
<arg choice='plain'><option>--packages</option></arg>
|
||||
<arg choice='plain'><option>-p</option></arg>
|
||||
</group>
|
||||
<arg choice='plain' rep='repeat'><replaceable>packages</replaceable></arg>
|
||||
</arg>
|
||||
<arg><replaceable>path</replaceable></arg>
|
||||
</group>
|
||||
</cmdsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
<para>The command <command>nix-shell</command> will build the
|
||||
dependencies of the specified derivation, but not the derivation
|
||||
itself. It will then start an interactive shell in which all
|
||||
environment variables defined by the derivation
|
||||
<replaceable>path</replaceable> have been set to their corresponding
|
||||
values, and the script <literal>$stdenv/setup</literal> has been
|
||||
sourced. This is useful for reproducing the environment of a
|
||||
derivation for development.</para>
|
||||
|
||||
<para>If <replaceable>path</replaceable> is not given,
|
||||
<command>nix-shell</command> defaults to
|
||||
<filename>shell.nix</filename> if it exists, and
|
||||
<filename>default.nix</filename> otherwise.</para>
|
||||
|
||||
<para>If <replaceable>path</replaceable> starts with
|
||||
<literal>http://</literal> or <literal>https://</literal>, it is
|
||||
interpreted as the URL of a tarball that will be downloaded and
|
||||
unpacked to a temporary location. The tarball must include a single
|
||||
top-level directory containing at least a file named
|
||||
<filename>default.nix</filename>.</para>
|
||||
|
||||
<para>If the derivation defines the variable
|
||||
<varname>shellHook</varname>, it will be evaluated after
|
||||
<literal>$stdenv/setup</literal> has been sourced. Since this hook is
|
||||
not executed by regular Nix builds, it allows you to perform
|
||||
initialisation specific to <command>nix-shell</command>. For example,
|
||||
the derivation attribute
|
||||
|
||||
<programlisting>
|
||||
shellHook =
|
||||
''
|
||||
echo "Hello shell"
|
||||
'';
|
||||
</programlisting>
|
||||
|
||||
will cause <command>nix-shell</command> to print <literal>Hello shell</literal>.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Options</title>
|
||||
|
||||
<para>All options not listed here are passed to <command>nix-store
|
||||
--realise</command>, except for <option>--arg</option> and
|
||||
<option>--attr</option> / <option>-A</option> which are passed to
|
||||
<command>nix-instantiate</command>. <phrase condition="manual">See
|
||||
also <xref linkend="sec-common-options" />.</phrase></para>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><option>--command</option> <replaceable>cmd</replaceable></term>
|
||||
|
||||
<listitem><para>In the environment of the derivation, run the
|
||||
shell command <replaceable>cmd</replaceable>. This command is
|
||||
executed in an interactive shell. (Use <option>--run</option> to
|
||||
use a non-interactive shell instead.) However, a call to
|
||||
<literal>exit</literal> is implicitly added to the command, so the
|
||||
shell will exit after running the command. To prevent this, add
|
||||
<literal>return</literal> at the end; e.g. <literal>--command
|
||||
"echo Hello; return"</literal> will print <literal>Hello</literal>
|
||||
and then drop you into the interactive shell. This can be useful
|
||||
for doing any additional initialisation.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--run</option> <replaceable>cmd</replaceable></term>
|
||||
|
||||
<listitem><para>Like <option>--command</option>, but executes the
|
||||
command in a non-interactive shell. This means (among other
|
||||
things) that if you hit Ctrl-C while the command is running, the
|
||||
shell exits.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--exclude</option> <replaceable>regexp</replaceable></term>
|
||||
|
||||
<listitem><para>Do not build any dependencies whose store path
|
||||
matches the regular expression <replaceable>regexp</replaceable>.
|
||||
This option may be specified multiple times.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--pure</option></term>
|
||||
|
||||
<listitem><para>If this flag is specified, the environment is
|
||||
almost entirely cleared before the interactive shell is started,
|
||||
so you get an environment that more closely corresponds to the
|
||||
“real” Nix build. A few variables, in particular
|
||||
<envar>HOME</envar>, <envar>USER</envar> and
|
||||
<envar>DISPLAY</envar>, are retained. Note that
|
||||
<filename>~/.bashrc</filename> and (depending on your Bash
|
||||
installation) <filename>/etc/bashrc</filename> are still sourced,
|
||||
so any variables set there will affect the interactive
|
||||
shell.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--packages</option> / <option>-p</option> <replaceable>packages</replaceable>…</term>
|
||||
|
||||
<listitem><para>Set up an environment in which the specified
|
||||
packages are present. The command line arguments are interpreted
|
||||
as attribute names inside the Nix Packages collection. Thus,
|
||||
<literal>nix-shell -p libjpeg openjdk</literal> will start a shell
|
||||
in which the packages denoted by the attribute names
|
||||
<varname>libjpeg</varname> and <varname>openjdk</varname> are
|
||||
present.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>-i</option> <replaceable>interpreter</replaceable></term>
|
||||
|
||||
<listitem><para>The chained script interpreter to be invoked by
|
||||
<command>nix-shell</command>. Only applicable in
|
||||
<literal>#!</literal>-scripts (described <link
|
||||
linkend="ssec-nix-shell-shebang">below</link>).</para>
|
||||
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><option>--keep</option> <replaceable>name</replaceable></term>
|
||||
|
||||
<listitem><para>When a <option>--pure</option> shell is started,
|
||||
keep the listed environment variables.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
<para>The following common options are supported:</para>
|
||||
|
||||
<variablelist condition="manpage">
|
||||
<xi:include href="opt-common.xml#xmlns(db=http://docbook.org/ns/docbook)xpointer(//db:variablelist[@xml:id='opt-common']/*)" />
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Environment variables</title>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><envar>NIX_BUILD_SHELL</envar></term>
|
||||
|
||||
<listitem><para>Shell used to start the interactive environment.
|
||||
Defaults to the <command>bash</command> found in <envar>PATH</envar>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Examples</title>
|
||||
|
||||
<para>To build the dependencies of the package Pan, and start an
|
||||
interactive shell in which to build it:
|
||||
|
||||
<screen>
|
||||
$ nix-shell '<nixpkgs>' -A pan
|
||||
[nix-shell]$ unpackPhase
|
||||
[nix-shell]$ cd pan-*
|
||||
[nix-shell]$ configurePhase
|
||||
[nix-shell]$ buildPhase
|
||||
[nix-shell]$ ./pan/gui/pan
|
||||
</screen>
|
||||
|
||||
To clear the environment first, and do some additional automatic
|
||||
initialisation of the interactive shell:
|
||||
|
||||
<screen>
|
||||
$ nix-shell '<nixpkgs>' -A pan --pure \
|
||||
--command 'export NIX_DEBUG=1; export NIX_CORES=8; return'
|
||||
</screen>
|
||||
|
||||
Nix expressions can also be given on the command line. For instance,
|
||||
the following starts a shell containing the packages
|
||||
<literal>sqlite</literal> and <literal>libX11</literal>:
|
||||
|
||||
<screen>
|
||||
$ nix-shell -E 'with import <nixpkgs> { }; runCommand "dummy" { buildInputs = [ sqlite xorg.libX11 ]; } ""'
|
||||
</screen>
|
||||
|
||||
A shorter way to do the same is:
|
||||
|
||||
<screen>
|
||||
$ nix-shell -p sqlite xorg.libX11
|
||||
[nix-shell]$ echo $NIX_LDFLAGS
|
||||
… -L/nix/store/j1zg5v…-sqlite-3.8.0.2/lib -L/nix/store/0gmcz9…-libX11-1.6.1/lib …
|
||||
</screen>
|
||||
|
||||
The <command>-p</command> flag looks up Nixpkgs in the Nix search
|
||||
path. You can override it by passing <option>-I</option> or setting
|
||||
<envar>NIX_PATH</envar>. For example, the following gives you a shell
|
||||
containing the Pan package from a specific revision of Nixpkgs:
|
||||
|
||||
<screen>
|
||||
$ nix-shell -p pan -I nixpkgs=https://github.com/NixOS/nixpkgs-channels/archive/8a3eea054838b55aca962c3fbde9c83c102b8bf2.tar.gz
|
||||
|
||||
[nix-shell:~]$ pan --version
|
||||
Pan 0.139
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection xml:id="ssec-nix-shell-shebang"><title>Use as a <literal>#!</literal>-interpreter</title>
|
||||
|
||||
<para>You can use <command>nix-shell</command> as a script interpreter
|
||||
to allow scripts written in arbitrary languages to obtain their own
|
||||
dependencies via Nix. This is done by starting the script with the
|
||||
following lines:
|
||||
|
||||
<programlisting>
|
||||
#! /usr/bin/env nix-shell
|
||||
#! nix-shell -i <replaceable>real-interpreter</replaceable> -p <replaceable>packages</replaceable>
|
||||
</programlisting>
|
||||
|
||||
where <replaceable>real-interpreter</replaceable> is the “real” script
|
||||
interpreter that will be invoked by <command>nix-shell</command> after
|
||||
it has obtained the dependencies and initialised the environment, and
|
||||
<replaceable>packages</replaceable> are the attribute names of the
|
||||
dependencies in Nixpkgs.</para>
|
||||
|
||||
<para>The lines starting with <literal>#! nix-shell</literal> specify
|
||||
<command>nix-shell</command> options (see above). Note that you cannot
|
||||
write <literal>#! /usr/bin/env nix-shell -i ...</literal> because
|
||||
many operating systems only allow one argument in
|
||||
<literal>#!</literal> lines.</para>
|
||||
|
||||
<para>For example, here is a Python script that depends on Python and
|
||||
the <literal>prettytable</literal> package:
|
||||
|
||||
<programlisting>
|
||||
#! /usr/bin/env nix-shell
|
||||
#! nix-shell -i python -p python pythonPackages.prettytable
|
||||
|
||||
import prettytable
|
||||
|
||||
# Print a simple table.
|
||||
t = prettytable.PrettyTable(["N", "N^2"])
|
||||
for n in range(1, 10): t.add_row([n, n * n])
|
||||
print t
|
||||
</programlisting>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Similarly, the following is a Perl script that specifies that it
|
||||
requires Perl and the <literal>HTML::TokeParser::Simple</literal> and
|
||||
<literal>LWP</literal> packages:
|
||||
|
||||
<programlisting>
|
||||
#! /usr/bin/env nix-shell
|
||||
#! nix-shell -i perl -p perl perlPackages.HTMLTokeParserSimple perlPackages.LWP
|
||||
|
||||
use HTML::TokeParser::Simple;
|
||||
|
||||
# Fetch nixos.org and print all hrefs.
|
||||
my $p = HTML::TokeParser::Simple->new(url => 'http://nixos.org/');
|
||||
|
||||
while (my $token = $p->get_tag("a")) {
|
||||
my $href = $token->get_attr("href");
|
||||
print "$href\n" if $href;
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Sometimes you need to pass a simple Nix expression to customize
|
||||
a package like Terraform:
|
||||
|
||||
<programlisting><![CDATA[
|
||||
#! /usr/bin/env nix-shell
|
||||
#! nix-shell -i bash -p "terraform.withPlugins (plugins: [ plugins.openstack ])"
|
||||
|
||||
terraform apply
|
||||
]]></programlisting>
|
||||
|
||||
<note><para>You must use double quotes (<literal>"</literal>) when
|
||||
passing a simple Nix expression in a nix-shell shebang.</para></note>
|
||||
</para>
|
||||
|
||||
<para>Finally, using the merging of multiple nix-shell shebangs the
|
||||
following Haskell script uses a specific branch of Nixpkgs/NixOS (the
|
||||
18.03 stable branch):
|
||||
|
||||
<programlisting><![CDATA[
|
||||
#! /usr/bin/env nix-shell
|
||||
#! nix-shell -i runghc -p "haskellPackages.ghcWithPackages (ps: [ps.HTTP ps.tagsoup])"
|
||||
#! nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs-channels/archive/nixos-18.03.tar.gz
|
||||
|
||||
import Network.HTTP
|
||||
import Text.HTML.TagSoup
|
||||
|
||||
-- Fetch nixos.org and print all hrefs.
|
||||
main = do
|
||||
resp <- Network.HTTP.simpleHTTP (getRequest "http://nixos.org/")
|
||||
body <- getResponseBody resp
|
||||
let tags = filter (isTagOpenName "a") $ parseTags body
|
||||
let tags' = map (fromAttrib "href") tags
|
||||
mapM_ putStrLn $ filter (/= "") tags'
|
||||
]]></programlisting>
|
||||
|
||||
If you want to be even more precise, you can specify a specific
|
||||
revision of Nixpkgs:
|
||||
|
||||
<programlisting>
|
||||
#! nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs-channels/archive/0672315759b3e15e2121365f067c1c8c56bb4722.tar.gz
|
||||
</programlisting>
|
||||
|
||||
</para>
|
||||
|
||||
<para>The examples above all used <option>-p</option> to get
|
||||
dependencies from Nixpkgs. You can also use a Nix expression to build
|
||||
your own dependencies. For example, the Python example could have been
|
||||
written as:
|
||||
|
||||
<programlisting>
|
||||
#! /usr/bin/env nix-shell
|
||||
#! nix-shell deps.nix -i python
|
||||
</programlisting>
|
||||
|
||||
where the file <filename>deps.nix</filename> in the same directory
|
||||
as the <literal>#!</literal>-script contains:
|
||||
|
||||
<programlisting>
|
||||
with import <nixpkgs> {};
|
||||
|
||||
runCommand "dummy" { buildInputs = [ python pythonPackages.prettytable ]; } ""
|
||||
</programlisting>
|
||||
|
||||
</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection condition="manpage"><title>Environment variables</title>
|
||||
|
||||
<variablelist>
|
||||
<xi:include href="env-common.xml#xmlns(db=http://docbook.org/ns/docbook)xpointer(//db:variablelist[@xml:id='env-common']/*)" />
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
</refentry>
|
||||
File diff suppressed because it is too large
Load diff
|
|
@ -1,64 +0,0 @@
|
|||
<nop xmlns="http://docbook.org/ns/docbook">
|
||||
|
||||
<arg><option>--help</option></arg>
|
||||
<arg><option>--version</option></arg>
|
||||
<arg rep='repeat'>
|
||||
<group choice='req'>
|
||||
<arg choice='plain'><option>--verbose</option></arg>
|
||||
<arg choice='plain'><option>-v</option></arg>
|
||||
</group>
|
||||
</arg>
|
||||
<arg>
|
||||
<arg choice='plain'><option>--quiet</option></arg>
|
||||
</arg>
|
||||
<arg>
|
||||
<group choice='plain'>
|
||||
<arg choice='plain'><option>--no-build-output</option></arg>
|
||||
<arg choice='plain'><option>-Q</option></arg>
|
||||
</group>
|
||||
</arg>
|
||||
<arg>
|
||||
<group choice='req'>
|
||||
<arg choice='plain'><option>--max-jobs</option></arg>
|
||||
<arg choice='plain'><option>-j</option></arg>
|
||||
</group>
|
||||
<replaceable>number</replaceable>
|
||||
</arg>
|
||||
<arg>
|
||||
<option>--cores</option>
|
||||
<replaceable>number</replaceable>
|
||||
</arg>
|
||||
<arg>
|
||||
<option>--max-silent-time</option>
|
||||
<replaceable>number</replaceable>
|
||||
</arg>
|
||||
<arg>
|
||||
<option>--timeout</option>
|
||||
<replaceable>number</replaceable>
|
||||
</arg>
|
||||
<arg>
|
||||
<group choice='plain'>
|
||||
<arg choice='plain'><option>--keep-going</option></arg>
|
||||
<arg choice='plain'><option>-k</option></arg>
|
||||
</group>
|
||||
</arg>
|
||||
<arg>
|
||||
<group choice='plain'>
|
||||
<arg choice='plain'><option>--keep-failed</option></arg>
|
||||
<arg choice='plain'><option>-K</option></arg>
|
||||
</group>
|
||||
</arg>
|
||||
<arg><option>--fallback</option></arg>
|
||||
<arg><option>--readonly-mode</option></arg>
|
||||
<arg>
|
||||
<option>-I</option>
|
||||
<replaceable>path</replaceable>
|
||||
</arg>
|
||||
<arg>
|
||||
<option>--option</option>
|
||||
<replaceable>name</replaceable>
|
||||
<replaceable>value</replaceable>
|
||||
</arg>
|
||||
<sbr />
|
||||
|
||||
</nop>
|
||||
|
|
@ -1,358 +0,0 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook" xml:id="sec-common-options">
|
||||
|
||||
<title>Common Options</title>
|
||||
|
||||
|
||||
<para>Most Nix commands accept the following command-line options:</para>
|
||||
|
||||
<variablelist xml:id="opt-common">
|
||||
|
||||
<varlistentry><term><option>--help</option></term>
|
||||
|
||||
<listitem><para>Prints out a summary of the command syntax and
|
||||
exits.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--version</option></term>
|
||||
|
||||
<listitem><para>Prints out the Nix version number on standard output
|
||||
and exits.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--verbose</option> / <option>-v</option></term>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para>Increases the level of verbosity of diagnostic messages
|
||||
printed on standard error. For each Nix operation, the information
|
||||
printed on standard output is well-defined; any diagnostic
|
||||
information is printed on standard error, never on standard
|
||||
output.</para>
|
||||
|
||||
<para>This option may be specified repeatedly. Currently, the
|
||||
following verbosity levels exist:</para>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term>0</term>
|
||||
<listitem><para>“Errors only”: only print messages
|
||||
explaining why the Nix invocation failed.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>1</term>
|
||||
<listitem><para>“Informational”: print
|
||||
<emphasis>useful</emphasis> messages about what Nix is doing.
|
||||
This is the default.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>2</term>
|
||||
<listitem><para>“Talkative”: print more informational
|
||||
messages.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>3</term>
|
||||
<listitem><para>“Chatty”: print even more
|
||||
informational messages.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>4</term>
|
||||
<listitem><para>“Debug”: print debug
|
||||
information.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>5</term>
|
||||
<listitem><para>“Vomit”: print vast amounts of debug
|
||||
information.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--quiet</option></term>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para>Decreases the level of verbosity of diagnostic messages
|
||||
printed on standard error. This is the inverse option to
|
||||
<option>-v</option> / <option>--verbose</option>.
|
||||
</para>
|
||||
|
||||
<para>This option may be specified repeatedly. See the previous
|
||||
verbosity levels list.</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--no-build-output</option> / <option>-Q</option></term>
|
||||
|
||||
<listitem><para>By default, output written by builders to standard
|
||||
output and standard error is echoed to the Nix command's standard
|
||||
error. This option suppresses this behaviour. Note that the
|
||||
builder's standard output and error are always written to a log file
|
||||
in
|
||||
<filename><replaceable>prefix</replaceable>/nix/var/log/nix</filename>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="opt-max-jobs"><term><option>--max-jobs</option> / <option>-j</option>
|
||||
<replaceable>number</replaceable></term>
|
||||
|
||||
<listitem><para>Sets the maximum number of build jobs that Nix will
|
||||
perform in parallel to the specified number. Specify
|
||||
<literal>auto</literal> to use the number of CPUs in the system.
|
||||
The default is specified by the <link
|
||||
linkend='conf-max-jobs'><literal>max-jobs</literal></link>
|
||||
configuration setting, which itself defaults to
|
||||
<literal>1</literal>. A higher value is useful on SMP systems or to
|
||||
exploit I/O latency.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="opt-cores"><term><option>--cores</option></term>
|
||||
|
||||
<listitem><para>Sets the value of the <envar>NIX_BUILD_CORES</envar>
|
||||
environment variable in the invocation of builders. Builders can
|
||||
use this variable at their discretion to control the maximum amount
|
||||
of parallelism. For instance, in Nixpkgs, if the derivation
|
||||
attribute <varname>enableParallelBuilding</varname> is set to
|
||||
<literal>true</literal>, the builder passes the
|
||||
<option>-j<replaceable>N</replaceable></option> flag to GNU Make.
|
||||
It defaults to the value of the <link
|
||||
linkend='conf-cores'><literal>cores</literal></link>
|
||||
configuration setting, if set, or <literal>1</literal> otherwise.
|
||||
The value <literal>0</literal> means that the builder should use all
|
||||
available CPU cores in the system.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="opt-max-silent-time"><term><option>--max-silent-time</option></term>
|
||||
|
||||
<listitem><para>Sets the maximum number of seconds that a builder
|
||||
can go without producing any data on standard output or standard
|
||||
error. The default is specified by the <link
|
||||
linkend='conf-max-silent-time'><literal>max-silent-time</literal></link>
|
||||
configuration setting. <literal>0</literal> means no
|
||||
time-out.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry xml:id="opt-timeout"><term><option>--timeout</option></term>
|
||||
|
||||
<listitem><para>Sets the maximum number of seconds that a builder
|
||||
can run. The default is specified by the <link
|
||||
linkend='conf-timeout'><literal>timeout</literal></link>
|
||||
configuration setting. <literal>0</literal> means no
|
||||
timeout.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--keep-going</option> / <option>-k</option></term>
|
||||
|
||||
<listitem><para>Keep going in case of failed builds, to the
|
||||
greatest extent possible. That is, if building an input of some
|
||||
derivation fails, Nix will still build the other inputs, but not the
|
||||
derivation itself. Without this option, Nix stops if any build
|
||||
fails (except for builds of substitutes), possibly killing builds in
|
||||
progress (in case of parallel or distributed builds).</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--keep-failed</option> / <option>-K</option></term>
|
||||
|
||||
<listitem><para>Specifies that in case of a build failure, the
|
||||
temporary directory (usually in <filename>/tmp</filename>) in which
|
||||
the build takes place should not be deleted. The path of the build
|
||||
directory is printed as an informational message.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--fallback</option></term>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para>Whenever Nix attempts to build a derivation for which
|
||||
substitutes are known for each output path, but realising the output
|
||||
paths through the substitutes fails, fall back on building the
|
||||
derivation.</para>
|
||||
|
||||
<para>The most common scenario in which this is useful is when we
|
||||
have registered substitutes in order to perform binary distribution
|
||||
from, say, a network repository. If the repository is down, the
|
||||
realisation of the derivation will fail. When this option is
|
||||
specified, Nix will build the derivation instead. Thus,
|
||||
installation from binaries falls back on installation from source.
|
||||
This option is not the default since it is generally not desirable
|
||||
for a transient failure in obtaining the substitutes to lead to a
|
||||
full build from source (with the related consumption of
|
||||
resources).</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--no-build-hook</option></term>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para>Disables the build hook mechanism. This allows to ignore remote
|
||||
builders if they are setup on the machine.</para>
|
||||
|
||||
<para>It's useful in cases where the bandwidth between the client and the
|
||||
remote builder is too low. In that case it can take more time to upload the
|
||||
sources to the remote builder and fetch back the result than to do the
|
||||
computation locally.</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
|
||||
<varlistentry><term><option>--readonly-mode</option></term>
|
||||
|
||||
<listitem><para>When this option is used, no attempt is made to open
|
||||
the Nix database. Most Nix operations do need database access, so
|
||||
those operations will fail.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--arg</option> <replaceable>name</replaceable> <replaceable>value</replaceable></term>
|
||||
|
||||
<listitem><para>This option is accepted by
|
||||
<command>nix-env</command>, <command>nix-instantiate</command> and
|
||||
<command>nix-build</command>. When evaluating Nix expressions, the
|
||||
expression evaluator will automatically try to call functions that
|
||||
it encounters. It can automatically call functions for which every
|
||||
argument has a <link linkend='ss-functions'>default value</link>
|
||||
(e.g., <literal>{ <replaceable>argName</replaceable> ?
|
||||
<replaceable>defaultValue</replaceable> }:
|
||||
<replaceable>...</replaceable></literal>). With
|
||||
<option>--arg</option>, you can also call functions that have
|
||||
arguments without a default value (or override a default value).
|
||||
That is, if the evaluator encounters a function with an argument
|
||||
named <replaceable>name</replaceable>, it will call it with value
|
||||
<replaceable>value</replaceable>.</para>
|
||||
|
||||
<para>For instance, the top-level <literal>default.nix</literal> in
|
||||
Nixpkgs is actually a function:
|
||||
|
||||
<programlisting>
|
||||
{ # The system (e.g., `i686-linux') for which to build the packages.
|
||||
system ? builtins.currentSystem
|
||||
<replaceable>...</replaceable>
|
||||
}: <replaceable>...</replaceable></programlisting>
|
||||
|
||||
So if you call this Nix expression (e.g., when you do
|
||||
<literal>nix-env -i <replaceable>pkgname</replaceable></literal>),
|
||||
the function will be called automatically using the value <link
|
||||
linkend='builtin-currentSystem'><literal>builtins.currentSystem</literal></link>
|
||||
for the <literal>system</literal> argument. You can override this
|
||||
using <option>--arg</option>, e.g., <literal>nix-env -i
|
||||
<replaceable>pkgname</replaceable> --arg system
|
||||
\"i686-freebsd\"</literal>. (Note that since the argument is a Nix
|
||||
string literal, you have to escape the quotes.)</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--argstr</option> <replaceable>name</replaceable> <replaceable>value</replaceable></term>
|
||||
|
||||
<listitem><para>This option is like <option>--arg</option>, only the
|
||||
value is not a Nix expression but a string. So instead of
|
||||
<literal>--arg system \"i686-linux\"</literal> (the outer quotes are
|
||||
to keep the shell happy) you can say <literal>--argstr system
|
||||
i686-linux</literal>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="opt-attr"><term><option>--attr</option> / <option>-A</option>
|
||||
<replaceable>attrPath</replaceable></term>
|
||||
|
||||
<listitem><para>Select an attribute from the top-level Nix
|
||||
expression being evaluated. (<command>nix-env</command>,
|
||||
<command>nix-instantiate</command>, <command>nix-build</command> and
|
||||
<command>nix-shell</command> only.) The <emphasis>attribute
|
||||
path</emphasis> <replaceable>attrPath</replaceable> is a sequence of
|
||||
attribute names separated by dots. For instance, given a top-level
|
||||
Nix expression <replaceable>e</replaceable>, the attribute path
|
||||
<literal>xorg.xorgserver</literal> would cause the expression
|
||||
<literal><replaceable>e</replaceable>.xorg.xorgserver</literal> to
|
||||
be used. See <link
|
||||
linkend='refsec-nix-env-install-examples'><command>nix-env
|
||||
--install</command></link> for some concrete examples.</para>
|
||||
|
||||
<para>In addition to attribute names, you can also specify array
|
||||
indices. For instance, the attribute path
|
||||
<literal>foo.3.bar</literal> selects the <literal>bar</literal>
|
||||
attribute of the fourth element of the array in the
|
||||
<literal>foo</literal> attribute of the top-level
|
||||
expression.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--expr</option> / <option>-E</option></term>
|
||||
|
||||
<listitem><para>Interpret the command line arguments as a list of
|
||||
Nix expressions to be parsed and evaluated, rather than as a list
|
||||
of file names of Nix expressions.
|
||||
(<command>nix-instantiate</command>, <command>nix-build</command>
|
||||
and <command>nix-shell</command> only.)</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="opt-I"><term><option>-I</option> <replaceable>path</replaceable></term>
|
||||
|
||||
<listitem><para>Add a path to the Nix expression search path. This
|
||||
option may be given multiple times. See the <envar
|
||||
linkend="env-NIX_PATH">NIX_PATH</envar> environment variable for
|
||||
information on the semantics of the Nix search path. Paths added
|
||||
through <option>-I</option> take precedence over
|
||||
<envar>NIX_PATH</envar>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--option</option> <replaceable>name</replaceable> <replaceable>value</replaceable></term>
|
||||
|
||||
<listitem><para>Set the Nix configuration option
|
||||
<replaceable>name</replaceable> to <replaceable>value</replaceable>.
|
||||
This overrides settings in the Nix configuration file (see
|
||||
<citerefentry><refentrytitle>nix.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--repair</option></term>
|
||||
|
||||
<listitem><para>Fix corrupted or missing store paths by
|
||||
redownloading or rebuilding them. Note that this is slow because it
|
||||
requires computing a cryptographic hash of the contents of every
|
||||
path in the closure of the build. Also note the warning under
|
||||
<command>nix-store --repair-path</command>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
</variablelist>
|
||||
|
||||
|
||||
</chapter>
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
<nop xmlns="http://docbook.org/ns/docbook">
|
||||
|
||||
<arg>
|
||||
<group choice='req'>
|
||||
<arg choice='plain'><option>--prebuilt-only</option></arg>
|
||||
<arg choice='plain'><option>-b</option></arg>
|
||||
</group>
|
||||
</arg>
|
||||
|
||||
<arg>
|
||||
<group choice='req'>
|
||||
<arg choice='plain'><option>--attr</option></arg>
|
||||
<arg choice='plain'><option>-A</option></arg>
|
||||
</group>
|
||||
</arg>
|
||||
|
||||
<arg><option>--from-expression</option></arg>
|
||||
<arg><option>-E</option></arg>
|
||||
|
||||
<arg><option>--from-profile</option> <replaceable>path</replaceable></arg>
|
||||
|
||||
</nop>
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='ch-utilities'>
|
||||
|
||||
<title>Utilities</title>
|
||||
|
||||
<para>This section lists utilities that you can use when you
|
||||
work with Nix.</para>
|
||||
|
||||
<xi:include href="nix-channel.xml" />
|
||||
<xi:include href="nix-collect-garbage.xml" />
|
||||
<xi:include href="nix-copy-closure.xml" />
|
||||
<xi:include href="nix-daemon.xml" />
|
||||
<xi:include href="nix-hash.xml" />
|
||||
<xi:include href="nix-instantiate.xml" />
|
||||
<xi:include href="nix-prefetch-url.xml" />
|
||||
|
||||
</chapter>
|
||||
7
doc/manual/custom.css
Normal file
7
doc/manual/custom.css
Normal file
|
|
@ -0,0 +1,7 @@
|
|||
h1:not(:first-of-type) {
|
||||
margin-top: 1.3em;
|
||||
}
|
||||
|
||||
h2 {
|
||||
margin-top: 1em;
|
||||
}
|
||||
|
|
@ -1,340 +0,0 @@
|
|||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-advanced-attributes">
|
||||
|
||||
<title>Advanced Attributes</title>
|
||||
|
||||
<para>Derivations can declare some infrequently used optional
|
||||
attributes.</para>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><varname>allowedReferences</varname></term>
|
||||
|
||||
<listitem><para>The optional attribute
|
||||
<varname>allowedReferences</varname> specifies a list of legal
|
||||
references (dependencies) of the output of the builder. For
|
||||
example,
|
||||
|
||||
<programlisting>
|
||||
allowedReferences = [];
|
||||
</programlisting>
|
||||
|
||||
enforces that the output of a derivation cannot have any runtime
|
||||
dependencies on its inputs. To allow an output to have a runtime
|
||||
dependency on itself, use <literal>"out"</literal> as a list item.
|
||||
This is used in NixOS to check that generated files such as
|
||||
initial ramdisks for booting Linux don’t have accidental
|
||||
dependencies on other paths in the Nix store.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><varname>allowedRequisites</varname></term>
|
||||
|
||||
<listitem><para>This attribute is similar to
|
||||
<varname>allowedReferences</varname>, but it specifies the legal
|
||||
requisites of the whole closure, so all the dependencies
|
||||
recursively. For example,
|
||||
|
||||
<programlisting>
|
||||
allowedRequisites = [ foobar ];
|
||||
</programlisting>
|
||||
|
||||
enforces that the output of a derivation cannot have any other
|
||||
runtime dependency than <varname>foobar</varname>, and in addition
|
||||
it enforces that <varname>foobar</varname> itself doesn't
|
||||
introduce any other dependency itself.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><varname>disallowedReferences</varname></term>
|
||||
|
||||
<listitem><para>The optional attribute
|
||||
<varname>disallowedReferences</varname> specifies a list of illegal
|
||||
references (dependencies) of the output of the builder. For
|
||||
example,
|
||||
|
||||
<programlisting>
|
||||
disallowedReferences = [ foo ];
|
||||
</programlisting>
|
||||
|
||||
enforces that the output of a derivation cannot have a direct runtime
|
||||
dependencies on the derivation <varname>foo</varname>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><varname>disallowedRequisites</varname></term>
|
||||
|
||||
<listitem><para>This attribute is similar to
|
||||
<varname>disallowedReferences</varname>, but it specifies illegal
|
||||
requisites for the whole closure, so all the dependencies
|
||||
recursively. For example,
|
||||
|
||||
<programlisting>
|
||||
disallowedRequisites = [ foobar ];
|
||||
</programlisting>
|
||||
|
||||
enforces that the output of a derivation cannot have any
|
||||
runtime dependency on <varname>foobar</varname> or any other derivation
|
||||
depending recursively on <varname>foobar</varname>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><varname>exportReferencesGraph</varname></term>
|
||||
|
||||
<listitem><para>This attribute allows builders access to the
|
||||
references graph of their inputs. The attribute is a list of
|
||||
inputs in the Nix store whose references graph the builder needs
|
||||
to know. The value of this attribute should be a list of pairs
|
||||
<literal>[ <replaceable>name1</replaceable>
|
||||
<replaceable>path1</replaceable> <replaceable>name2</replaceable>
|
||||
<replaceable>path2</replaceable> <replaceable>...</replaceable>
|
||||
]</literal>. The references graph of each
|
||||
<replaceable>pathN</replaceable> will be stored in a text file
|
||||
<replaceable>nameN</replaceable> in the temporary build directory.
|
||||
The text files have the format used by <command>nix-store
|
||||
--register-validity</command> (with the deriver fields left
|
||||
empty). For example, when the following derivation is built:
|
||||
|
||||
<programlisting>
|
||||
derivation {
|
||||
...
|
||||
exportReferencesGraph = [ "libfoo-graph" libfoo ];
|
||||
};
|
||||
</programlisting>
|
||||
|
||||
the references graph of <literal>libfoo</literal> is placed in the
|
||||
file <filename>libfoo-graph</filename> in the temporary build
|
||||
directory.</para>
|
||||
|
||||
<para><varname>exportReferencesGraph</varname> is useful for
|
||||
builders that want to do something with the closure of a store
|
||||
path. Examples include the builders in NixOS that generate the
|
||||
initial ramdisk for booting Linux (a <command>cpio</command>
|
||||
archive containing the closure of the boot script) and the
|
||||
ISO-9660 image for the installation CD (which is populated with a
|
||||
Nix store containing the closure of a bootable NixOS
|
||||
configuration).</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><varname>impureEnvVars</varname></term>
|
||||
|
||||
<listitem><para>This attribute allows you to specify a list of
|
||||
environment variables that should be passed from the environment
|
||||
of the calling user to the builder. Usually, the environment is
|
||||
cleared completely when the builder is executed, but with this
|
||||
attribute you can allow specific environment variables to be
|
||||
passed unmodified. For example, <function>fetchurl</function> in
|
||||
Nixpkgs has the line
|
||||
|
||||
<programlisting>
|
||||
impureEnvVars = [ "http_proxy" "https_proxy" <replaceable>...</replaceable> ];
|
||||
</programlisting>
|
||||
|
||||
to make it use the proxy server configuration specified by the
|
||||
user in the environment variables <envar>http_proxy</envar> and
|
||||
friends.</para>
|
||||
|
||||
<para>This attribute is only allowed in <link
|
||||
linkend="fixed-output-drvs">fixed-output derivations</link>, where
|
||||
impurities such as these are okay since (the hash of) the output
|
||||
is known in advance. It is ignored for all other
|
||||
derivations.</para>
|
||||
|
||||
<warning><para><varname>impureEnvVars</varname> implementation takes
|
||||
environment variables from the current builder process. When a daemon is
|
||||
building its environmental variables are used. Without the daemon, the
|
||||
environmental variables come from the environment of the
|
||||
<command>nix-build</command>.</para></warning></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="fixed-output-drvs">
|
||||
<term><varname>outputHash</varname></term>
|
||||
<term><varname>outputHashAlgo</varname></term>
|
||||
<term><varname>outputHashMode</varname></term>
|
||||
|
||||
<listitem><para>These attributes declare that the derivation is a
|
||||
so-called <emphasis>fixed-output derivation</emphasis>, which
|
||||
means that a cryptographic hash of the output is already known in
|
||||
advance. When the build of a fixed-output derivation finishes,
|
||||
Nix computes the cryptographic hash of the output and compares it
|
||||
to the hash declared with these attributes. If there is a
|
||||
mismatch, the build fails.</para>
|
||||
|
||||
<para>The rationale for fixed-output derivations is derivations
|
||||
such as those produced by the <function>fetchurl</function>
|
||||
function. This function downloads a file from a given URL. To
|
||||
ensure that the downloaded file has not been modified, the caller
|
||||
must also specify a cryptographic hash of the file. For example,
|
||||
|
||||
<programlisting>
|
||||
fetchurl {
|
||||
url = http://ftp.gnu.org/pub/gnu/hello/hello-2.1.1.tar.gz;
|
||||
sha256 = "1md7jsfd8pa45z73bz1kszpp01yw6x5ljkjk2hx7wl800any6465";
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
It sometimes happens that the URL of the file changes, e.g.,
|
||||
because servers are reorganised or no longer available. We then
|
||||
must update the call to <function>fetchurl</function>, e.g.,
|
||||
|
||||
<programlisting>
|
||||
fetchurl {
|
||||
url = ftp://ftp.nluug.nl/pub/gnu/hello/hello-2.1.1.tar.gz;
|
||||
sha256 = "1md7jsfd8pa45z73bz1kszpp01yw6x5ljkjk2hx7wl800any6465";
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
If a <function>fetchurl</function> derivation was treated like a
|
||||
normal derivation, the output paths of the derivation and
|
||||
<emphasis>all derivations depending on it</emphasis> would change.
|
||||
For instance, if we were to change the URL of the Glibc source
|
||||
distribution in Nixpkgs (a package on which almost all other
|
||||
packages depend) massive rebuilds would be needed. This is
|
||||
unfortunate for a change which we know cannot have a real effect
|
||||
as it propagates upwards through the dependency graph.</para>
|
||||
|
||||
<para>For fixed-output derivations, on the other hand, the name of
|
||||
the output path only depends on the <varname>outputHash*</varname>
|
||||
and <varname>name</varname> attributes, while all other attributes
|
||||
are ignored for the purpose of computing the output path. (The
|
||||
<varname>name</varname> attribute is included because it is part
|
||||
of the path.)</para>
|
||||
|
||||
<para>As an example, here is the (simplified) Nix expression for
|
||||
<varname>fetchurl</varname>:
|
||||
|
||||
<programlisting>
|
||||
{ stdenv, curl }: # The <command>curl</command> program is used for downloading.
|
||||
|
||||
{ url, sha256 }:
|
||||
|
||||
stdenv.mkDerivation {
|
||||
name = baseNameOf (toString url);
|
||||
builder = ./builder.sh;
|
||||
buildInputs = [ curl ];
|
||||
|
||||
# This is a fixed-output derivation; the output must be a regular
|
||||
# file with SHA256 hash <varname>sha256</varname>.
|
||||
outputHashMode = "flat";
|
||||
outputHashAlgo = "sha256";
|
||||
outputHash = sha256;
|
||||
|
||||
inherit url;
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
</para>
|
||||
|
||||
<para>The <varname>outputHashAlgo</varname> attribute specifies
|
||||
the hash algorithm used to compute the hash. It can currently be
|
||||
<literal>"sha1"</literal>, <literal>"sha256"</literal> or
|
||||
<literal>"sha512"</literal>.</para>
|
||||
|
||||
<para>The <varname>outputHashMode</varname> attribute determines
|
||||
how the hash is computed. It must be one of the following two
|
||||
values:
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><literal>"flat"</literal></term>
|
||||
|
||||
<listitem><para>The output must be a non-executable regular
|
||||
file. If it isn’t, the build fails. The hash is simply
|
||||
computed over the contents of that file (so it’s equal to what
|
||||
Unix commands like <command>sha256sum</command> or
|
||||
<command>sha1sum</command> produce).</para>
|
||||
|
||||
<para>This is the default.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><literal>"recursive"</literal></term>
|
||||
|
||||
<listitem><para>The hash is computed over the NAR archive dump
|
||||
of the output (i.e., the result of <link
|
||||
linkend="refsec-nix-store-dump"><command>nix-store
|
||||
--dump</command></link>). In this case, the output can be
|
||||
anything, including a directory tree.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</para>
|
||||
|
||||
<para>The <varname>outputHash</varname> attribute, finally, must
|
||||
be a string containing the hash in either hexadecimal or base-32
|
||||
notation. (See the <link
|
||||
linkend="sec-nix-hash"><command>nix-hash</command> command</link>
|
||||
for information about converting to and from base-32
|
||||
notation.)</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><varname>passAsFile</varname></term>
|
||||
|
||||
<listitem><para>A list of names of attributes that should be
|
||||
passed via files rather than environment variables. For example,
|
||||
if you have
|
||||
|
||||
<programlisting>
|
||||
passAsFile = ["big"];
|
||||
big = "a very long string";
|
||||
</programlisting>
|
||||
|
||||
then when the builder runs, the environment variable
|
||||
<envar>bigPath</envar> will contain the absolute path to a
|
||||
temporary file containing <literal>a very long
|
||||
string</literal>. That is, for any attribute
|
||||
<replaceable>x</replaceable> listed in
|
||||
<varname>passAsFile</varname>, Nix will pass an environment
|
||||
variable <envar><replaceable>x</replaceable>Path</envar> holding
|
||||
the path of the file containing the value of attribute
|
||||
<replaceable>x</replaceable>. This is useful when you need to pass
|
||||
large strings to a builder, since most operating systems impose a
|
||||
limit on the size of the environment (typically, a few hundred
|
||||
kilobyte).</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><varname>preferLocalBuild</varname></term>
|
||||
|
||||
<listitem><para>If this attribute is set to
|
||||
<literal>true</literal> and <link
|
||||
linkend="chap-distributed-builds">distributed building is
|
||||
enabled</link>, then, if possible, the derivaton will be built
|
||||
locally instead of forwarded to a remote machine. This is
|
||||
appropriate for trivial builders where the cost of doing a
|
||||
download or remote build would exceed the cost of building
|
||||
locally.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><varname>allowSubstitutes</varname></term>
|
||||
|
||||
<listitem><para>If this attribute is set to
|
||||
<literal>false</literal>, then Nix will always build this
|
||||
derivation; it will not try to substitute its outputs. This is
|
||||
useful for very trivial derivations (such as
|
||||
<function>writeText</function> in Nixpkgs) that are cheaper to
|
||||
build than to substitute from a binary cache.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
</variablelist>
|
||||
|
||||
</section>
|
||||
|
|
@ -1,121 +0,0 @@
|
|||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='sec-arguments'>
|
||||
|
||||
<title>Arguments and Variables</title>
|
||||
|
||||
<example xml:id='ex-hello-composition'>
|
||||
|
||||
<title>Composing GNU Hello
|
||||
(<filename>all-packages.nix</filename>)</title>
|
||||
<programlisting>
|
||||
...
|
||||
|
||||
rec { <co xml:id='ex-hello-composition-co-1' />
|
||||
|
||||
hello = import ../applications/misc/hello/ex-1 <co xml:id='ex-hello-composition-co-2' /> { <co xml:id='ex-hello-composition-co-3' />
|
||||
inherit fetchurl stdenv perl;
|
||||
};
|
||||
|
||||
perl = import ../development/interpreters/perl { <co xml:id='ex-hello-composition-co-4' />
|
||||
inherit fetchurl stdenv;
|
||||
};
|
||||
|
||||
fetchurl = import ../build-support/fetchurl {
|
||||
inherit stdenv; ...
|
||||
};
|
||||
|
||||
stdenv = ...;
|
||||
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<para>The Nix expression in <xref linkend='ex-hello-nix' /> is a
|
||||
function; it is missing some arguments that have to be filled in
|
||||
somewhere. In the Nix Packages collection this is done in the file
|
||||
<filename>pkgs/top-level/all-packages.nix</filename>, where all
|
||||
Nix expressions for packages are imported and called with the
|
||||
appropriate arguments. <xref linkend='ex-hello-composition' /> shows
|
||||
some fragments of
|
||||
<filename>all-packages.nix</filename>.</para>
|
||||
|
||||
<calloutlist>
|
||||
|
||||
<callout arearefs='ex-hello-composition-co-1'>
|
||||
|
||||
<para>This file defines a set of attributes, all of which are
|
||||
concrete derivations (i.e., not functions). In fact, we define a
|
||||
<emphasis>mutually recursive</emphasis> set of attributes. That
|
||||
is, the attributes can refer to each other. This is precisely
|
||||
what we want since we want to <quote>plug</quote> the
|
||||
various packages into each other.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-composition-co-2'>
|
||||
|
||||
<para>Here we <emphasis>import</emphasis> the Nix expression for
|
||||
GNU Hello. The import operation just loads and returns the
|
||||
specified Nix expression. In fact, we could just have put the
|
||||
contents of <xref linkend='ex-hello-nix' /> in
|
||||
<filename>all-packages.nix</filename> at this point. That
|
||||
would be completely equivalent, but it would make the file rather
|
||||
bulky.</para>
|
||||
|
||||
<para>Note that we refer to
|
||||
<filename>../applications/misc/hello/ex-1</filename>, not
|
||||
<filename>../applications/misc/hello/ex-1/default.nix</filename>.
|
||||
When you try to import a directory, Nix automatically appends
|
||||
<filename>/default.nix</filename> to the file name.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-composition-co-3'>
|
||||
|
||||
<para>This is where the actual composition takes place. Here we
|
||||
<emphasis>call</emphasis> the function imported from
|
||||
<filename>../applications/misc/hello/ex-1</filename> with a set
|
||||
containing the things that the function expects, namely
|
||||
<varname>fetchurl</varname>, <varname>stdenv</varname>, and
|
||||
<varname>perl</varname>. We use inherit again to use the
|
||||
attributes defined in the surrounding scope (we could also have
|
||||
written <literal>fetchurl = fetchurl;</literal>, etc.).</para>
|
||||
|
||||
<para>The result of this function call is an actual derivation
|
||||
that can be built by Nix (since when we fill in the arguments of
|
||||
the function, what we get is its body, which is the call to
|
||||
<varname>stdenv.mkDerivation</varname> in <xref
|
||||
linkend='ex-hello-nix' />).</para>
|
||||
|
||||
<note><para>Nixpkgs has a convenience function
|
||||
<function>callPackage</function> that imports and calls a
|
||||
function, filling in any missing arguments by passing the
|
||||
corresponding attribute from the Nixpkgs set, like this:
|
||||
|
||||
<programlisting>
|
||||
hello = callPackage ../applications/misc/hello/ex-1 { };
|
||||
</programlisting>
|
||||
|
||||
If necessary, you can set or override arguments:
|
||||
|
||||
<programlisting>
|
||||
hello = callPackage ../applications/misc/hello/ex-1 { stdenv = myStdenv; };
|
||||
</programlisting>
|
||||
|
||||
</para></note>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-composition-co-4'>
|
||||
|
||||
<para>Likewise, we have to instantiate Perl,
|
||||
<varname>fetchurl</varname>, and the standard environment.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
</calloutlist>
|
||||
|
||||
</section>
|
||||
|
|
@ -1,119 +0,0 @@
|
|||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='sec-build-script'>
|
||||
|
||||
<title>Build Script</title>
|
||||
|
||||
<example xml:id='ex-hello-builder'><title>Build script for GNU Hello
|
||||
(<filename>builder.sh</filename>)</title>
|
||||
<programlisting>
|
||||
source $stdenv/setup <co xml:id='ex-hello-builder-co-1' />
|
||||
|
||||
PATH=$perl/bin:$PATH <co xml:id='ex-hello-builder-co-2' />
|
||||
|
||||
tar xvfz $src <co xml:id='ex-hello-builder-co-3' />
|
||||
cd hello-*
|
||||
./configure --prefix=$out <co xml:id='ex-hello-builder-co-4' />
|
||||
make <co xml:id='ex-hello-builder-co-5' />
|
||||
make install</programlisting>
|
||||
</example>
|
||||
|
||||
<para><xref linkend='ex-hello-builder' /> shows the builder referenced
|
||||
from Hello's Nix expression (stored in
|
||||
<filename>pkgs/applications/misc/hello/ex-1/builder.sh</filename>).
|
||||
The builder can actually be made a lot shorter by using the
|
||||
<emphasis>generic builder</emphasis> functions provided by
|
||||
<varname>stdenv</varname>, but here we write out the build steps to
|
||||
elucidate what a builder does. It performs the following
|
||||
steps:</para>
|
||||
|
||||
<calloutlist>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-1'>
|
||||
|
||||
<para>When Nix runs a builder, it initially completely clears the
|
||||
environment (except for the attributes declared in the
|
||||
derivation). For instance, the <envar>PATH</envar> variable is
|
||||
empty<footnote><para>Actually, it's initialised to
|
||||
<filename>/path-not-set</filename> to prevent Bash from setting it
|
||||
to a default value.</para></footnote>. This is done to prevent
|
||||
undeclared inputs from being used in the build process. If for
|
||||
example the <envar>PATH</envar> contained
|
||||
<filename>/usr/bin</filename>, then you might accidentally use
|
||||
<filename>/usr/bin/gcc</filename>.</para>
|
||||
|
||||
<para>So the first step is to set up the environment. This is
|
||||
done by calling the <filename>setup</filename> script of the
|
||||
standard environment. The environment variable
|
||||
<envar>stdenv</envar> points to the location of the standard
|
||||
environment being used. (It wasn't specified explicitly as an
|
||||
attribute in <xref linkend='ex-hello-nix' />, but
|
||||
<varname>mkDerivation</varname> adds it automatically.)</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-2'>
|
||||
|
||||
<para>Since Hello needs Perl, we have to make sure that Perl is in
|
||||
the <envar>PATH</envar>. The <envar>perl</envar> environment
|
||||
variable points to the location of the Perl package (since it
|
||||
was passed in as an attribute to the derivation), so
|
||||
<filename><replaceable>$perl</replaceable>/bin</filename> is the
|
||||
directory containing the Perl interpreter.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-3'>
|
||||
|
||||
<para>Now we have to unpack the sources. The
|
||||
<varname>src</varname> attribute was bound to the result of
|
||||
fetching the Hello source tarball from the network, so the
|
||||
<envar>src</envar> environment variable points to the location in
|
||||
the Nix store to which the tarball was downloaded. After
|
||||
unpacking, we <command>cd</command> to the resulting source
|
||||
directory.</para>
|
||||
|
||||
<para>The whole build is performed in a temporary directory
|
||||
created in <varname>/tmp</varname>, by the way. This directory is
|
||||
removed after the builder finishes, so there is no need to clean
|
||||
up the sources afterwards. Also, the temporary directory is
|
||||
always newly created, so you don't have to worry about files from
|
||||
previous builds interfering with the current build.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-4'>
|
||||
|
||||
<para>GNU Hello is a typical Autoconf-based package, so we first
|
||||
have to run its <filename>configure</filename> script. In Nix
|
||||
every package is stored in a separate location in the Nix store,
|
||||
for instance
|
||||
<filename>/nix/store/9a54ba97fb71b65fda531012d0443ce2-hello-2.1.1</filename>.
|
||||
Nix computes this path by cryptographically hashing all attributes
|
||||
of the derivation. The path is passed to the builder through the
|
||||
<envar>out</envar> environment variable. So here we give
|
||||
<filename>configure</filename> the parameter
|
||||
<literal>--prefix=$out</literal> to cause Hello to be installed in
|
||||
the expected location.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-5'>
|
||||
|
||||
<para>Finally we build Hello (<literal>make</literal>) and install
|
||||
it into the location specified by <envar>out</envar>
|
||||
(<literal>make install</literal>).</para>
|
||||
|
||||
</callout>
|
||||
|
||||
</calloutlist>
|
||||
|
||||
<para>If you are wondering about the absence of error checking on the
|
||||
result of various commands called in the builder: this is because the
|
||||
shell script is evaluated with Bash's <option>-e</option> option,
|
||||
which causes the script to be aborted if any command fails without an
|
||||
error check.</para>
|
||||
|
||||
</section>
|
||||
|
|
@ -1,119 +0,0 @@
|
|||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='sec-builder-syntax'>
|
||||
|
||||
<title>Builder Syntax</title>
|
||||
|
||||
<example xml:id='ex-hello-builder'><title>Build script for GNU Hello
|
||||
(<filename>builder.sh</filename>)</title>
|
||||
<programlisting>
|
||||
source $stdenv/setup <co xml:id='ex-hello-builder-co-1' />
|
||||
|
||||
PATH=$perl/bin:$PATH <co xml:id='ex-hello-builder-co-2' />
|
||||
|
||||
tar xvfz $src <co xml:id='ex-hello-builder-co-3' />
|
||||
cd hello-*
|
||||
./configure --prefix=$out <co xml:id='ex-hello-builder-co-4' />
|
||||
make <co xml:id='ex-hello-builder-co-5' />
|
||||
make install</programlisting>
|
||||
</example>
|
||||
|
||||
<para><xref linkend='ex-hello-builder' /> shows the builder referenced
|
||||
from Hello's Nix expression (stored in
|
||||
<filename>pkgs/applications/misc/hello/ex-1/builder.sh</filename>).
|
||||
The builder can actually be made a lot shorter by using the
|
||||
<emphasis>generic builder</emphasis> functions provided by
|
||||
<varname>stdenv</varname>, but here we write out the build steps to
|
||||
elucidate what a builder does. It performs the following
|
||||
steps:</para>
|
||||
|
||||
<calloutlist>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-1'>
|
||||
|
||||
<para>When Nix runs a builder, it initially completely clears the
|
||||
environment (except for the attributes declared in the
|
||||
derivation). For instance, the <envar>PATH</envar> variable is
|
||||
empty<footnote><para>Actually, it's initialised to
|
||||
<filename>/path-not-set</filename> to prevent Bash from setting it
|
||||
to a default value.</para></footnote>. This is done to prevent
|
||||
undeclared inputs from being used in the build process. If for
|
||||
example the <envar>PATH</envar> contained
|
||||
<filename>/usr/bin</filename>, then you might accidentally use
|
||||
<filename>/usr/bin/gcc</filename>.</para>
|
||||
|
||||
<para>So the first step is to set up the environment. This is
|
||||
done by calling the <filename>setup</filename> script of the
|
||||
standard environment. The environment variable
|
||||
<envar>stdenv</envar> points to the location of the standard
|
||||
environment being used. (It wasn't specified explicitly as an
|
||||
attribute in <xref linkend='ex-hello-nix' />, but
|
||||
<varname>mkDerivation</varname> adds it automatically.)</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-2'>
|
||||
|
||||
<para>Since Hello needs Perl, we have to make sure that Perl is in
|
||||
the <envar>PATH</envar>. The <envar>perl</envar> environment
|
||||
variable points to the location of the Perl package (since it
|
||||
was passed in as an attribute to the derivation), so
|
||||
<filename><replaceable>$perl</replaceable>/bin</filename> is the
|
||||
directory containing the Perl interpreter.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-3'>
|
||||
|
||||
<para>Now we have to unpack the sources. The
|
||||
<varname>src</varname> attribute was bound to the result of
|
||||
fetching the Hello source tarball from the network, so the
|
||||
<envar>src</envar> environment variable points to the location in
|
||||
the Nix store to which the tarball was downloaded. After
|
||||
unpacking, we <command>cd</command> to the resulting source
|
||||
directory.</para>
|
||||
|
||||
<para>The whole build is performed in a temporary directory
|
||||
created in <varname>/tmp</varname>, by the way. This directory is
|
||||
removed after the builder finishes, so there is no need to clean
|
||||
up the sources afterwards. Also, the temporary directory is
|
||||
always newly created, so you don't have to worry about files from
|
||||
previous builds interfering with the current build.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-4'>
|
||||
|
||||
<para>GNU Hello is a typical Autoconf-based package, so we first
|
||||
have to run its <filename>configure</filename> script. In Nix
|
||||
every package is stored in a separate location in the Nix store,
|
||||
for instance
|
||||
<filename>/nix/store/9a54ba97fb71b65fda531012d0443ce2-hello-2.1.1</filename>.
|
||||
Nix computes this path by cryptographically hashing all attributes
|
||||
of the derivation. The path is passed to the builder through the
|
||||
<envar>out</envar> environment variable. So here we give
|
||||
<filename>configure</filename> the parameter
|
||||
<literal>--prefix=$out</literal> to cause Hello to be installed in
|
||||
the expected location.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-5'>
|
||||
|
||||
<para>Finally we build Hello (<literal>make</literal>) and install
|
||||
it into the location specified by <envar>out</envar>
|
||||
(<literal>make install</literal>).</para>
|
||||
|
||||
</callout>
|
||||
|
||||
</calloutlist>
|
||||
|
||||
<para>If you are wondering about the absence of error checking on the
|
||||
result of various commands called in the builder: this is because the
|
||||
shell script is evaluated with Bash's <option>-e</option> option,
|
||||
which causes the script to be aborted if any command fails without an
|
||||
error check.</para>
|
||||
|
||||
</section>
|
||||
File diff suppressed because it is too large
Load diff
|
|
@ -1,211 +0,0 @@
|
|||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ssec-derivation">
|
||||
|
||||
<title>Derivations</title>
|
||||
|
||||
<para>The most important built-in function is
|
||||
<function>derivation</function>, which is used to describe a single
|
||||
derivation (a build action). It takes as input a set, the attributes
|
||||
of which specify the inputs of the build.</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem xml:id="attr-system"><para>There must be an attribute named
|
||||
<varname>system</varname> whose value must be a string specifying a
|
||||
Nix platform identifier, such as <literal>"i686-linux"</literal> or
|
||||
<literal>"x86_64-darwin"</literal><footnote><para>To figure out
|
||||
your platform identifier, look at the line <quote>Checking for the
|
||||
canonical Nix system name</quote> in the output of Nix's
|
||||
<filename>configure</filename> script.</para></footnote> The build
|
||||
can only be performed on a machine and operating system matching the
|
||||
platform identifier. (Nix can automatically forward builds for
|
||||
other platforms by forwarding them to other machines; see <xref
|
||||
linkend='chap-distributed-builds' />.)</para></listitem>
|
||||
|
||||
<listitem><para>There must be an attribute named
|
||||
<varname>name</varname> whose value must be a string. This is used
|
||||
as a symbolic name for the package by <command>nix-env</command>,
|
||||
and it is appended to the output paths of the
|
||||
derivation.</para></listitem>
|
||||
|
||||
<listitem><para>There must be an attribute named
|
||||
<varname>builder</varname> that identifies the program that is
|
||||
executed to perform the build. It can be either a derivation or a
|
||||
source (a local file reference, e.g.,
|
||||
<filename>./builder.sh</filename>).</para></listitem>
|
||||
|
||||
<listitem><para>Every attribute is passed as an environment variable
|
||||
to the builder. Attribute values are translated to environment
|
||||
variables as follows:
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para>Strings and numbers are just passed
|
||||
verbatim.</para></listitem>
|
||||
|
||||
<listitem><para>A <emphasis>path</emphasis> (e.g.,
|
||||
<filename>../foo/sources.tar</filename>) causes the referenced
|
||||
file to be copied to the store; its location in the store is put
|
||||
in the environment variable. The idea is that all sources
|
||||
should reside in the Nix store, since all inputs to a derivation
|
||||
should reside in the Nix store.</para></listitem>
|
||||
|
||||
<listitem><para>A <emphasis>derivation</emphasis> causes that
|
||||
derivation to be built prior to the present derivation; its
|
||||
default output path is put in the environment
|
||||
variable.</para></listitem>
|
||||
|
||||
<listitem><para>Lists of the previous types are also allowed.
|
||||
They are simply concatenated, separated by
|
||||
spaces.</para></listitem>
|
||||
|
||||
<listitem><para><literal>true</literal> is passed as the string
|
||||
<literal>1</literal>, <literal>false</literal> and
|
||||
<literal>null</literal> are passed as an empty string.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>The optional attribute <varname>args</varname>
|
||||
specifies command-line arguments to be passed to the builder. It
|
||||
should be a list.</para></listitem>
|
||||
|
||||
<listitem><para>The optional attribute <varname>outputs</varname>
|
||||
specifies a list of symbolic outputs of the derivation. By default,
|
||||
a derivation produces a single output path, denoted as
|
||||
<literal>out</literal>. However, derivations can produce multiple
|
||||
output paths. This is useful because it allows outputs to be
|
||||
downloaded or garbage-collected separately. For instance, imagine a
|
||||
library package that provides a dynamic library, header files, and
|
||||
documentation. A program that links against the library doesn’t
|
||||
need the header files and documentation at runtime, and it doesn’t
|
||||
need the documentation at build time. Thus, the library package
|
||||
could specify:
|
||||
<programlisting>
|
||||
outputs = [ "lib" "headers" "doc" ];
|
||||
</programlisting>
|
||||
This will cause Nix to pass environment variables
|
||||
<literal>lib</literal>, <literal>headers</literal> and
|
||||
<literal>doc</literal> to the builder containing the intended store
|
||||
paths of each output. The builder would typically do something like
|
||||
<programlisting>
|
||||
./configure --libdir=$lib/lib --includedir=$headers/include --docdir=$doc/share/doc
|
||||
</programlisting>
|
||||
for an Autoconf-style package. You can refer to each output of a
|
||||
derivation by selecting it as an attribute, e.g.
|
||||
<programlisting>
|
||||
buildInputs = [ pkg.lib pkg.headers ];
|
||||
</programlisting>
|
||||
The first element of <varname>outputs</varname> determines the
|
||||
<emphasis>default output</emphasis>. Thus, you could also write
|
||||
<programlisting>
|
||||
buildInputs = [ pkg pkg.headers ];
|
||||
</programlisting>
|
||||
since <literal>pkg</literal> is equivalent to
|
||||
<literal>pkg.lib</literal>.</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
<para>The function <function>mkDerivation</function> in the Nixpkgs
|
||||
standard environment is a wrapper around
|
||||
<function>derivation</function> that adds a default value for
|
||||
<varname>system</varname> and always uses Bash as the builder, to
|
||||
which the supplied builder is passed as a command-line argument. See
|
||||
the Nixpkgs manual for details.</para>
|
||||
|
||||
<para>The builder is executed as follows:
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para>A temporary directory is created under the directory
|
||||
specified by <envar>TMPDIR</envar> (default
|
||||
<filename>/tmp</filename>) where the build will take place. The
|
||||
current directory is changed to this directory.</para></listitem>
|
||||
|
||||
<listitem><para>The environment is cleared and set to the derivation
|
||||
attributes, as specified above.</para></listitem>
|
||||
|
||||
<listitem><para>In addition, the following variables are set:
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para><envar>NIX_BUILD_TOP</envar> contains the path of
|
||||
the temporary directory for this build.</para></listitem>
|
||||
|
||||
<listitem><para>Also, <envar>TMPDIR</envar>,
|
||||
<envar>TEMPDIR</envar>, <envar>TMP</envar>, <envar>TEMP</envar>
|
||||
are set to point to the temporary directory. This is to prevent
|
||||
the builder from accidentally writing temporary files anywhere
|
||||
else. Doing so might cause interference by other
|
||||
processes.</para></listitem>
|
||||
|
||||
<listitem><para><envar>PATH</envar> is set to
|
||||
<filename>/path-not-set</filename> to prevent shells from
|
||||
initialising it to their built-in default value.</para></listitem>
|
||||
|
||||
<listitem><para><envar>HOME</envar> is set to
|
||||
<filename>/homeless-shelter</filename> to prevent programs from
|
||||
using <filename>/etc/passwd</filename> or the like to find the
|
||||
user's home directory, which could cause impurity. Usually, when
|
||||
<envar>HOME</envar> is set, it is used as the location of the home
|
||||
directory, even if it points to a non-existent
|
||||
path.</para></listitem>
|
||||
|
||||
<listitem><para><envar>NIX_STORE</envar> is set to the path of the
|
||||
top-level Nix store directory (typically,
|
||||
<filename>/nix/store</filename>).</para></listitem>
|
||||
|
||||
<listitem><para>For each output declared in
|
||||
<varname>outputs</varname>, the corresponding environment variable
|
||||
is set to point to the intended path in the Nix store for that
|
||||
output. Each output path is a concatenation of the cryptographic
|
||||
hash of all build inputs, the <varname>name</varname> attribute
|
||||
and the output name. (The output name is omitted if it’s
|
||||
<literal>out</literal>.)</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>If an output path already exists, it is removed.
|
||||
Also, locks are acquired to prevent multiple Nix instances from
|
||||
performing the same build at the same time.</para></listitem>
|
||||
|
||||
<listitem><para>A log of the combined standard output and error is
|
||||
written to <filename>/nix/var/log/nix</filename>.</para></listitem>
|
||||
|
||||
<listitem><para>The builder is executed with the arguments specified
|
||||
by the attribute <varname>args</varname>. If it exits with exit
|
||||
code 0, it is considered to have succeeded.</para></listitem>
|
||||
|
||||
<listitem><para>The temporary directory is removed (unless the
|
||||
<option>-K</option> option was specified).</para></listitem>
|
||||
|
||||
<listitem><para>If the build was successful, Nix scans each output
|
||||
path for references to input paths by looking for the hash parts of
|
||||
the input paths. Since these are potential runtime dependencies,
|
||||
Nix registers them as dependencies of the output
|
||||
paths.</para></listitem>
|
||||
|
||||
<listitem><para>After the build, Nix sets the last-modified
|
||||
timestamp on all files in the build result to 1 (00:00:01 1/1/1970
|
||||
UTC), sets the group to the default group, and sets the mode of the
|
||||
file to 0444 or 0555 (i.e., read-only, with execute permission
|
||||
enabled if the file was originally executable). Note that possible
|
||||
<literal>setuid</literal> and <literal>setgid</literal> bits are
|
||||
cleared. Setuid and setgid programs are not currently supported by
|
||||
Nix. This is because the Nix archives used in deployment have no
|
||||
concept of ownership information, and because it makes the build
|
||||
result dependent on the user performing the build.</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</para>
|
||||
|
||||
<xi:include href="advanced-attributes.xml" />
|
||||
|
||||
</section>
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-expression-language">
|
||||
|
||||
<title>Nix Expression Language</title>
|
||||
|
||||
<para>The Nix expression language is a pure, lazy, functional
|
||||
language. Purity means that operations in the language don't have
|
||||
side-effects (for instance, there is no variable assignment).
|
||||
Laziness means that arguments to functions are evaluated only when
|
||||
they are needed. Functional means that functions are
|
||||
<quote>normal</quote> values that can be passed around and manipulated
|
||||
in interesting ways. The language is not a full-featured, general
|
||||
purpose language. Its main job is to describe packages,
|
||||
compositions of packages, and the variability within
|
||||
packages.</para>
|
||||
|
||||
<para>This section presents the various features of the
|
||||
language.</para>
|
||||
|
||||
<xi:include href="language-values.xml" />
|
||||
<xi:include href="language-constructs.xml" />
|
||||
<xi:include href="language-operators.xml" />
|
||||
<xi:include href="derivations.xml" />
|
||||
<xi:include href="builtins.xml" />
|
||||
|
||||
|
||||
</chapter>
|
||||
|
|
@ -1,148 +0,0 @@
|
|||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='sec-expression-syntax'>
|
||||
|
||||
<title>Expression Syntax</title>
|
||||
|
||||
<example xml:id='ex-hello-nix'><title>Nix expression for GNU Hello
|
||||
(<filename>default.nix</filename>)</title>
|
||||
<programlisting>
|
||||
{ stdenv, fetchurl, perl }: <co xml:id='ex-hello-nix-co-1' />
|
||||
|
||||
stdenv.mkDerivation { <co xml:id='ex-hello-nix-co-2' />
|
||||
name = "hello-2.1.1"; <co xml:id='ex-hello-nix-co-3' />
|
||||
builder = ./builder.sh; <co xml:id='ex-hello-nix-co-4' />
|
||||
src = fetchurl { <co xml:id='ex-hello-nix-co-5' />
|
||||
url = ftp://ftp.nluug.nl/pub/gnu/hello/hello-2.1.1.tar.gz;
|
||||
sha256 = "1md7jsfd8pa45z73bz1kszpp01yw6x5ljkjk2hx7wl800any6465";
|
||||
};
|
||||
inherit perl; <co xml:id='ex-hello-nix-co-6' />
|
||||
}</programlisting>
|
||||
</example>
|
||||
|
||||
<para><xref linkend='ex-hello-nix' /> shows a Nix expression for GNU
|
||||
Hello. It's actually already in the Nix Packages collection in
|
||||
<filename>pkgs/applications/misc/hello/ex-1/default.nix</filename>.
|
||||
It is customary to place each package in a separate directory and call
|
||||
the single Nix expression in that directory
|
||||
<filename>default.nix</filename>. The file has the following elements
|
||||
(referenced from the figure by number):
|
||||
|
||||
<calloutlist>
|
||||
|
||||
<callout arearefs='ex-hello-nix-co-1'>
|
||||
|
||||
<para>This states that the expression is a
|
||||
<emphasis>function</emphasis> that expects to be called with three
|
||||
arguments: <varname>stdenv</varname>, <varname>fetchurl</varname>,
|
||||
and <varname>perl</varname>. They are needed to build Hello, but
|
||||
we don't know how to build them here; that's why they are function
|
||||
arguments. <varname>stdenv</varname> is a package that is used
|
||||
by almost all Nix Packages packages; it provides a
|
||||
<quote>standard</quote> environment consisting of the things you
|
||||
would expect in a basic Unix environment: a C/C++ compiler (GCC,
|
||||
to be precise), the Bash shell, fundamental Unix tools such as
|
||||
<command>cp</command>, <command>grep</command>,
|
||||
<command>tar</command>, etc. <varname>fetchurl</varname> is a
|
||||
function that downloads files. <varname>perl</varname> is the
|
||||
Perl interpreter.</para>
|
||||
|
||||
<para>Nix functions generally have the form <literal>{ x, y, ...,
|
||||
z }: e</literal> where <varname>x</varname>, <varname>y</varname>,
|
||||
etc. are the names of the expected arguments, and where
|
||||
<replaceable>e</replaceable> is the body of the function. So
|
||||
here, the entire remainder of the file is the body of the
|
||||
function; when given the required arguments, the body should
|
||||
describe how to build an instance of the Hello package.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-nix-co-2'>
|
||||
|
||||
<para>So we have to build a package. Building something from
|
||||
other stuff is called a <emphasis>derivation</emphasis> in Nix (as
|
||||
opposed to sources, which are built by humans instead of
|
||||
computers). We perform a derivation by calling
|
||||
<varname>stdenv.mkDerivation</varname>.
|
||||
<varname>mkDerivation</varname> is a function provided by
|
||||
<varname>stdenv</varname> that builds a package from a set of
|
||||
<emphasis>attributes</emphasis>. A set is just a list of
|
||||
key/value pairs where each key is a string and each value is an
|
||||
arbitrary Nix expression. They take the general form <literal>{
|
||||
<replaceable>name1</replaceable> =
|
||||
<replaceable>expr1</replaceable>; <replaceable>...</replaceable>
|
||||
<replaceable>nameN</replaceable> =
|
||||
<replaceable>exprN</replaceable>; }</literal>.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-nix-co-3'>
|
||||
|
||||
<para>The attribute <varname>name</varname> specifies the symbolic
|
||||
name and version of the package. Nix doesn't really care about
|
||||
these things, but they are used by for instance <command>nix-env
|
||||
-q</command> to show a <quote>human-readable</quote> name for
|
||||
packages. This attribute is required by
|
||||
<varname>mkDerivation</varname>.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-nix-co-4'>
|
||||
|
||||
<para>The attribute <varname>builder</varname> specifies the
|
||||
builder. This attribute can sometimes be omitted, in which case
|
||||
<varname>mkDerivation</varname> will fill in a default builder
|
||||
(which does a <literal>configure; make; make install</literal>, in
|
||||
essence). Hello is sufficiently simple that the default builder
|
||||
would suffice, but in this case, we will show an actual builder
|
||||
for educational purposes. The value
|
||||
<command>./builder.sh</command> refers to the shell script shown
|
||||
in <xref linkend='ex-hello-builder' />, discussed below.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-nix-co-5'>
|
||||
|
||||
<para>The builder has to know what the sources of the package
|
||||
are. Here, the attribute <varname>src</varname> is bound to the
|
||||
result of a call to the <command>fetchurl</command> function.
|
||||
Given a URL and a SHA-256 hash of the expected contents of the file
|
||||
at that URL, this function builds a derivation that downloads the
|
||||
file and checks its hash. So the sources are a dependency that
|
||||
like all other dependencies is built before Hello itself is
|
||||
built.</para>
|
||||
|
||||
<para>Instead of <varname>src</varname> any other name could have
|
||||
been used, and in fact there can be any number of sources (bound
|
||||
to different attributes). However, <varname>src</varname> is
|
||||
customary, and it's also expected by the default builder (which we
|
||||
don't use in this example).</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-nix-co-6'>
|
||||
|
||||
<para>Since the derivation requires Perl, we have to pass the
|
||||
value of the <varname>perl</varname> function argument to the
|
||||
builder. All attributes in the set are actually passed as
|
||||
environment variables to the builder, so declaring an attribute
|
||||
|
||||
<programlisting>
|
||||
perl = perl;</programlisting>
|
||||
|
||||
will do the trick: it binds an attribute <varname>perl</varname>
|
||||
to the function argument which also happens to be called
|
||||
<varname>perl</varname>. However, it looks a bit silly, so there
|
||||
is a shorter syntax. The <literal>inherit</literal> keyword
|
||||
causes the specified attributes to be bound to whatever variables
|
||||
with the same name happen to be in scope.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
</calloutlist>
|
||||
|
||||
</para>
|
||||
|
||||
</section>
|
||||
|
|
@ -1,98 +0,0 @@
|
|||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='sec-generic-builder'>
|
||||
|
||||
<title>Generic Builder Syntax</title>
|
||||
|
||||
<para>Recall from <xref linkend='ex-hello-builder' /> that the builder
|
||||
looked something like this:
|
||||
|
||||
<programlisting>
|
||||
PATH=$perl/bin:$PATH
|
||||
tar xvfz $src
|
||||
cd hello-*
|
||||
./configure --prefix=$out
|
||||
make
|
||||
make install</programlisting>
|
||||
|
||||
The builders for almost all Unix packages look like this — set up some
|
||||
environment variables, unpack the sources, configure, build, and
|
||||
install. For this reason the standard environment provides some Bash
|
||||
functions that automate the build process. A builder using the
|
||||
generic build facilities in shown in <xref linkend='ex-hello-builder2'
|
||||
/>.</para>
|
||||
|
||||
<example xml:id='ex-hello-builder2'><title>Build script using the generic
|
||||
build functions</title>
|
||||
<programlisting>
|
||||
buildInputs="$perl" <co xml:id='ex-hello-builder2-co-1' />
|
||||
|
||||
source $stdenv/setup <co xml:id='ex-hello-builder2-co-2' />
|
||||
|
||||
genericBuild <co xml:id='ex-hello-builder2-co-3' /></programlisting>
|
||||
</example>
|
||||
|
||||
<calloutlist>
|
||||
|
||||
<callout arearefs='ex-hello-builder2-co-1'>
|
||||
|
||||
<para>The <envar>buildInputs</envar> variable tells
|
||||
<filename>setup</filename> to use the indicated packages as
|
||||
<quote>inputs</quote>. This means that if a package provides a
|
||||
<filename>bin</filename> subdirectory, it's added to
|
||||
<envar>PATH</envar>; if it has a <filename>include</filename>
|
||||
subdirectory, it's added to GCC's header search path; and so
|
||||
on.<footnote><para>How does it work? <filename>setup</filename>
|
||||
tries to source the file
|
||||
<filename><replaceable>pkg</replaceable>/nix-support/setup-hook</filename>
|
||||
of all dependencies. These “setup hooks” can then set up whatever
|
||||
environment variables they want; for instance, the setup hook for
|
||||
Perl sets the <envar>PERL5LIB</envar> environment variable to
|
||||
contain the <filename>lib/site_perl</filename> directories of all
|
||||
inputs.</para></footnote>
|
||||
</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder2-co-2'>
|
||||
|
||||
<para>The function <function>genericBuild</function> is defined in
|
||||
the file <literal>$stdenv/setup</literal>.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder2-co-3'>
|
||||
|
||||
<para>The final step calls the shell function
|
||||
<function>genericBuild</function>, which performs the steps that
|
||||
were done explicitly in <xref linkend='ex-hello-builder' />. The
|
||||
generic builder is smart enough to figure out whether to unpack
|
||||
the sources using <command>gzip</command>,
|
||||
<command>bzip2</command>, etc. It can be customised in many ways;
|
||||
see the Nixpkgs manual for details.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
</calloutlist>
|
||||
|
||||
<para>Discerning readers will note that the
|
||||
<envar>buildInputs</envar> could just as well have been set in the Nix
|
||||
expression, like this:
|
||||
|
||||
<programlisting>
|
||||
buildInputs = [ perl ];</programlisting>
|
||||
|
||||
The <varname>perl</varname> attribute can then be removed, and the
|
||||
builder becomes even shorter:
|
||||
|
||||
<programlisting>
|
||||
source $stdenv/setup
|
||||
genericBuild</programlisting>
|
||||
|
||||
In fact, <varname>mkDerivation</varname> provides a default builder
|
||||
that looks exactly like that, so it is actually possible to omit the
|
||||
builder for Hello entirely.</para>
|
||||
|
||||
</section>
|
||||
|
|
@ -1,391 +0,0 @@
|
|||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-constructs">
|
||||
|
||||
<title>Language Constructs</title>
|
||||
|
||||
<simplesect><title>Recursive sets</title>
|
||||
|
||||
<para>Recursive sets are just normal sets, but the attributes can
|
||||
refer to each other. For example,
|
||||
|
||||
<programlisting>
|
||||
rec {
|
||||
x = y;
|
||||
y = 123;
|
||||
}.x
|
||||
</programlisting>
|
||||
|
||||
evaluates to <literal>123</literal>. Note that without
|
||||
<literal>rec</literal> the binding <literal>x = y;</literal> would
|
||||
refer to the variable <varname>y</varname> in the surrounding scope,
|
||||
if one exists, and would be invalid if no such variable exists. That
|
||||
is, in a normal (non-recursive) set, attributes are not added to the
|
||||
lexical scope; in a recursive set, they are.</para>
|
||||
|
||||
<para>Recursive sets of course introduce the danger of infinite
|
||||
recursion. For example,
|
||||
|
||||
<programlisting>
|
||||
rec {
|
||||
x = y;
|
||||
y = x;
|
||||
}.x</programlisting>
|
||||
|
||||
does not terminate<footnote><para>Actually, Nix detects infinite
|
||||
recursion in this case and aborts (<quote>infinite recursion
|
||||
encountered</quote>).</para></footnote>.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect xml:id="sect-let-expressions"><title>Let-expressions</title>
|
||||
|
||||
<para>A let-expression allows you define local variables for an
|
||||
expression. For instance,
|
||||
|
||||
<programlisting>
|
||||
let
|
||||
x = "foo";
|
||||
y = "bar";
|
||||
in x + y</programlisting>
|
||||
|
||||
evaluates to <literal>"foobar"</literal>.
|
||||
|
||||
</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Inheriting attributes</title>
|
||||
|
||||
<para>When defining a set or in a let-expression it is often convenient to copy variables
|
||||
from the surrounding lexical scope (e.g., when you want to propagate
|
||||
attributes). This can be shortened using the
|
||||
<literal>inherit</literal> keyword. For instance,
|
||||
|
||||
<programlisting>
|
||||
let x = 123; in
|
||||
{ inherit x;
|
||||
y = 456;
|
||||
}</programlisting>
|
||||
|
||||
is equivalent to
|
||||
|
||||
<programlisting>
|
||||
let x = 123; in
|
||||
{ x = x;
|
||||
y = 456;
|
||||
}</programlisting>
|
||||
|
||||
and both evaluate to <literal>{ x = 123; y = 456; }</literal>. (Note that
|
||||
this works because <varname>x</varname> is added to the lexical scope
|
||||
by the <literal>let</literal> construct.) It is also possible to
|
||||
inherit attributes from another set. For instance, in this fragment
|
||||
from <filename>all-packages.nix</filename>,
|
||||
|
||||
<programlisting>
|
||||
graphviz = (import ../tools/graphics/graphviz) {
|
||||
inherit fetchurl stdenv libpng libjpeg expat x11 yacc;
|
||||
inherit (xlibs) libXaw;
|
||||
};
|
||||
|
||||
xlibs = {
|
||||
libX11 = ...;
|
||||
libXaw = ...;
|
||||
...
|
||||
}
|
||||
|
||||
libpng = ...;
|
||||
libjpg = ...;
|
||||
...</programlisting>
|
||||
|
||||
the set used in the function call to the function defined in
|
||||
<filename>../tools/graphics/graphviz</filename> inherits a number of
|
||||
variables from the surrounding scope (<varname>fetchurl</varname>
|
||||
... <varname>yacc</varname>), but also inherits
|
||||
<varname>libXaw</varname> (the X Athena Widgets) from the
|
||||
<varname>xlibs</varname> (X11 client-side libraries) set.</para>
|
||||
|
||||
<para>
|
||||
Summarizing the fragment
|
||||
|
||||
<programlisting>
|
||||
...
|
||||
inherit x y z;
|
||||
inherit (src-set) a b c;
|
||||
...</programlisting>
|
||||
|
||||
is equivalent to
|
||||
|
||||
<programlisting>
|
||||
...
|
||||
x = x; y = y; z = z;
|
||||
a = src-set.a; b = src-set.b; c = src-set.c;
|
||||
...</programlisting>
|
||||
|
||||
when used while defining local variables in a let-expression or
|
||||
while defining a set.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect xml:id="ss-functions"><title>Functions</title>
|
||||
|
||||
<para>Functions have the following form:
|
||||
|
||||
<programlisting>
|
||||
<replaceable>pattern</replaceable>: <replaceable>body</replaceable></programlisting>
|
||||
|
||||
The pattern specifies what the argument of the function must look
|
||||
like, and binds variables in the body to (parts of) the
|
||||
argument. There are three kinds of patterns:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
|
||||
<listitem><para>If a pattern is a single identifier, then the
|
||||
function matches any argument. Example:
|
||||
|
||||
<programlisting>
|
||||
let negate = x: !x;
|
||||
concat = x: y: x + y;
|
||||
in if negate true then concat "foo" "bar" else ""</programlisting>
|
||||
|
||||
Note that <function>concat</function> is a function that takes one
|
||||
argument and returns a function that takes another argument. This
|
||||
allows partial parameterisation (i.e., only filling some of the
|
||||
arguments of a function); e.g.,
|
||||
|
||||
<programlisting>
|
||||
map (concat "foo") [ "bar" "bla" "abc" ]</programlisting>
|
||||
|
||||
evaluates to <literal>[ "foobar" "foobla"
|
||||
"fooabc" ]</literal>.</para></listitem>
|
||||
|
||||
|
||||
<listitem><para>A <emphasis>set pattern</emphasis> of the form
|
||||
<literal>{ name1, name2, …, nameN }</literal> matches a set
|
||||
containing the listed attributes, and binds the values of those
|
||||
attributes to variables in the function body. For example, the
|
||||
function
|
||||
|
||||
<programlisting>
|
||||
{ x, y, z }: z + y + x</programlisting>
|
||||
|
||||
can only be called with a set containing exactly the attributes
|
||||
<varname>x</varname>, <varname>y</varname> and
|
||||
<varname>z</varname>. No other attributes are allowed. If you want
|
||||
to allow additional arguments, you can use an ellipsis
|
||||
(<literal>...</literal>):
|
||||
|
||||
<programlisting>
|
||||
{ x, y, z, ... }: z + y + x</programlisting>
|
||||
|
||||
This works on any set that contains at least the three named
|
||||
attributes.</para>
|
||||
|
||||
<para>It is possible to provide <emphasis>default values</emphasis>
|
||||
for attributes, in which case they are allowed to be missing. A
|
||||
default value is specified by writing
|
||||
<literal><replaceable>name</replaceable> ?
|
||||
<replaceable>e</replaceable></literal>, where
|
||||
<replaceable>e</replaceable> is an arbitrary expression. For example,
|
||||
|
||||
<programlisting>
|
||||
{ x, y ? "foo", z ? "bar" }: z + y + x</programlisting>
|
||||
|
||||
specifies a function that only requires an attribute named
|
||||
<varname>x</varname>, but optionally accepts <varname>y</varname>
|
||||
and <varname>z</varname>.</para></listitem>
|
||||
|
||||
|
||||
<listitem><para>An <literal>@</literal>-pattern provides a means of referring
|
||||
to the whole value being matched:
|
||||
|
||||
<programlisting> args@{ x, y, z, ... }: z + y + x + args.a</programlisting>
|
||||
|
||||
but can also be written as:
|
||||
|
||||
<programlisting> { x, y, z, ... } @ args: z + y + x + args.a</programlisting>
|
||||
|
||||
Here <varname>args</varname> is bound to the entire argument, which
|
||||
is further matched against the pattern <literal>{ x, y, z,
|
||||
... }</literal>. <literal>@</literal>-pattern makes mainly sense with an
|
||||
ellipsis(<literal>...</literal>) as you can access attribute names as
|
||||
<literal>a</literal>, using <literal>args.a</literal>, which was given as an
|
||||
additional attribute to the function.
|
||||
</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
<para>Note that functions do not have names. If you want to give them
|
||||
a name, you can bind them to an attribute, e.g.,
|
||||
|
||||
<programlisting>
|
||||
let concat = { x, y }: x + y;
|
||||
in concat { x = "foo"; y = "bar"; }</programlisting>
|
||||
|
||||
</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Conditionals</title>
|
||||
|
||||
<para>Conditionals look like this:
|
||||
|
||||
<programlisting>
|
||||
if <replaceable>e1</replaceable> then <replaceable>e2</replaceable> else <replaceable>e3</replaceable></programlisting>
|
||||
|
||||
where <replaceable>e1</replaceable> is an expression that should
|
||||
evaluate to a Boolean value (<literal>true</literal> or
|
||||
<literal>false</literal>).</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Assertions</title>
|
||||
|
||||
<para>Assertions are generally used to check that certain requirements
|
||||
on or between features and dependencies hold. They look like this:
|
||||
|
||||
<programlisting>
|
||||
assert <replaceable>e1</replaceable>; <replaceable>e2</replaceable></programlisting>
|
||||
|
||||
where <replaceable>e1</replaceable> is an expression that should
|
||||
evaluate to a Boolean value. If it evaluates to
|
||||
<literal>true</literal>, <replaceable>e2</replaceable> is returned;
|
||||
otherwise expression evaluation is aborted and a backtrace is printed.</para>
|
||||
|
||||
<example xml:id='ex-subversion-nix'><title>Nix expression for Subversion</title>
|
||||
<programlisting>
|
||||
{ localServer ? false
|
||||
, httpServer ? false
|
||||
, sslSupport ? false
|
||||
, pythonBindings ? false
|
||||
, javaSwigBindings ? false
|
||||
, javahlBindings ? false
|
||||
, stdenv, fetchurl
|
||||
, openssl ? null, httpd ? null, db4 ? null, expat, swig ? null, j2sdk ? null
|
||||
}:
|
||||
|
||||
assert localServer -> db4 != null; <co xml:id='ex-subversion-nix-co-1' />
|
||||
assert httpServer -> httpd != null && httpd.expat == expat; <co xml:id='ex-subversion-nix-co-2' />
|
||||
assert sslSupport -> openssl != null && (httpServer -> httpd.openssl == openssl); <co xml:id='ex-subversion-nix-co-3' />
|
||||
assert pythonBindings -> swig != null && swig.pythonSupport;
|
||||
assert javaSwigBindings -> swig != null && swig.javaSupport;
|
||||
assert javahlBindings -> j2sdk != null;
|
||||
|
||||
stdenv.mkDerivation {
|
||||
name = "subversion-1.1.1";
|
||||
...
|
||||
openssl = if sslSupport then openssl else null; <co xml:id='ex-subversion-nix-co-4' />
|
||||
...
|
||||
}</programlisting>
|
||||
</example>
|
||||
|
||||
<para><xref linkend='ex-subversion-nix' /> show how assertions are
|
||||
used in the Nix expression for Subversion.</para>
|
||||
|
||||
<calloutlist>
|
||||
|
||||
<callout arearefs='ex-subversion-nix-co-1'>
|
||||
<para>This assertion states that if Subversion is to have support
|
||||
for local repositories, then Berkeley DB is needed. So if the
|
||||
Subversion function is called with the
|
||||
<varname>localServer</varname> argument set to
|
||||
<literal>true</literal> but the <varname>db4</varname> argument
|
||||
set to <literal>null</literal>, then the evaluation fails.</para>
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-subversion-nix-co-2'>
|
||||
<para>This is a more subtle condition: if Subversion is built with
|
||||
Apache (<literal>httpServer</literal>) support, then the Expat
|
||||
library (an XML library) used by Subversion should be same as the
|
||||
one used by Apache. This is because in this configuration
|
||||
Subversion code ends up being linked with Apache code, and if the
|
||||
Expat libraries do not match, a build- or runtime link error or
|
||||
incompatibility might occur.</para>
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-subversion-nix-co-3'>
|
||||
<para>This assertion says that in order for Subversion to have SSL
|
||||
support (so that it can access <literal>https</literal> URLs), an
|
||||
OpenSSL library must be passed. Additionally, it says that
|
||||
<emphasis>if</emphasis> Apache support is enabled, then Apache's
|
||||
OpenSSL should match Subversion's. (Note that if Apache support
|
||||
is not enabled, we don't care about Apache's OpenSSL.)</para>
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-subversion-nix-co-4'>
|
||||
<para>The conditional here is not really related to assertions,
|
||||
but is worth pointing out: it ensures that if SSL support is
|
||||
disabled, then the Subversion derivation is not dependent on
|
||||
OpenSSL, even if a non-<literal>null</literal> value was passed.
|
||||
This prevents an unnecessary rebuild of Subversion if OpenSSL
|
||||
changes.</para>
|
||||
</callout>
|
||||
|
||||
</calloutlist>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
|
||||
<simplesect><title>With-expressions</title>
|
||||
|
||||
<para>A <emphasis>with-expression</emphasis>,
|
||||
|
||||
<programlisting>
|
||||
with <replaceable>e1</replaceable>; <replaceable>e2</replaceable></programlisting>
|
||||
|
||||
introduces the set <replaceable>e1</replaceable> into the lexical
|
||||
scope of the expression <replaceable>e2</replaceable>. For instance,
|
||||
|
||||
<programlisting>
|
||||
let as = { x = "foo"; y = "bar"; };
|
||||
in with as; x + y</programlisting>
|
||||
|
||||
evaluates to <literal>"foobar"</literal> since the
|
||||
<literal>with</literal> adds the <varname>x</varname> and
|
||||
<varname>y</varname> attributes of <varname>as</varname> to the
|
||||
lexical scope in the expression <literal>x + y</literal>. The most
|
||||
common use of <literal>with</literal> is in conjunction with the
|
||||
<function>import</function> function. E.g.,
|
||||
|
||||
<programlisting>
|
||||
with (import ./definitions.nix); ...</programlisting>
|
||||
|
||||
makes all attributes defined in the file
|
||||
<filename>definitions.nix</filename> available as if they were defined
|
||||
locally in a <literal>let</literal>-expression.</para>
|
||||
|
||||
<para>The bindings introduced by <literal>with</literal> do not shadow bindings
|
||||
introduced by other means, e.g.
|
||||
|
||||
<programlisting>
|
||||
let a = 3; in with { a = 1; }; let a = 4; in with { a = 2; }; ...</programlisting>
|
||||
|
||||
establishes the same scope as
|
||||
|
||||
<programlisting>
|
||||
let a = 1; in let a = 2; in let a = 3; in let a = 4; in ...</programlisting>
|
||||
|
||||
</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Comments</title>
|
||||
|
||||
<para>Comments can be single-line, started with a <literal>#</literal>
|
||||
character, or inline/multi-line, enclosed within <literal>/*
|
||||
... */</literal>.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
</section>
|
||||
|
|
@ -1,135 +0,0 @@
|
|||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-language-operators">
|
||||
|
||||
<title>Operators</title>
|
||||
|
||||
<para><xref linkend='table-operators' /> lists the operators in the
|
||||
Nix expression language, in order of precedence (from strongest to
|
||||
weakest binding).</para>
|
||||
|
||||
<table xml:id='table-operators'>
|
||||
<title>Operators</title>
|
||||
<tgroup cols='3'>
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Syntax</entry>
|
||||
<entry>Associativity</entry>
|
||||
<entry>Description</entry>
|
||||
</row>
|
||||
</thead>
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><replaceable>e</replaceable> <literal>.</literal>
|
||||
<replaceable>attrpath</replaceable>
|
||||
[ <literal>or</literal> <replaceable>def</replaceable> ]
|
||||
</entry>
|
||||
<entry>none</entry>
|
||||
<entry>Select attribute denoted by the attribute path
|
||||
<replaceable>attrpath</replaceable> from set
|
||||
<replaceable>e</replaceable>. (An attribute path is a
|
||||
dot-separated list of attribute names.) If the attribute
|
||||
doesn’t exist, return <replaceable>def</replaceable> if
|
||||
provided, otherwise abort evaluation.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><replaceable>e1</replaceable> <replaceable>e2</replaceable></entry>
|
||||
<entry>left</entry>
|
||||
<entry>Call function <replaceable>e1</replaceable> with
|
||||
argument <replaceable>e2</replaceable>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>-</literal> <replaceable>e</replaceable></entry>
|
||||
<entry>none</entry>
|
||||
<entry>Arithmetic negation.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><replaceable>e</replaceable> <literal>?</literal>
|
||||
<replaceable>attrpath</replaceable></entry>
|
||||
<entry>none</entry>
|
||||
<entry>Test whether set <replaceable>e</replaceable> contains
|
||||
the attribute denoted by <replaceable>attrpath</replaceable>;
|
||||
return <literal>true</literal> or
|
||||
<literal>false</literal>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><replaceable>e1</replaceable> <literal>++</literal> <replaceable>e2</replaceable></entry>
|
||||
<entry>right</entry>
|
||||
<entry>List concatenation.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>
|
||||
<replaceable>e1</replaceable> <literal>*</literal> <replaceable>e2</replaceable>,
|
||||
<replaceable>e1</replaceable> <literal>/</literal> <replaceable>e2</replaceable>
|
||||
</entry>
|
||||
<entry>left</entry>
|
||||
<entry>Arithmetic multiplication and division.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>
|
||||
<replaceable>e1</replaceable> <literal>+</literal> <replaceable>e2</replaceable>,
|
||||
<replaceable>e1</replaceable> <literal>-</literal> <replaceable>e2</replaceable>
|
||||
</entry>
|
||||
<entry>left</entry>
|
||||
<entry>Arithmetic addition and subtraction. String or path concatenation (only by <literal>+</literal>).</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>!</literal> <replaceable>e</replaceable></entry>
|
||||
<entry>none</entry>
|
||||
<entry>Boolean negation.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><replaceable>e1</replaceable> <literal>//</literal>
|
||||
<replaceable>e2</replaceable></entry>
|
||||
<entry>right</entry>
|
||||
<entry>Return a set consisting of the attributes in
|
||||
<replaceable>e1</replaceable> and
|
||||
<replaceable>e2</replaceable> (with the latter taking
|
||||
precedence over the former in case of equally named
|
||||
attributes).</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>
|
||||
<replaceable>e1</replaceable> <literal><</literal> <replaceable>e2</replaceable>,
|
||||
<replaceable>e1</replaceable> <literal>></literal> <replaceable>e2</replaceable>,
|
||||
<replaceable>e1</replaceable> <literal><=</literal> <replaceable>e2</replaceable>,
|
||||
<replaceable>e1</replaceable> <literal>>=</literal> <replaceable>e2</replaceable>
|
||||
</entry>
|
||||
<entry>none</entry>
|
||||
<entry>Arithmetic comparison.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>
|
||||
<replaceable>e1</replaceable> <literal>==</literal> <replaceable>e2</replaceable>,
|
||||
<replaceable>e1</replaceable> <literal>!=</literal> <replaceable>e2</replaceable>
|
||||
</entry>
|
||||
<entry>none</entry>
|
||||
<entry>Equality and inequality.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><replaceable>e1</replaceable> <literal>&&</literal>
|
||||
<replaceable>e2</replaceable></entry>
|
||||
<entry>left</entry>
|
||||
<entry>Logical AND.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><replaceable>e1</replaceable> <literal>||</literal>
|
||||
<replaceable>e2</replaceable></entry>
|
||||
<entry>left</entry>
|
||||
<entry>Logical OR.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><replaceable>e1</replaceable> <literal>-></literal>
|
||||
<replaceable>e2</replaceable></entry>
|
||||
<entry>none</entry>
|
||||
<entry>Logical implication (equivalent to
|
||||
<literal>!<replaceable>e1</replaceable> ||
|
||||
<replaceable>e2</replaceable></literal>).</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
</section>
|
||||
|
|
@ -1,313 +0,0 @@
|
|||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='ssec-values'>
|
||||
|
||||
<title>Values</title>
|
||||
|
||||
|
||||
<simplesect><title>Simple Values</title>
|
||||
|
||||
<para>Nix has the following basic data types:
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para><emphasis>Strings</emphasis> can be written in three
|
||||
ways.</para>
|
||||
|
||||
<para>The most common way is to enclose the string between double
|
||||
quotes, e.g., <literal>"foo bar"</literal>. Strings can span
|
||||
multiple lines. The special characters <literal>"</literal> and
|
||||
<literal>\</literal> and the character sequence
|
||||
<literal>${</literal> must be escaped by prefixing them with a
|
||||
backslash (<literal>\</literal>). Newlines, carriage returns and
|
||||
tabs can be written as <literal>\n</literal>,
|
||||
<literal>\r</literal> and <literal>\t</literal>,
|
||||
respectively.</para>
|
||||
|
||||
<para>You can include the result of an expression into a string by
|
||||
enclosing it in
|
||||
<literal>${<replaceable>...</replaceable>}</literal>, a feature
|
||||
known as <emphasis>antiquotation</emphasis>. The enclosed
|
||||
expression must evaluate to something that can be coerced into a
|
||||
string (meaning that it must be a string, a path, or a
|
||||
derivation). For instance, rather than writing
|
||||
|
||||
<programlisting>
|
||||
"--with-freetype2-library=" + freetype + "/lib"</programlisting>
|
||||
|
||||
(where <varname>freetype</varname> is a derivation), you can
|
||||
instead write the more natural
|
||||
|
||||
<programlisting>
|
||||
"--with-freetype2-library=${freetype}/lib"</programlisting>
|
||||
|
||||
The latter is automatically translated to the former. A more
|
||||
complicated example (from the Nix expression for <link
|
||||
xlink:href='http://www.trolltech.com/products/qt'>Qt</link>):
|
||||
|
||||
<programlisting>
|
||||
configureFlags = "
|
||||
-system-zlib -system-libpng -system-libjpeg
|
||||
${if openglSupport then "-dlopen-opengl
|
||||
-L${mesa}/lib -I${mesa}/include
|
||||
-L${libXmu}/lib -I${libXmu}/include" else ""}
|
||||
${if threadSupport then "-thread" else "-no-thread"}
|
||||
";</programlisting>
|
||||
|
||||
Note that Nix expressions and strings can be arbitrarily nested;
|
||||
in this case the outer string contains various antiquotations that
|
||||
themselves contain strings (e.g., <literal>"-thread"</literal>),
|
||||
some of which in turn contain expressions (e.g.,
|
||||
<literal>${mesa}</literal>).</para>
|
||||
|
||||
<para>The second way to write string literals is as an
|
||||
<emphasis>indented string</emphasis>, which is enclosed between
|
||||
pairs of <emphasis>double single-quotes</emphasis>, like so:
|
||||
|
||||
<programlisting>
|
||||
''
|
||||
This is the first line.
|
||||
This is the second line.
|
||||
This is the third line.
|
||||
''</programlisting>
|
||||
|
||||
This kind of string literal intelligently strips indentation from
|
||||
the start of each line. To be precise, it strips from each line a
|
||||
number of spaces equal to the minimal indentation of the string as
|
||||
a whole (disregarding the indentation of empty lines). For
|
||||
instance, the first and second line are indented two space, while
|
||||
the third line is indented four spaces. Thus, two spaces are
|
||||
stripped from each line, so the resulting string is
|
||||
|
||||
<programlisting>
|
||||
"This is the first line.\nThis is the second line.\n This is the third line.\n"</programlisting>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Note that the whitespace and newline following the opening
|
||||
<literal>''</literal> is ignored if there is no non-whitespace
|
||||
text on the initial line.</para>
|
||||
|
||||
<para>Antiquotation
|
||||
(<literal>${<replaceable>expr</replaceable>}</literal>) is
|
||||
supported in indented strings.</para>
|
||||
|
||||
<para>Since <literal>${</literal> and <literal>''</literal> have
|
||||
special meaning in indented strings, you need a way to quote them.
|
||||
<literal>$</literal> can be escaped by prefixing it with
|
||||
<literal>''</literal> (that is, two single quotes), i.e.,
|
||||
<literal>''$</literal>. <literal>''</literal> can be escaped by
|
||||
prefixing it with <literal>'</literal>, i.e.,
|
||||
<literal>'''</literal>. <literal>$</literal> removes any special meaning
|
||||
from the following <literal>$</literal>. Linefeed, carriage-return and tab
|
||||
characters can be written as <literal>''\n</literal>,
|
||||
<literal>''\r</literal>, <literal>''\t</literal>, and <literal>''\</literal>
|
||||
escapes any other character.
|
||||
|
||||
</para>
|
||||
|
||||
<para>Indented strings are primarily useful in that they allow
|
||||
multi-line string literals to follow the indentation of the
|
||||
enclosing Nix expression, and that less escaping is typically
|
||||
necessary for strings representing languages such as shell scripts
|
||||
and configuration files because <literal>''</literal> is much less
|
||||
common than <literal>"</literal>. Example:
|
||||
|
||||
<programlisting>
|
||||
stdenv.mkDerivation {
|
||||
<replaceable>...</replaceable>
|
||||
postInstall =
|
||||
''
|
||||
mkdir $out/bin $out/etc
|
||||
cp foo $out/bin
|
||||
echo "Hello World" > $out/etc/foo.conf
|
||||
${if enableBar then "cp bar $out/bin" else ""}
|
||||
'';
|
||||
<replaceable>...</replaceable>
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Finally, as a convenience, <emphasis>URIs</emphasis> as
|
||||
defined in appendix B of <link
|
||||
xlink:href='http://www.ietf.org/rfc/rfc2396.txt'>RFC 2396</link>
|
||||
can be written <emphasis>as is</emphasis>, without quotes. For
|
||||
instance, the string
|
||||
<literal>"http://example.org/foo.tar.bz2"</literal>
|
||||
can also be written as
|
||||
<literal>http://example.org/foo.tar.bz2</literal>.</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
<listitem><para>Numbers, which can be <emphasis>integers</emphasis> (like
|
||||
<literal>123</literal>) or <emphasis>floating point</emphasis> (like
|
||||
<literal>123.43</literal> or <literal>.27e13</literal>).</para>
|
||||
|
||||
<para>Numbers are type-compatible: pure integer operations will always
|
||||
return integers, whereas any operation involving at least one floating point
|
||||
number will have a floating point number as a result.</para></listitem>
|
||||
|
||||
<listitem><para><emphasis>Paths</emphasis>, e.g.,
|
||||
<filename>/bin/sh</filename> or <filename>./builder.sh</filename>.
|
||||
A path must contain at least one slash to be recognised as such; for
|
||||
instance, <filename>builder.sh</filename> is not a
|
||||
path<footnote><para>It's parsed as an expression that selects the
|
||||
attribute <varname>sh</varname> from the variable
|
||||
<varname>builder</varname>.</para></footnote>. If the file name is
|
||||
relative, i.e., if it does not begin with a slash, it is made
|
||||
absolute at parse time relative to the directory of the Nix
|
||||
expression that contained it. For instance, if a Nix expression in
|
||||
<filename>/foo/bar/bla.nix</filename> refers to
|
||||
<filename>../xyzzy/fnord.nix</filename>, the absolute path is
|
||||
<filename>/foo/xyzzy/fnord.nix</filename>.</para>
|
||||
|
||||
<para>If the first component of a path is a <literal>~</literal>,
|
||||
it is interpreted as if the rest of the path were relative to the
|
||||
user's home directory. e.g. <filename>~/foo</filename> would be
|
||||
equivalent to <filename>/home/edolstra/foo</filename> for a user
|
||||
whose home directory is <filename>/home/edolstra</filename>.
|
||||
</para>
|
||||
|
||||
<para>Paths can also be specified between angle brackets, e.g.
|
||||
<literal><nixpkgs></literal>. This means that the directories
|
||||
listed in the environment variable
|
||||
<envar linkend="env-NIX_PATH">NIX_PATH</envar> will be searched
|
||||
for the given file or directory name.
|
||||
</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
<listitem><para><emphasis>Booleans</emphasis> with values
|
||||
<literal>true</literal> and
|
||||
<literal>false</literal>.</para></listitem>
|
||||
|
||||
<listitem><para>The null value, denoted as
|
||||
<literal>null</literal>.</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Lists</title>
|
||||
|
||||
<para>Lists are formed by enclosing a whitespace-separated list of
|
||||
values between square brackets. For example,
|
||||
|
||||
<programlisting>
|
||||
[ 123 ./foo.nix "abc" (f { x = y; }) ]</programlisting>
|
||||
|
||||
defines a list of four elements, the last being the result of a call
|
||||
to the function <varname>f</varname>. Note that function calls have
|
||||
to be enclosed in parentheses. If they had been omitted, e.g.,
|
||||
|
||||
<programlisting>
|
||||
[ 123 ./foo.nix "abc" f { x = y; } ]</programlisting>
|
||||
|
||||
the result would be a list of five elements, the fourth one being a
|
||||
function and the fifth being a set.</para>
|
||||
|
||||
<para>Note that lists are only lazy in values, and they are strict in length.
|
||||
</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Sets</title>
|
||||
|
||||
<para>Sets are really the core of the language, since ultimately the
|
||||
Nix language is all about creating derivations, which are really just
|
||||
sets of attributes to be passed to build scripts.</para>
|
||||
|
||||
<para>Sets are just a list of name/value pairs (called
|
||||
<emphasis>attributes</emphasis>) enclosed in curly brackets, where
|
||||
each value is an arbitrary expression terminated by a semicolon. For
|
||||
example:
|
||||
|
||||
<programlisting>
|
||||
{ x = 123;
|
||||
text = "Hello";
|
||||
y = f { bla = 456; };
|
||||
}</programlisting>
|
||||
|
||||
This defines a set with attributes named <varname>x</varname>,
|
||||
<varname>text</varname>, <varname>y</varname>. The order of the
|
||||
attributes is irrelevant. An attribute name may only occur
|
||||
once.</para>
|
||||
|
||||
<para>Attributes can be selected from a set using the
|
||||
<literal>.</literal> operator. For instance,
|
||||
|
||||
<programlisting>
|
||||
{ a = "Foo"; b = "Bar"; }.a</programlisting>
|
||||
|
||||
evaluates to <literal>"Foo"</literal>. It is possible to provide a
|
||||
default value in an attribute selection using the
|
||||
<literal>or</literal> keyword. For example,
|
||||
|
||||
<programlisting>
|
||||
{ a = "Foo"; b = "Bar"; }.c or "Xyzzy"</programlisting>
|
||||
|
||||
will evaluate to <literal>"Xyzzy"</literal> because there is no
|
||||
<varname>c</varname> attribute in the set.</para>
|
||||
|
||||
<para>You can use arbitrary double-quoted strings as attribute
|
||||
names:
|
||||
|
||||
<programlisting>
|
||||
{ "foo ${bar}" = 123; "nix-1.0" = 456; }."foo ${bar}"
|
||||
</programlisting>
|
||||
|
||||
This will evaluate to <literal>123</literal> (Assuming
|
||||
<literal>bar</literal> is antiquotable). In the case where an
|
||||
attribute name is just a single antiquotation, the quotes can be
|
||||
dropped:
|
||||
|
||||
<programlisting>
|
||||
{ foo = 123; }.${bar} or 456 </programlisting>
|
||||
|
||||
This will evaluate to <literal>123</literal> if
|
||||
<literal>bar</literal> evaluates to <literal>"foo"</literal> when
|
||||
coerced to a string and <literal>456</literal> otherwise (again
|
||||
assuming <literal>bar</literal> is antiquotable).</para>
|
||||
|
||||
<para>In the special case where an attribute name inside of a set declaration
|
||||
evaluates to <literal>null</literal> (which is normally an error, as
|
||||
<literal>null</literal> is not antiquotable), that attribute is simply not
|
||||
added to the set:
|
||||
|
||||
<programlisting>
|
||||
{ ${if foo then "bar" else null} = true; }</programlisting>
|
||||
|
||||
This will evaluate to <literal>{}</literal> if <literal>foo</literal>
|
||||
evaluates to <literal>false</literal>.</para>
|
||||
|
||||
<para>A set that has a <literal>__functor</literal> attribute whose value
|
||||
is callable (i.e. is itself a function or a set with a
|
||||
<literal>__functor</literal> attribute whose value is callable) can be
|
||||
applied as if it were a function, with the set itself passed in first
|
||||
, e.g.,
|
||||
|
||||
<programlisting>
|
||||
let add = { __functor = self: x: x + self.x; };
|
||||
inc = add // { x = 1; };
|
||||
in inc 1
|
||||
</programlisting>
|
||||
|
||||
evaluates to <literal>2</literal>. This can be used to attach metadata to a
|
||||
function without the caller needing to treat it specially, or to implement
|
||||
a form of object-oriented programming, for example.
|
||||
|
||||
</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
</section>
|
||||
|
|
@ -1,84 +0,0 @@
|
|||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='sec-building-simple'>
|
||||
|
||||
<title>Building and Testing</title>
|
||||
|
||||
<para>You can now try to build Hello. Of course, you could do
|
||||
<literal>nix-env -i hello</literal>, but you may not want to install a
|
||||
possibly broken package just yet. The best way to test the package is by
|
||||
using the command <command linkend="sec-nix-build">nix-build</command>,
|
||||
which builds a Nix expression and creates a symlink named
|
||||
<filename>result</filename> in the current directory:
|
||||
|
||||
<screen>
|
||||
$ nix-build -A hello
|
||||
building path `/nix/store/632d2b22514d...-hello-2.1.1'
|
||||
hello-2.1.1/
|
||||
hello-2.1.1/intl/
|
||||
hello-2.1.1/intl/ChangeLog
|
||||
<replaceable>...</replaceable>
|
||||
|
||||
$ ls -l result
|
||||
lrwxrwxrwx ... 2006-09-29 10:43 result -> /nix/store/632d2b22514d...-hello-2.1.1
|
||||
|
||||
$ ./result/bin/hello
|
||||
Hello, world!</screen>
|
||||
|
||||
The <link linkend='opt-attr'><option>-A</option></link> option selects
|
||||
the <literal>hello</literal> attribute. This is faster than using the
|
||||
symbolic package name specified by the <literal>name</literal>
|
||||
attribute (which also happens to be <literal>hello</literal>) and is
|
||||
unambiguous (there can be multiple packages with the symbolic name
|
||||
<literal>hello</literal>, but there can be only one attribute in a set
|
||||
named <literal>hello</literal>).</para>
|
||||
|
||||
<para><command>nix-build</command> registers the
|
||||
<filename>./result</filename> symlink as a garbage collection root, so
|
||||
unless and until you delete the <filename>./result</filename> symlink,
|
||||
the output of the build will be safely kept on your system. You can
|
||||
use <command>nix-build</command>’s <option
|
||||
linkend='opt-out-link'>-o</option> switch to give the symlink another
|
||||
name.</para>
|
||||
|
||||
<para>Nix has a transactional semantics. Once a build finishes
|
||||
successfully, Nix makes a note of this in its database: it registers
|
||||
that the path denoted by <envar>out</envar> is now
|
||||
<quote>valid</quote>. If you try to build the derivation again, Nix
|
||||
will see that the path is already valid and finish immediately. If a
|
||||
build fails, either because it returns a non-zero exit code, because
|
||||
Nix or the builder are killed, or because the machine crashes, then
|
||||
the output paths will not be registered as valid. If you try to build
|
||||
the derivation again, Nix will remove the output paths if they exist
|
||||
(e.g., because the builder died half-way through <literal>make
|
||||
install</literal>) and try again. Note that there is no
|
||||
<quote>negative caching</quote>: Nix doesn't remember that a build
|
||||
failed, and so a failed build can always be repeated. This is because
|
||||
Nix cannot distinguish between permanent failures (e.g., a compiler
|
||||
error due to a syntax error in the source) and transient failures
|
||||
(e.g., a disk full condition).</para>
|
||||
|
||||
<para>Nix also performs locking. If you run multiple Nix builds
|
||||
simultaneously, and they try to build the same derivation, the first
|
||||
Nix instance that gets there will perform the build, while the others
|
||||
block (or perform other derivations if available) until the build
|
||||
finishes:
|
||||
|
||||
<screen>
|
||||
$ nix-build -A hello
|
||||
waiting for lock on `/nix/store/0h5b7hp8d4hqfrw8igvx97x1xawrjnac-hello-2.1.1x'</screen>
|
||||
|
||||
So it is always safe to run multiple instances of Nix in parallel
|
||||
(which isn’t the case with, say, <command>make</command>).</para>
|
||||
|
||||
<para>If you have a system with multiple CPUs, you may want to have
|
||||
Nix build different derivations in parallel (insofar as possible).
|
||||
Just pass the option <link linkend='opt-max-jobs'><option>-j
|
||||
<replaceable>N</replaceable></option></link>, where
|
||||
<replaceable>N</replaceable> is the maximum number of jobs to be run
|
||||
in parallel, or set. Typically this should be the number of
|
||||
CPUs.</para>
|
||||
|
||||
</section>
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-simple-expression">
|
||||
|
||||
<title>A Simple Nix Expression</title>
|
||||
|
||||
<para>This section shows how to add and test the <link
|
||||
xlink:href='http://www.gnu.org/software/hello/hello.html'>GNU Hello
|
||||
package</link> to the Nix Packages collection. Hello is a program
|
||||
that prints out the text <quote>Hello, world!</quote>.</para>
|
||||
|
||||
<para>To add a package to the Nix Packages collection, you generally
|
||||
need to do three things:
|
||||
|
||||
<orderedlist>
|
||||
|
||||
<listitem><para>Write a Nix expression for the package. This is a
|
||||
file that describes all the inputs involved in building the package,
|
||||
such as dependencies, sources, and so on.</para></listitem>
|
||||
|
||||
<listitem><para>Write a <emphasis>builder</emphasis>. This is a
|
||||
shell script<footnote><para>In fact, it can be written in any
|
||||
language, but typically it's a <command>bash</command> shell
|
||||
script.</para></footnote> that actually builds the package from
|
||||
the inputs.</para></listitem>
|
||||
|
||||
<listitem><para>Add the package to the file
|
||||
<filename>pkgs/top-level/all-packages.nix</filename>. The Nix
|
||||
expression written in the first step is a
|
||||
<emphasis>function</emphasis>; it requires other packages in order
|
||||
to build it. In this step you put it all together, i.e., you call
|
||||
the function with the right arguments to build the actual
|
||||
package.</para></listitem>
|
||||
|
||||
</orderedlist>
|
||||
|
||||
</para>
|
||||
|
||||
<xi:include href="expression-syntax.xml" />
|
||||
<xi:include href="build-script.xml" />
|
||||
<xi:include href="arguments-variables.xml" />
|
||||
<xi:include href="simple-building-testing.xml" />
|
||||
<xi:include href="generic-builder.xml" />
|
||||
|
||||
</chapter>
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
<part xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='chap-writing-nix-expressions'>
|
||||
|
||||
<title>Writing Nix Expressions</title>
|
||||
|
||||
<partintro>
|
||||
<para>This chapter shows you how to write Nix expressions, which
|
||||
instruct Nix how to build packages. It starts with a
|
||||
simple example (a Nix expression for GNU Hello), and then moves
|
||||
on to a more in-depth look at the Nix expression language.</para>
|
||||
|
||||
<note><para>This chapter is mostly about the Nix expression language.
|
||||
For more extensive information on adding packages to the Nix Packages
|
||||
collection (such as functions in the standard environment and coding
|
||||
conventions), please consult <link
|
||||
xlink:href="http://nixos.org/nixpkgs/manual/">its
|
||||
manual</link>.</para></note>
|
||||
</partintro>
|
||||
|
||||
<xi:include href="simple-expression.xml" />
|
||||
<xi:include href="expression-language.xml" />
|
||||
|
||||
</part>
|
||||
14
doc/manual/generate-builtins.nix
Normal file
14
doc/manual/generate-builtins.nix
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
with builtins;
|
||||
with import ./utils.nix;
|
||||
|
||||
builtins:
|
||||
|
||||
concatStrings (map
|
||||
(name:
|
||||
let builtin = builtins.${name}; in
|
||||
" - `builtins.${name}` " + concatStringsSep " " (map (s: "*${s}*") builtin.args)
|
||||
+ " \n\n"
|
||||
+ concatStrings (map (s: " ${s}\n") (splitLines builtin.doc)) + "\n\n"
|
||||
)
|
||||
(attrNames builtins))
|
||||
|
||||
92
doc/manual/generate-manpage.nix
Normal file
92
doc/manual/generate-manpage.nix
Normal file
|
|
@ -0,0 +1,92 @@
|
|||
command:
|
||||
|
||||
with builtins;
|
||||
with import ./utils.nix;
|
||||
|
||||
let
|
||||
|
||||
showCommand =
|
||||
{ command, def, filename }:
|
||||
"# Name\n\n"
|
||||
+ "`${command}` - ${def.description}\n\n"
|
||||
+ "# Synopsis\n\n"
|
||||
+ showSynopsis { inherit command; args = def.args; }
|
||||
+ (if def.commands or {} != {}
|
||||
then
|
||||
let
|
||||
categories = sort (x: y: x.id < y.id) (unique (map (cmd: cmd.category) (attrValues def.commands)));
|
||||
listCommands = cmds:
|
||||
concatStrings (map (name:
|
||||
"* [`${command} ${name}`](./${appendName filename name}.md) - ${cmds.${name}.description}\n")
|
||||
(attrNames cmds));
|
||||
in
|
||||
"where *subcommand* is one of the following:\n\n"
|
||||
# FIXME: group by category
|
||||
+ (if length categories > 1
|
||||
then
|
||||
concatStrings (map
|
||||
(cat:
|
||||
"**${toString cat.description}:**\n\n"
|
||||
+ listCommands (filterAttrs (n: v: v.category == cat) def.commands)
|
||||
+ "\n"
|
||||
) categories)
|
||||
+ "\n"
|
||||
else
|
||||
listCommands def.commands
|
||||
+ "\n")
|
||||
else "")
|
||||
+ (if def ? doc
|
||||
then def.doc + "\n\n"
|
||||
else "")
|
||||
+ (let s = showOptions def.flags; in
|
||||
if s != ""
|
||||
then "# Options\n\n${s}"
|
||||
else "")
|
||||
;
|
||||
|
||||
appendName = filename: name: (if filename == "nix" then "nix3" else filename) + "-" + name;
|
||||
|
||||
showOptions = flags:
|
||||
let
|
||||
categories = sort builtins.lessThan (unique (map (cmd: cmd.category) (attrValues flags)));
|
||||
in
|
||||
concatStrings (map
|
||||
(cat:
|
||||
(if cat != ""
|
||||
then "**${cat}:**\n\n"
|
||||
else "")
|
||||
+ concatStrings
|
||||
(map (longName:
|
||||
let
|
||||
flag = flags.${longName};
|
||||
in
|
||||
" - `--${longName}`"
|
||||
+ (if flag ? shortName then " / `-${flag.shortName}`" else "")
|
||||
+ (if flag ? labels then " " + (concatStringsSep " " (map (s: "*${s}*") flag.labels)) else "")
|
||||
+ " \n"
|
||||
+ " " + flag.description + "\n\n"
|
||||
) (attrNames (filterAttrs (n: v: v.category == cat) flags))))
|
||||
categories);
|
||||
|
||||
showSynopsis =
|
||||
{ command, args }:
|
||||
"`${command}` [*option*...] ${concatStringsSep " "
|
||||
(map (arg: "*${arg.label}*" + (if arg ? arity then "" else "...")) args)}\n\n";
|
||||
|
||||
processCommand = { command, def, filename }:
|
||||
[ { name = filename + ".md"; value = showCommand { inherit command def filename; }; inherit command; } ]
|
||||
++ concatMap
|
||||
(name: processCommand {
|
||||
filename = appendName filename name;
|
||||
command = command + " " + name;
|
||||
def = def.commands.${name};
|
||||
})
|
||||
(attrNames def.commands or {});
|
||||
|
||||
in
|
||||
|
||||
let
|
||||
manpages = processCommand { filename = "nix"; command = "nix"; def = command; };
|
||||
summary = concatStrings (map (manpage: " - [${manpage.command}](command-ref/new-cli/${manpage.name})\n") manpages);
|
||||
in
|
||||
(listToAttrs manpages) // { "SUMMARY.md" = summary; }
|
||||
26
doc/manual/generate-options.nix
Normal file
26
doc/manual/generate-options.nix
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
with builtins;
|
||||
with import ./utils.nix;
|
||||
|
||||
options:
|
||||
|
||||
concatStrings (map
|
||||
(name:
|
||||
let option = options.${name}; in
|
||||
" - `${name}` \n\n"
|
||||
+ concatStrings (map (s: " ${s}\n") (splitLines option.description)) + "\n\n"
|
||||
+ " **Default:** " + (
|
||||
if option.value == "" || option.value == []
|
||||
then "*empty*"
|
||||
else if isBool option.value
|
||||
then (if option.value then "`true`" else "`false`")
|
||||
else
|
||||
# n.b. a StringMap value type is specified as a string, but
|
||||
# this shows the value type. The empty stringmap is "null" in
|
||||
# JSON, but that converts to "{ }" here.
|
||||
(if isAttrs option.value then "`\"\"`"
|
||||
else "`" + toString option.value + "`")) + "\n\n"
|
||||
+ (if option.aliases != []
|
||||
then " **Deprecated alias:** " + (concatStringsSep ", " (map (s: "`${s}`") option.aliases)) + "\n\n"
|
||||
else "")
|
||||
)
|
||||
(attrNames options))
|
||||
|
|
@ -1,199 +0,0 @@
|
|||
<appendix xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="part-glossary">
|
||||
|
||||
<title>Glossary</title>
|
||||
|
||||
|
||||
<glosslist>
|
||||
|
||||
|
||||
<glossentry xml:id="gloss-derivation"><glossterm>derivation</glossterm>
|
||||
|
||||
<glossdef><para>A description of a build action. The result of a
|
||||
derivation is a store object. Derivations are typically specified
|
||||
in Nix expressions using the <link
|
||||
linkend="ssec-derivation"><function>derivation</function>
|
||||
primitive</link>. These are translated into low-level
|
||||
<emphasis>store derivations</emphasis> (implicitly by
|
||||
<command>nix-env</command> and <command>nix-build</command>, or
|
||||
explicitly by <command>nix-instantiate</command>).</para></glossdef>
|
||||
|
||||
</glossentry>
|
||||
|
||||
|
||||
<glossentry><glossterm>store</glossterm>
|
||||
|
||||
<glossdef><para>The location in the file system where store objects
|
||||
live. Typically <filename>/nix/store</filename>.</para></glossdef>
|
||||
|
||||
</glossentry>
|
||||
|
||||
|
||||
<glossentry><glossterm>store path</glossterm>
|
||||
|
||||
<glossdef><para>The location in the file system of a store object,
|
||||
i.e., an immediate child of the Nix store
|
||||
directory.</para></glossdef>
|
||||
|
||||
</glossentry>
|
||||
|
||||
|
||||
<glossentry><glossterm>store object</glossterm>
|
||||
|
||||
<glossdef><para>A file that is an immediate child of the Nix store
|
||||
directory. These can be regular files, but also entire directory
|
||||
trees. Store objects can be sources (objects copied from outside of
|
||||
the store), derivation outputs (objects produced by running a build
|
||||
action), or derivations (files describing a build
|
||||
action).</para></glossdef>
|
||||
|
||||
</glossentry>
|
||||
|
||||
|
||||
<glossentry xml:id="gloss-substitute"><glossterm>substitute</glossterm>
|
||||
|
||||
<glossdef><para>A substitute is a command invocation stored in the
|
||||
Nix database that describes how to build a store object, bypassing
|
||||
the normal build mechanism (i.e., derivations). Typically, the
|
||||
substitute builds the store object by downloading a pre-built
|
||||
version of the store object from some server.</para></glossdef>
|
||||
|
||||
</glossentry>
|
||||
|
||||
|
||||
<glossentry><glossterm>purity</glossterm>
|
||||
|
||||
<glossdef><para>The assumption that equal Nix derivations when run
|
||||
always produce the same output. This cannot be guaranteed in
|
||||
general (e.g., a builder can rely on external inputs such as the
|
||||
network or the system time) but the Nix model assumes
|
||||
it.</para></glossdef>
|
||||
|
||||
</glossentry>
|
||||
|
||||
|
||||
<glossentry><glossterm>Nix expression</glossterm>
|
||||
|
||||
<glossdef><para>A high-level description of software packages and
|
||||
compositions thereof. Deploying software using Nix entails writing
|
||||
Nix expressions for your packages. Nix expressions are translated
|
||||
to derivations that are stored in the Nix store. These derivations
|
||||
can then be built.</para></glossdef>
|
||||
|
||||
</glossentry>
|
||||
|
||||
|
||||
<glossentry xml:id="gloss-reference"><glossterm>reference</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>A store path <varname>P</varname> is said to have a
|
||||
reference to a store path <varname>Q</varname> if the store object
|
||||
at <varname>P</varname> contains the path <varname>Q</varname>
|
||||
somewhere. The <emphasis>references</emphasis> of a store path are
|
||||
the set of store paths to which it has a reference.
|
||||
</para>
|
||||
<para>A derivation can reference other derivations and sources
|
||||
(but not output paths), whereas an output path only references other
|
||||
output paths.
|
||||
</para>
|
||||
</glossdef>
|
||||
|
||||
</glossentry>
|
||||
|
||||
<glossentry xml:id="gloss-reachable"><glossterm>reachable</glossterm>
|
||||
|
||||
<glossdef><para>A store path <varname>Q</varname> is reachable from
|
||||
another store path <varname>P</varname> if <varname>Q</varname> is in the
|
||||
<link linkend="gloss-closure">closure</link> of the
|
||||
<link linkend="gloss-reference">references</link> relation.
|
||||
</para></glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry xml:id="gloss-closure"><glossterm>closure</glossterm>
|
||||
|
||||
<glossdef><para>The closure of a store path is the set of store
|
||||
paths that are directly or indirectly “reachable” from that store
|
||||
path; that is, it’s the closure of the path under the <link
|
||||
linkend="gloss-reference">references</link> relation. For a package, the
|
||||
closure of its derivation is equivalent to the build-time
|
||||
dependencies, while the closure of its output path is equivalent to its
|
||||
runtime dependencies. For correct deployment it is necessary to deploy whole
|
||||
closures, since otherwise at runtime files could be missing. The command
|
||||
<command>nix-store -qR</command> prints out closures of store paths.
|
||||
</para>
|
||||
<para>As an example, if the store object at path <varname>P</varname> contains
|
||||
a reference to path <varname>Q</varname>, then <varname>Q</varname> is
|
||||
in the closure of <varname>P</varname>. Further, if <varname>Q</varname>
|
||||
references <varname>R</varname> then <varname>R</varname> is also in
|
||||
the closure of <varname>P</varname>.
|
||||
</para></glossdef>
|
||||
|
||||
</glossentry>
|
||||
|
||||
|
||||
<glossentry xml:id="gloss-output-path"><glossterm>output path</glossterm>
|
||||
|
||||
<glossdef><para>A store path produced by a derivation.</para></glossdef>
|
||||
|
||||
</glossentry>
|
||||
|
||||
|
||||
<glossentry xml:id="gloss-deriver"><glossterm>deriver</glossterm>
|
||||
|
||||
<glossdef><para>The deriver of an <link
|
||||
linkend="gloss-output-path">output path</link> is the store
|
||||
derivation that built it.</para></glossdef>
|
||||
|
||||
</glossentry>
|
||||
|
||||
|
||||
<glossentry xml:id="gloss-validity"><glossterm>validity</glossterm>
|
||||
|
||||
<glossdef><para>A store path is considered
|
||||
<emphasis>valid</emphasis> if it exists in the file system, is
|
||||
listed in the Nix database as being valid, and if all paths in its
|
||||
closure are also valid.</para></glossdef>
|
||||
|
||||
</glossentry>
|
||||
|
||||
|
||||
<glossentry xml:id="gloss-user-env"><glossterm>user environment</glossterm>
|
||||
|
||||
<glossdef><para>An automatically generated store object that
|
||||
consists of a set of symlinks to “active” applications, i.e., other
|
||||
store paths. These are generated automatically by <link
|
||||
linkend="sec-nix-env"><command>nix-env</command></link>. See <xref
|
||||
linkend="sec-profiles" />.</para>
|
||||
|
||||
</glossdef>
|
||||
|
||||
</glossentry>
|
||||
|
||||
|
||||
<glossentry xml:id="gloss-profile"><glossterm>profile</glossterm>
|
||||
|
||||
<glossdef><para>A symlink to the current <link
|
||||
linkend="gloss-user-env">user environment</link> of a user, e.g.,
|
||||
<filename>/nix/var/nix/profiles/default</filename>.</para></glossdef>
|
||||
|
||||
</glossentry>
|
||||
|
||||
|
||||
<glossentry xml:id="gloss-nar"><glossterm>NAR</glossterm>
|
||||
|
||||
<glossdef><para>A <emphasis>N</emphasis>ix
|
||||
<emphasis>AR</emphasis>chive. This is a serialisation of a path in
|
||||
the Nix store. It can contain regular files, directories and
|
||||
symbolic links. NARs are generated and unpacked using
|
||||
<command>nix-store --dump</command> and <command>nix-store
|
||||
--restore</command>.</para></glossdef>
|
||||
|
||||
</glossentry>
|
||||
|
||||
|
||||
|
||||
</glosslist>
|
||||
|
||||
|
||||
</appendix>
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
<appendix xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="chap-hacking">
|
||||
|
||||
<title>Hacking</title>
|
||||
|
||||
<para>This section provides some notes on how to hack on Nix. To get
|
||||
the latest version of Nix from GitHub:
|
||||
<screen>
|
||||
$ git clone git://github.com/NixOS/nix.git
|
||||
$ cd nix
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>To build it and its dependencies:
|
||||
<screen>
|
||||
$ nix-build release.nix -A build.x86_64-linux
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>To build all dependencies and start a shell in which all
|
||||
environment variables are set up so that those dependencies can be
|
||||
found:
|
||||
<screen>
|
||||
$ nix-shell
|
||||
</screen>
|
||||
To build Nix itself in this shell:
|
||||
<screen>
|
||||
[nix-shell]$ ./bootstrap.sh
|
||||
[nix-shell]$ configurePhase
|
||||
[nix-shell]$ make
|
||||
</screen>
|
||||
To install it in <literal>$(pwd)/inst</literal> and test it:
|
||||
<screen>
|
||||
[nix-shell]$ make install
|
||||
[nix-shell]$ make installcheck
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
</appendix>
|
||||
6
doc/manual/highlight.pack.js
Normal file
6
doc/manual/highlight.pack.js
Normal file
File diff suppressed because one or more lines are too long
Binary file not shown.
|
Before Width: | Height: | Size: 889 B |
Binary file not shown.
|
Before Width: | Height: | Size: 929 B |
Binary file not shown.
|
Before Width: | Height: | Size: 202 B |
Binary file not shown.
|
Before Width: | Height: | Size: 210 B |
Binary file not shown.
|
Before Width: | Height: | Size: 209 B |
Binary file not shown.
|
Before Width: | Height: | Size: 205 B |
Binary file not shown.
|
Before Width: | Height: | Size: 210 B |
Binary file not shown.
|
Before Width: | Height: | Size: 907 B |
Binary file not shown.
|
Before Width: | Height: | Size: 914 B |
Binary file not shown.
|
Before Width: | Height: | Size: 907 B |
Binary file not shown.
|
Before Width: | Height: | Size: 916 B |
Binary file not shown.
|
Before Width: | Height: | Size: 218 B |
Binary file not shown.
|
Before Width: | Height: | Size: 907 B |
Binary file not shown.
|
Before Width: | Height: | Size: 918 B |
Binary file not shown.
|
Before Width: | Height: | Size: 923 B |
|
|
@ -1,49 +0,0 @@
|
|||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-building-source">
|
||||
|
||||
<title>Building Nix from Source</title>
|
||||
|
||||
<para>After unpacking or checking out the Nix sources, issue the
|
||||
following commands:
|
||||
|
||||
<screen>
|
||||
$ ./configure <replaceable>options...</replaceable>
|
||||
$ make
|
||||
$ make install</screen>
|
||||
|
||||
Nix requires GNU Make so you may need to invoke
|
||||
<command>gmake</command> instead.</para>
|
||||
|
||||
<para>When building from the Git repository, these should be preceded
|
||||
by the command:
|
||||
|
||||
<screen>
|
||||
$ ./bootstrap.sh</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>The installation path can be specified by passing the
|
||||
<option>--prefix=<replaceable>prefix</replaceable></option> to
|
||||
<command>configure</command>. The default installation directory is
|
||||
<filename>/usr/local</filename>. You can change this to any location
|
||||
you like. You must have write permission to the
|
||||
<replaceable>prefix</replaceable> path.</para>
|
||||
|
||||
<para>Nix keeps its <emphasis>store</emphasis> (the place where
|
||||
packages are stored) in <filename>/nix/store</filename> by default.
|
||||
This can be changed using
|
||||
<option>--with-store-dir=<replaceable>path</replaceable></option>.</para>
|
||||
|
||||
<warning><para>It is best <emphasis>not</emphasis> to change the Nix
|
||||
store from its default, since doing so makes it impossible to use
|
||||
pre-built binaries from the standard Nixpkgs channels — that is, all
|
||||
packages will need to be built from source.</para></warning>
|
||||
|
||||
<para>Nix keeps state (such as its database and log files) in
|
||||
<filename>/nix/var</filename> by default. This can be changed using
|
||||
<option>--localstatedir=<replaceable>path</replaceable></option>.</para>
|
||||
|
||||
</section>
|
||||
|
|
@ -1,71 +0,0 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-env-variables">
|
||||
|
||||
<title>Environment Variables</title>
|
||||
|
||||
<para>To use Nix, some environment variables should be set. In
|
||||
particular, <envar>PATH</envar> should contain the directories
|
||||
<filename><replaceable>prefix</replaceable>/bin</filename> and
|
||||
<filename>~/.nix-profile/bin</filename>. The first directory contains
|
||||
the Nix tools themselves, while <filename>~/.nix-profile</filename> is
|
||||
a symbolic link to the current <emphasis>user environment</emphasis>
|
||||
(an automatically generated package consisting of symlinks to
|
||||
installed packages). The simplest way to set the required environment
|
||||
variables is to include the file
|
||||
<filename><replaceable>prefix</replaceable>/etc/profile.d/nix.sh</filename>
|
||||
in your <filename>~/.profile</filename> (or similar), like this:</para>
|
||||
|
||||
<screen>
|
||||
source <replaceable>prefix</replaceable>/etc/profile.d/nix.sh</screen>
|
||||
|
||||
<section xml:id="sec-nix-ssl-cert-file">
|
||||
|
||||
<title><envar>NIX_SSL_CERT_FILE</envar></title>
|
||||
|
||||
<para>If you need to specify a custom certificate bundle to account
|
||||
for an HTTPS-intercepting man in the middle proxy, you must specify
|
||||
the path to the certificate bundle in the environment variable
|
||||
<envar>NIX_SSL_CERT_FILE</envar>.</para>
|
||||
|
||||
|
||||
<para>If you don't specify a <envar>NIX_SSL_CERT_FILE</envar>
|
||||
manually, Nix will install and use its own certificate
|
||||
bundle.</para>
|
||||
|
||||
<procedure>
|
||||
<step><para>Set the environment variable and install Nix</para>
|
||||
<screen>
|
||||
$ export NIX_SSL_CERT_FILE=/etc/ssl/my-certificate-bundle.crt
|
||||
$ sh <(curl https://nixos.org/nix/install)
|
||||
</screen></step>
|
||||
|
||||
<step><para>In the shell profile and rc files (for example,
|
||||
<filename>/etc/bashrc</filename>, <filename>/etc/zshrc</filename>),
|
||||
add the following line:</para>
|
||||
<programlisting>
|
||||
export NIX_SSL_CERT_FILE=/etc/ssl/my-certificate-bundle.crt
|
||||
</programlisting>
|
||||
</step>
|
||||
</procedure>
|
||||
|
||||
<note><para>You must not add the export and then do the install, as
|
||||
the Nix installer will detect the presense of Nix configuration, and
|
||||
abort.</para></note>
|
||||
|
||||
<section xml:id="sec-nix-ssl-cert-file-with-nix-daemon-and-macos">
|
||||
<title><envar>NIX_SSL_CERT_FILE</envar> with macOS and the Nix daemon</title>
|
||||
|
||||
<para>On macOS you must specify the environment variable for the Nix
|
||||
daemon service, then restart it:</para>
|
||||
|
||||
<screen>
|
||||
$ sudo launchctl setenv NIX_SSL_CERT_FILE /etc/ssl/my-certificate-bundle.crt
|
||||
$ sudo launchctl kickstart -k system/org.nixos.nix-daemon
|
||||
</screen>
|
||||
</section>
|
||||
|
||||
</section>
|
||||
</chapter>
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
<part xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="chap-installation">
|
||||
|
||||
<title>Installation</title>
|
||||
|
||||
<partintro>
|
||||
<para>This section describes how to install and configure Nix for first-time use.</para>
|
||||
</partintro>
|
||||
|
||||
<xi:include href="supported-platforms.xml" />
|
||||
<xi:include href="installing-binary.xml" />
|
||||
<xi:include href="installing-source.xml" />
|
||||
<xi:include href="nix-security.xml" />
|
||||
<xi:include href="env-variables.xml" />
|
||||
|
||||
<!-- TODO: should be updated
|
||||
<section><title>Upgrading Nix through Nix</title>
|
||||
|
||||
<para>You can install the latest stable version of Nix through Nix
|
||||
itself by subscribing to the channel <link
|
||||
xlink:href="http://nixos.org/releases/nix/channels/nix-stable" />,
|
||||
or the latest unstable version by subscribing to the channel <link
|
||||
xlink:href="http://nixos.org/releases/nix/channels/nix-unstable" />.
|
||||
You can also do a <link linkend="sec-one-click">one-click
|
||||
installation</link> by clicking on the package links at <link
|
||||
xlink:href="http://nixos.org/releases/full-index-nix.html" />.</para>
|
||||
|
||||
</section>
|
||||
-->
|
||||
|
||||
</part>
|
||||
|
|
@ -1,190 +0,0 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-installing-binary">
|
||||
|
||||
<title>Installing a Binary Distribution</title>
|
||||
|
||||
<para>If you are using Linux or macOS, the easiest way to install Nix
|
||||
is to run the following command:
|
||||
|
||||
<screen>
|
||||
$ sh <(curl https://nixos.org/nix/install)
|
||||
</screen>
|
||||
|
||||
As of Nix 2.1.0, the Nix installer will always default to creating a
|
||||
single-user installation, however opting in to the multi-user
|
||||
installation is highly recommended.
|
||||
</para>
|
||||
|
||||
<section xml:id="sect-single-user-installation">
|
||||
<title>Single User Installation</title>
|
||||
|
||||
<para>
|
||||
To explicitly select a single-user installation on your system:
|
||||
|
||||
<screen>
|
||||
sh <(curl https://nixos.org/nix/install) --no-daemon
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This will perform a single-user installation of Nix, meaning that
|
||||
<filename>/nix</filename> is owned by the invoking user. You should
|
||||
run this under your usual user account, <emphasis>not</emphasis> as
|
||||
root. The script will invoke <command>sudo</command> to create
|
||||
<filename>/nix</filename> if it doesn’t already exist. If you don’t
|
||||
have <command>sudo</command>, you should manually create
|
||||
<command>/nix</command> first as root, e.g.:
|
||||
|
||||
<screen>
|
||||
$ mkdir /nix
|
||||
$ chown alice /nix
|
||||
</screen>
|
||||
|
||||
The install script will modify the first writable file from amongst
|
||||
<filename>.bash_profile</filename>, <filename>.bash_login</filename>
|
||||
and <filename>.profile</filename> to source
|
||||
<filename>~/.nix-profile/etc/profile.d/nix.sh</filename>. You can set
|
||||
the <command>NIX_INSTALLER_NO_MODIFY_PROFILE</command> environment
|
||||
variable before executing the install script to disable this
|
||||
behaviour.
|
||||
</para>
|
||||
|
||||
|
||||
<para>You can uninstall Nix simply by running:
|
||||
|
||||
<screen>
|
||||
$ rm -rf /nix
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sect-multi-user-installation">
|
||||
<title>Multi User Installation</title>
|
||||
<para>
|
||||
The multi-user Nix installation creates system users, and a system
|
||||
service for the Nix daemon.
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<title>Supported Systems</title>
|
||||
|
||||
<listitem>
|
||||
<para>Linux running systemd, with SELinux disabled</para>
|
||||
</listitem>
|
||||
<listitem><para>macOS</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
You can instruct the installer to perform a multi-user
|
||||
installation on your system:
|
||||
|
||||
<screen>
|
||||
sh <(curl https://nixos.org/nix/install) --daemon
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The multi-user installation of Nix will create build users between
|
||||
the user IDs 30001 and 30032, and a group with the group ID 30000.
|
||||
|
||||
You should run this under your usual user account,
|
||||
<emphasis>not</emphasis> as root. The script will invoke
|
||||
<command>sudo</command> as needed.
|
||||
</para>
|
||||
|
||||
<note><para>
|
||||
If you need Nix to use a different group ID or user ID set, you
|
||||
will have to download the tarball manually and <link
|
||||
linkend="sect-nix-install-binary-tarball">edit the install
|
||||
script</link>.
|
||||
</para></note>
|
||||
|
||||
<para>
|
||||
The installer will modify <filename>/etc/bashrc</filename>, and
|
||||
<filename>/etc/zshrc</filename> if they exist. The installer will
|
||||
first back up these files with a
|
||||
<literal>.backup-before-nix</literal> extension. The installer
|
||||
will also create <filename>/etc/profile.d/nix.sh</filename>.
|
||||
</para>
|
||||
|
||||
<para>You can uninstall Nix with the following commands:
|
||||
|
||||
<screen>
|
||||
sudo rm -rf /etc/profile/nix.sh /etc/nix /nix ~root/.nix-profile ~root/.nix-defexpr ~root/.nix-channels ~/.nix-profile ~/.nix-defexpr ~/.nix-channels
|
||||
|
||||
# If you are on Linux with systemd, you will need to run:
|
||||
sudo systemctl stop nix-daemon.socket
|
||||
sudo systemctl stop nix-daemon.service
|
||||
sudo systemctl disable nix-daemon.socket
|
||||
sudo systemctl disable nix-daemon.service
|
||||
sudo systemctl daemon-reload
|
||||
|
||||
# If you are on macOS, you will need to run:
|
||||
sudo launchctl unload /Library/LaunchDaemons/org.nixos.nix-daemon.plist
|
||||
sudo rm /Library/LaunchDaemons/org.nixos.nix-daemon.plist
|
||||
</screen>
|
||||
|
||||
There may also be references to Nix in
|
||||
<filename>/etc/profile</filename>,
|
||||
<filename>/etc/bashrc</filename>, and
|
||||
<filename>/etc/zshrc</filename> which you may remove.
|
||||
</para>
|
||||
|
||||
</section>
|
||||
|
||||
<section xml:id="sect-nix-install-pinned-version-url">
|
||||
<title>Installing a pinned Nix version from a URL</title>
|
||||
|
||||
<para>
|
||||
NixOS.org hosts version-specific installation URLs for all Nix
|
||||
versions since 1.11.16, at
|
||||
<literal>https://nixos.org/releases/nix/nix-VERSION/install</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
These install scripts can be used the same as the main
|
||||
NixOS.org installation script:
|
||||
|
||||
<screen>
|
||||
sh <(curl https://nixos.org/nix/install)
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the same directory of the install script are sha256 sums, and
|
||||
gpg signature files.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sect-nix-install-binary-tarball">
|
||||
<title>Installing from a binary tarball</title>
|
||||
|
||||
<para>
|
||||
You can also download a binary tarball that contains Nix and all
|
||||
its dependencies. (This is what the install script at
|
||||
<uri>https://nixos.org/nix/install</uri> does automatically.) You
|
||||
should unpack it somewhere (e.g. in <filename>/tmp</filename>),
|
||||
and then run the script named <command>install</command> inside
|
||||
the binary tarball:
|
||||
|
||||
|
||||
<screen>
|
||||
alice$ cd /tmp
|
||||
alice$ tar xfj nix-1.8-x86_64-darwin.tar.bz2
|
||||
alice$ cd nix-1.8-x86_64-darwin
|
||||
alice$ ./install
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you need to edit the multi-user installation script to use
|
||||
different group ID or a different user ID range, modify the
|
||||
variables set in the file named
|
||||
<filename>install-multi-user</filename>.
|
||||
</para>
|
||||
</section>
|
||||
</chapter>
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-installing-source">
|
||||
|
||||
<title>Installing Nix from Source</title>
|
||||
|
||||
<para>If no binary package is available, you can download and compile
|
||||
a source distribution.</para>
|
||||
|
||||
<xi:include href="prerequisites-source.xml" />
|
||||
<xi:include href="obtaining-source.xml" />
|
||||
<xi:include href="building-source.xml" />
|
||||
|
||||
</chapter>
|
||||
|
|
@ -1,107 +0,0 @@
|
|||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ssec-multi-user">
|
||||
|
||||
<title>Multi-User Mode</title>
|
||||
|
||||
<para>To allow a Nix store to be shared safely among multiple users,
|
||||
it is important that users are not able to run builders that modify
|
||||
the Nix store or database in arbitrary ways, or that interfere with
|
||||
builds started by other users. If they could do so, they could
|
||||
install a Trojan horse in some package and compromise the accounts of
|
||||
other users.</para>
|
||||
|
||||
<para>To prevent this, the Nix store and database are owned by some
|
||||
privileged user (usually <literal>root</literal>) and builders are
|
||||
executed under special user accounts (usually named
|
||||
<literal>nixbld1</literal>, <literal>nixbld2</literal>, etc.). When a
|
||||
unprivileged user runs a Nix command, actions that operate on the Nix
|
||||
store (such as builds) are forwarded to a <emphasis>Nix
|
||||
daemon</emphasis> running under the owner of the Nix store/database
|
||||
that performs the operation.</para>
|
||||
|
||||
<note><para>Multi-user mode has one important limitation: only
|
||||
<systemitem class="username">root</systemitem> and a set of trusted
|
||||
users specified in <filename>nix.conf</filename> can specify arbitrary
|
||||
binary caches. So while unprivileged users may install packages from
|
||||
arbitrary Nix expressions, they may not get pre-built
|
||||
binaries.</para></note>
|
||||
|
||||
|
||||
<simplesect>
|
||||
|
||||
<title>Setting up the build users</title>
|
||||
|
||||
<para>The <emphasis>build users</emphasis> are the special UIDs under
|
||||
which builds are performed. They should all be members of the
|
||||
<emphasis>build users group</emphasis> <literal>nixbld</literal>.
|
||||
This group should have no other members. The build users should not
|
||||
be members of any other group. On Linux, you can create the group and
|
||||
users as follows:
|
||||
|
||||
<screen>
|
||||
$ groupadd -r nixbld
|
||||
$ for n in $(seq 1 10); do useradd -c "Nix build user $n" \
|
||||
-d /var/empty -g nixbld -G nixbld -M -N -r -s "$(which nologin)" \
|
||||
nixbld$n; done
|
||||
</screen>
|
||||
|
||||
This creates 10 build users. There can never be more concurrent builds
|
||||
than the number of build users, so you may want to increase this if
|
||||
you expect to do many builds at the same time.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect>
|
||||
|
||||
<title>Running the daemon</title>
|
||||
|
||||
<para>The <link linkend="sec-nix-daemon">Nix daemon</link> should be
|
||||
started as follows (as <literal>root</literal>):
|
||||
|
||||
<screen>
|
||||
$ nix-daemon</screen>
|
||||
|
||||
You’ll want to put that line somewhere in your system’s boot
|
||||
scripts.</para>
|
||||
|
||||
<para>To let unprivileged users use the daemon, they should set the
|
||||
<link linkend="envar-remote"><envar>NIX_REMOTE</envar> environment
|
||||
variable</link> to <literal>daemon</literal>. So you should put a
|
||||
line like
|
||||
|
||||
<programlisting>
|
||||
export NIX_REMOTE=daemon</programlisting>
|
||||
|
||||
into the users’ login scripts.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect>
|
||||
|
||||
<title>Restricting access</title>
|
||||
|
||||
<para>To limit which users can perform Nix operations, you can use the
|
||||
permissions on the directory
|
||||
<filename>/nix/var/nix/daemon-socket</filename>. For instance, if you
|
||||
want to restrict the use of Nix to the members of a group called
|
||||
<literal>nix-users</literal>, do
|
||||
|
||||
<screen>
|
||||
$ chgrp nix-users /nix/var/nix/daemon-socket
|
||||
$ chmod ug=rwx,o= /nix/var/nix/daemon-socket
|
||||
</screen>
|
||||
|
||||
This way, users who are not in the <literal>nix-users</literal> group
|
||||
cannot connect to the Unix domain socket
|
||||
<filename>/nix/var/nix/daemon-socket/socket</filename>, so they cannot
|
||||
perform Nix operations.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
</section>
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-nix-security">
|
||||
|
||||
<title>Security</title>
|
||||
|
||||
<para>Nix has two basic security models. First, it can be used in
|
||||
“single-user mode”, which is similar to what most other package
|
||||
management tools do: there is a single user (typically <systemitem
|
||||
class="username">root</systemitem>) who performs all package
|
||||
management operations. All other users can then use the installed
|
||||
packages, but they cannot perform package management operations
|
||||
themselves.</para>
|
||||
|
||||
<para>Alternatively, you can configure Nix in “multi-user mode”. In
|
||||
this model, all users can perform package management operations — for
|
||||
instance, every user can install software without requiring root
|
||||
privileges. Nix ensures that this is secure. For instance, it’s not
|
||||
possible for one user to overwrite a package used by another user with
|
||||
a Trojan horse.</para>
|
||||
|
||||
<xi:include href="single-user.xml" />
|
||||
<xi:include href="multi-user.xml" />
|
||||
|
||||
</chapter>
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-obtaining-source">
|
||||
|
||||
<title>Obtaining a Source Distribution</title>
|
||||
|
||||
<para>The source tarball of the most recent stable release can be
|
||||
downloaded from the <link
|
||||
xlink:href="http://nixos.org/nix/download.html">Nix homepage</link>.
|
||||
You can also grab the <link
|
||||
xlink:href="http://hydra.nixos.org/job/nix/master/release/latest-finished#tabs-constituents">most
|
||||
recent development release</link>.</para>
|
||||
|
||||
<para>Alternatively, the most recent sources of Nix can be obtained
|
||||
from its <link
|
||||
xlink:href="https://github.com/NixOS/nix">Git
|
||||
repository</link>. For example, the following command will check out
|
||||
the latest revision into a directory called
|
||||
<filename>nix</filename>:</para>
|
||||
|
||||
<screen>
|
||||
$ git clone https://github.com/NixOS/nix</screen>
|
||||
|
||||
<para>Likewise, specific releases can be obtained from the <link
|
||||
xlink:href="https://github.com/NixOS/nix/tags">tags</link> of the
|
||||
repository.</para>
|
||||
|
||||
</section>
|
||||
|
|
@ -1,101 +0,0 @@
|
|||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-prerequisites-source">
|
||||
|
||||
<title>Prerequisites</title>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para>GNU Make.</para></listitem>
|
||||
|
||||
<listitem><para>Bash Shell. The <literal>./configure</literal> script
|
||||
relies on bashisms, so Bash is required.</para></listitem>
|
||||
|
||||
<listitem><para>A version of GCC or Clang that supports C++14.</para></listitem>
|
||||
|
||||
<listitem><para><command>pkg-config</command> to locate
|
||||
dependencies. If your distribution does not provide it, you can get
|
||||
it from <link
|
||||
xlink:href="http://www.freedesktop.org/wiki/Software/pkg-config"
|
||||
/>.</para></listitem>
|
||||
|
||||
<listitem><para>The OpenSSL library to calculate cryptographic hashes.
|
||||
If your distribution does not provide it, you can get it from <link
|
||||
xlink:href="https://www.openssl.org"/>.</para></listitem>
|
||||
|
||||
<listitem><para>The <literal>libbrotlienc</literal> and
|
||||
<literal>libbrotlidec</literal> libraries to provide implementation
|
||||
of the Brotli compression algorithm. They are available for download
|
||||
from the official repository <link
|
||||
xlink:href="https://github.com/google/brotli" />.</para></listitem>
|
||||
|
||||
<listitem><para>The bzip2 compressor program and the
|
||||
<literal>libbz2</literal> library. Thus you must have bzip2
|
||||
installed, including development headers and libraries. If your
|
||||
distribution does not provide these, you can obtain bzip2 from <link
|
||||
xlink:href="https://web.archive.org/web/20180624184756/http://www.bzip.org/"
|
||||
/>.</para></listitem>
|
||||
|
||||
<listitem><para><literal>liblzma</literal>, which is provided by
|
||||
XZ Utils. If your distribution does not provide this, you can
|
||||
get it from <link xlink:href="https://tukaani.org/xz/"/>.</para></listitem>
|
||||
|
||||
<listitem><para>cURL and its library. If your distribution does not
|
||||
provide it, you can get it from <link
|
||||
xlink:href="https://curl.haxx.se/"/>.</para></listitem>
|
||||
|
||||
<listitem><para>The SQLite embedded database library, version 3.6.19
|
||||
or higher. If your distribution does not provide it, please install
|
||||
it from <link xlink:href="http://www.sqlite.org/" />.</para></listitem>
|
||||
|
||||
<listitem><para>The <link
|
||||
xlink:href="http://www.hboehm.info/gc/">Boehm
|
||||
garbage collector</link> to reduce the evaluator’s memory
|
||||
consumption (optional). To enable it, install
|
||||
<literal>pkgconfig</literal> and the Boehm garbage collector, and
|
||||
pass the flag <option>--enable-gc</option> to
|
||||
<command>configure</command>.</para></listitem>
|
||||
|
||||
<listitem><para>The <literal>boost</literal> library of version
|
||||
1.66.0 or higher. It can be obtained from the official web site
|
||||
<link xlink:href="https://www.boost.org/" />.</para></listitem>
|
||||
|
||||
<listitem><para>The <command>xmllint</command> and
|
||||
<command>xsltproc</command> programs to build this manual and the
|
||||
man-pages. These are part of the <literal>libxml2</literal> and
|
||||
<literal>libxslt</literal> packages, respectively. You also need
|
||||
the <link
|
||||
xlink:href="http://docbook.sourceforge.net/projects/xsl/">DocBook
|
||||
XSL stylesheets</link> and optionally the <link
|
||||
xlink:href="http://www.docbook.org/schemas/5x"> DocBook 5.0 RELAX NG
|
||||
schemas</link>. Note that these are only required if you modify the
|
||||
manual sources or when you are building from the Git
|
||||
repository.</para></listitem>
|
||||
|
||||
<listitem><para>Recent versions of Bison and Flex to build the
|
||||
parser. (This is because Nix needs GLR support in Bison and
|
||||
reentrancy support in Flex.) For Bison, you need version 2.6, which
|
||||
can be obtained from the <link
|
||||
xlink:href="ftp://alpha.gnu.org/pub/gnu/bison">GNU FTP
|
||||
server</link>. For Flex, you need version 2.5.35, which is
|
||||
available on <link
|
||||
xlink:href="http://lex.sourceforge.net/">SourceForge</link>.
|
||||
Slightly older versions may also work, but ancient versions like the
|
||||
ubiquitous 2.5.4a won't. Note that these are only required if you
|
||||
modify the parser or when you are building from the Git
|
||||
repository.</para></listitem>
|
||||
|
||||
<listitem><para>The <literal>libseccomp</literal> is used to provide
|
||||
syscall filtering on Linux. This is an optional dependency and can
|
||||
be disabled passing a <option>--disable-seccomp-sandboxing</option>
|
||||
option to the <command>configure</command> script (Not recommended
|
||||
unless your system doesn't support
|
||||
<literal>libseccomp</literal>). To get the library, visit <link
|
||||
xlink:href="https://github.com/seccomp/libseccomp"
|
||||
/>.</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</section>
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-single-user">
|
||||
|
||||
<title>Single-User Mode</title>
|
||||
|
||||
<para>In single-user mode, all Nix operations that access the database
|
||||
in <filename><replaceable>prefix</replaceable>/var/nix/db</filename>
|
||||
or modify the Nix store in
|
||||
<filename><replaceable>prefix</replaceable>/store</filename> must be
|
||||
performed under the user ID that owns those directories. This is
|
||||
typically <systemitem class="username">root</systemitem>. (If you
|
||||
install from RPM packages, that’s in fact the default ownership.)
|
||||
However, on single-user machines, it is often convenient to
|
||||
<command>chown</command> those directories to your normal user account
|
||||
so that you don’t have to <command>su</command> to <systemitem
|
||||
class="username">root</systemitem> all the time.</para>
|
||||
|
||||
</section>
|
||||
|
|
@ -1,36 +0,0 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-supported-platforms">
|
||||
|
||||
<title>Supported Platforms</title>
|
||||
|
||||
<para>Nix is currently supported on the following platforms:
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para>Linux (i686, x86_64, aarch64).</para></listitem>
|
||||
|
||||
<listitem><para>macOS (x86_64).</para></listitem>
|
||||
|
||||
<!--
|
||||
<listitem><para>FreeBSD (only tested on Intel).</para></listitem>
|
||||
-->
|
||||
|
||||
<!--
|
||||
<listitem><para>Windows through <link
|
||||
xlink:href="http://www.cygwin.com/">Cygwin</link>.</para>
|
||||
|
||||
<warning><para>On Cygwin, Nix <emphasis>must</emphasis> be installed
|
||||
on an NTFS partition. It will not work correctly on a FAT
|
||||
partition.</para></warning>
|
||||
|
||||
</listitem>
|
||||
-->
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</para>
|
||||
|
||||
</chapter>
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-upgrading-nix">
|
||||
|
||||
<title>Upgrading Nix</title>
|
||||
|
||||
<para>
|
||||
Multi-user Nix users on macOS can upgrade Nix by running:
|
||||
<command>sudo -i sh -c 'nix-channel --update &&
|
||||
nix-env -iA nixpkgs.nix &&
|
||||
launchctl remove org.nixos.nix-daemon &&
|
||||
launchctl load /Library/LaunchDaemons/org.nixos.nix-daemon.plist'</command>
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
Single-user installations of Nix should run this:
|
||||
<command>nix-channel --update; nix-env -iA nixpkgs.nix</command>
|
||||
</para>
|
||||
</chapter>
|
||||
|
|
@ -1,268 +0,0 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-about-nix">
|
||||
|
||||
<title>About Nix</title>
|
||||
|
||||
<para>Nix is a <emphasis>purely functional package manager</emphasis>.
|
||||
This means that it treats packages like values in purely functional
|
||||
programming languages such as Haskell — they are built by functions
|
||||
that don’t have side-effects, and they never change after they have
|
||||
been built. Nix stores packages in the <emphasis>Nix
|
||||
store</emphasis>, usually the directory
|
||||
<filename>/nix/store</filename>, where each package has its own unique
|
||||
subdirectory such as
|
||||
|
||||
<programlisting>
|
||||
/nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/
|
||||
</programlisting>
|
||||
|
||||
where <literal>b6gvzjyb2pg0…</literal> is a unique identifier for the
|
||||
package that captures all its dependencies (it’s a cryptographic hash
|
||||
of the package’s build dependency graph). This enables many powerful
|
||||
features.</para>
|
||||
|
||||
|
||||
<simplesect><title>Multiple versions</title>
|
||||
|
||||
<para>You can have multiple versions or variants of a package
|
||||
installed at the same time. This is especially important when
|
||||
different applications have dependencies on different versions of the
|
||||
same package — it prevents the “DLL hell”. Because of the hashing
|
||||
scheme, different versions of a package end up in different paths in
|
||||
the Nix store, so they don’t interfere with each other.</para>
|
||||
|
||||
<para>An important consequence is that operations like upgrading or
|
||||
uninstalling an application cannot break other applications, since
|
||||
these operations never “destructively” update or delete files that are
|
||||
used by other packages.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Complete dependencies</title>
|
||||
|
||||
<para>Nix helps you make sure that package dependency specifications
|
||||
are complete. In general, when you’re making a package for a package
|
||||
management system like RPM, you have to specify for each package what
|
||||
its dependencies are, but there are no guarantees that this
|
||||
specification is complete. If you forget a dependency, then the
|
||||
package will build and work correctly on <emphasis>your</emphasis>
|
||||
machine if you have the dependency installed, but not on the end
|
||||
user's machine if it's not there.</para>
|
||||
|
||||
<para>Since Nix on the other hand doesn’t install packages in “global”
|
||||
locations like <filename>/usr/bin</filename> but in package-specific
|
||||
directories, the risk of incomplete dependencies is greatly reduced.
|
||||
This is because tools such as compilers don’t search in per-packages
|
||||
directories such as
|
||||
<filename>/nix/store/5lbfaxb722zp…-openssl-0.9.8d/include</filename>,
|
||||
so if a package builds correctly on your system, this is because you
|
||||
specified the dependency explicitly. This takes care of the build-time
|
||||
dependencies.</para>
|
||||
|
||||
<para>Once a package is built, runtime dependencies are found by
|
||||
scanning binaries for the hash parts of Nix store paths (such as
|
||||
<literal>r8vvq9kq…</literal>). This sounds risky, but it works
|
||||
extremely well.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Multi-user support</title>
|
||||
|
||||
<para>Nix has multi-user support. This means that non-privileged
|
||||
users can securely install software. Each user can have a different
|
||||
<emphasis>profile</emphasis>, a set of packages in the Nix store that
|
||||
appear in the user’s <envar>PATH</envar>. If a user installs a
|
||||
package that another user has already installed previously, the
|
||||
package won’t be built or downloaded a second time. At the same time,
|
||||
it is not possible for one user to inject a Trojan horse into a
|
||||
package that might be used by another user.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Atomic upgrades and rollbacks</title>
|
||||
|
||||
<para>Since package management operations never overwrite packages in
|
||||
the Nix store but just add new versions in different paths, they are
|
||||
<emphasis>atomic</emphasis>. So during a package upgrade, there is no
|
||||
time window in which the package has some files from the old version
|
||||
and some files from the new version — which would be bad because a
|
||||
program might well crash if it’s started during that period.</para>
|
||||
|
||||
<para>And since packages aren’t overwritten, the old versions are still
|
||||
there after an upgrade. This means that you can <emphasis>roll
|
||||
back</emphasis> to the old version:</para>
|
||||
|
||||
<screen>
|
||||
$ nix-env --upgrade <replaceable>some-packages</replaceable>
|
||||
$ nix-env --rollback
|
||||
</screen>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Garbage collection</title>
|
||||
|
||||
<para>When you uninstall a package like this…
|
||||
|
||||
<screen>
|
||||
$ nix-env --uninstall firefox
|
||||
</screen>
|
||||
|
||||
the package isn’t deleted from the system right away (after all, you
|
||||
might want to do a rollback, or it might be in the profiles of other
|
||||
users). Instead, unused packages can be deleted safely by running the
|
||||
<emphasis>garbage collector</emphasis>:
|
||||
|
||||
<screen>
|
||||
$ nix-collect-garbage
|
||||
</screen>
|
||||
|
||||
This deletes all packages that aren’t in use by any user profile or by
|
||||
a currently running program.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Functional package language</title>
|
||||
|
||||
<para>Packages are built from <emphasis>Nix expressions</emphasis>,
|
||||
which is a simple functional language. A Nix expression describes
|
||||
everything that goes into a package build action (a “derivation”):
|
||||
other packages, sources, the build script, environment variables for
|
||||
the build script, etc. Nix tries very hard to ensure that Nix
|
||||
expressions are <emphasis>deterministic</emphasis>: building a Nix
|
||||
expression twice should yield the same result.</para>
|
||||
|
||||
<para>Because it’s a functional language, it’s easy to support
|
||||
building variants of a package: turn the Nix expression into a
|
||||
function and call it any number of times with the appropriate
|
||||
arguments. Due to the hashing scheme, variants don’t conflict with
|
||||
each other in the Nix store.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Transparent source/binary deployment</title>
|
||||
|
||||
<para>Nix expressions generally describe how to build a package from
|
||||
source, so an installation action like
|
||||
|
||||
<screen>
|
||||
$ nix-env --install firefox
|
||||
</screen>
|
||||
|
||||
<emphasis>could</emphasis> cause quite a bit of build activity, as not
|
||||
only Firefox but also all its dependencies (all the way up to the C
|
||||
library and the compiler) would have to built, at least if they are
|
||||
not already in the Nix store. This is a <emphasis>source deployment
|
||||
model</emphasis>. For most users, building from source is not very
|
||||
pleasant as it takes far too long. However, Nix can automatically
|
||||
skip building from source and instead use a <emphasis>binary
|
||||
cache</emphasis>, a web server that provides pre-built binaries. For
|
||||
instance, when asked to build
|
||||
<literal>/nix/store/b6gvzjyb2pg0…-firefox-33.1</literal> from source,
|
||||
Nix would first check if the file
|
||||
<uri>https://cache.nixos.org/b6gvzjyb2pg0….narinfo</uri> exists, and
|
||||
if so, fetch the pre-built binary referenced from there; otherwise, it
|
||||
would fall back to building from source.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<!--
|
||||
<simplesect><title>Binary patching</title>
|
||||
|
||||
<para>In addition to downloading binaries automatically if they’re
|
||||
available, Nix can download binary deltas that patch an existing
|
||||
package in the Nix store into a new version. This speeds up
|
||||
upgrades.</para>
|
||||
|
||||
</simplesect>
|
||||
-->
|
||||
|
||||
|
||||
<simplesect><title>Nix Packages collection</title>
|
||||
|
||||
<para>We provide a large set of Nix expressions containing hundreds of
|
||||
existing Unix packages, the <emphasis>Nix Packages
|
||||
collection</emphasis> (Nixpkgs).</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Managing build environments</title>
|
||||
|
||||
<para>Nix is extremely useful for developers as it makes it easy to
|
||||
automatically set up the build environment for a package. Given a
|
||||
Nix expression that describes the dependencies of your package, the
|
||||
command <command>nix-shell</command> will build or download those
|
||||
dependencies if they’re not already in your Nix store, and then start
|
||||
a Bash shell in which all necessary environment variables (such as
|
||||
compiler search paths) are set.</para>
|
||||
|
||||
<para>For example, the following command gets all dependencies of the
|
||||
Pan newsreader, as described by <link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/newsreaders/pan/default.nix">its
|
||||
Nix expression</link>:</para>
|
||||
|
||||
<screen>
|
||||
$ nix-shell '<nixpkgs>' -A pan
|
||||
</screen>
|
||||
|
||||
<para>You’re then dropped into a shell where you can edit, build and test
|
||||
the package:</para>
|
||||
|
||||
<screen>
|
||||
[nix-shell]$ tar xf $src
|
||||
[nix-shell]$ cd pan-*
|
||||
[nix-shell]$ ./configure
|
||||
[nix-shell]$ make
|
||||
[nix-shell]$ ./pan/gui/pan
|
||||
</screen>
|
||||
|
||||
<!--
|
||||
<para>Since Nix packages are reproducible and have complete dependency
|
||||
specifications, Nix makes an excellent basis for <a
|
||||
href="[%root%]hydra">a continuous build system</a>.</para>
|
||||
-->
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Portability</title>
|
||||
|
||||
<para>Nix runs on Linux and macOS.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>NixOS</title>
|
||||
|
||||
<para>NixOS is a Linux distribution based on Nix. It uses Nix not
|
||||
just for package management but also to manage the system
|
||||
configuration (e.g., to build configuration files in
|
||||
<filename>/etc</filename>). This means, among other things, that it
|
||||
is easy to roll back the entire configuration of the system to an
|
||||
earlier state. Also, users can install software without root
|
||||
privileges. For more information and downloads, see the <link
|
||||
xlink:href="http://nixos.org/">NixOS homepage</link>.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>License</title>
|
||||
|
||||
<para>Nix is released under the terms of the <link
|
||||
xlink:href="http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html">GNU
|
||||
LGPLv2.1 or (at your option) any later version</link>.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
</chapter>
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
<part xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="chap-introduction">
|
||||
|
||||
<title>Introduction</title>
|
||||
|
||||
<xi:include href="about-nix.xml" />
|
||||
<xi:include href="quick-start.xml" />
|
||||
|
||||
</part>
|
||||
|
|
@ -1,124 +0,0 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="chap-quick-start">
|
||||
|
||||
<title>Quick Start</title>
|
||||
|
||||
<para>This chapter is for impatient people who don't like reading
|
||||
documentation. For more in-depth information you are kindly referred
|
||||
to subsequent chapters.</para>
|
||||
|
||||
<procedure>
|
||||
|
||||
<step><para>Install single-user Nix by running the following:
|
||||
|
||||
<screen>
|
||||
$ bash <(curl https://nixos.org/nix/install)
|
||||
</screen>
|
||||
|
||||
This will install Nix in <filename>/nix</filename>. The install script
|
||||
will create <filename>/nix</filename> using <command>sudo</command>,
|
||||
so make sure you have sufficient rights. (For other installation
|
||||
methods, see <xref linkend="chap-installation"/>.)</para></step>
|
||||
|
||||
<step><para>See what installable packages are currently available
|
||||
in the channel:
|
||||
|
||||
<screen>
|
||||
$ nix-env -qa
|
||||
docbook-xml-4.3
|
||||
docbook-xml-4.5
|
||||
firefox-33.0.2
|
||||
hello-2.9
|
||||
libxslt-1.1.28
|
||||
<replaceable>...</replaceable></screen>
|
||||
|
||||
</para></step>
|
||||
|
||||
<step><para>Install some packages from the channel:
|
||||
|
||||
<screen>
|
||||
$ nix-env -i hello</screen>
|
||||
|
||||
This should download pre-built packages; it should not build them
|
||||
locally (if it does, something went wrong).</para></step>
|
||||
|
||||
<step><para>Test that they work:
|
||||
|
||||
<screen>
|
||||
$ which hello
|
||||
/home/eelco/.nix-profile/bin/hello
|
||||
$ hello
|
||||
Hello, world!
|
||||
</screen>
|
||||
|
||||
</para></step>
|
||||
|
||||
<step><para>Uninstall a package:
|
||||
|
||||
<screen>
|
||||
$ nix-env -e hello</screen>
|
||||
|
||||
</para></step>
|
||||
|
||||
<step><para>You can also test a package without installing it:
|
||||
|
||||
<screen>
|
||||
$ nix-shell -p hello
|
||||
</screen>
|
||||
|
||||
This builds or downloads GNU Hello and its dependencies, then drops
|
||||
you into a Bash shell where the <command>hello</command> command is
|
||||
present, all without affecting your normal environment:
|
||||
|
||||
<screen>
|
||||
[nix-shell:~]$ hello
|
||||
Hello, world!
|
||||
|
||||
[nix-shell:~]$ exit
|
||||
|
||||
$ hello
|
||||
hello: command not found
|
||||
</screen>
|
||||
|
||||
</para></step>
|
||||
|
||||
<step><para>To keep up-to-date with the channel, do:
|
||||
|
||||
<screen>
|
||||
$ nix-channel --update nixpkgs
|
||||
$ nix-env -u '*'</screen>
|
||||
|
||||
The latter command will upgrade each installed package for which there
|
||||
is a “newer” version (as determined by comparing the version
|
||||
numbers).</para></step>
|
||||
|
||||
<step><para>If you're unhappy with the result of a
|
||||
<command>nix-env</command> action (e.g., an upgraded package turned
|
||||
out not to work properly), you can go back:
|
||||
|
||||
<screen>
|
||||
$ nix-env --rollback</screen>
|
||||
|
||||
</para></step>
|
||||
|
||||
<step><para>You should periodically run the Nix garbage collector
|
||||
to get rid of unused packages, since uninstalls or upgrades don't
|
||||
actually delete them:
|
||||
|
||||
<screen>
|
||||
$ nix-collect-garbage -d</screen>
|
||||
|
||||
<!--
|
||||
The first command deletes old “generations” of your profile (making
|
||||
rollbacks impossible, but also making the packages in those old
|
||||
generations available for garbage collection), while the second
|
||||
command actually deletes them.-->
|
||||
|
||||
</para></step>
|
||||
|
||||
</procedure>
|
||||
|
||||
</chapter>
|
||||
|
|
@ -1,43 +1,6 @@
|
|||
|
||||
ifeq ($(doc_generate),yes)
|
||||
|
||||
XSLTPROC = $(xsltproc) --nonet $(xmlflags) \
|
||||
--param section.autolabel 1 \
|
||||
--param section.label.includes.component.label 1 \
|
||||
--param html.stylesheet \'style.css\' \
|
||||
--param xref.with.number.and.title 1 \
|
||||
--param toc.section.depth 3 \
|
||||
--param admon.style \'\' \
|
||||
--param callout.graphics.extension \'.gif\' \
|
||||
--param contrib.inline.enabled 0 \
|
||||
--stringparam generate.toc "book toc" \
|
||||
--param keep.relative.image.uris 0
|
||||
|
||||
docbookxsl = http://docbook.sourceforge.net/release/xsl-ns/current
|
||||
docbookrng = http://docbook.org/xml/5.0/rng/docbook.rng
|
||||
|
||||
MANUAL_SRCS := $(call rwildcard, $(d), *.xml)
|
||||
|
||||
|
||||
# Do XInclude processing / RelaxNG validation
|
||||
$(d)/manual.xmli: $(d)/manual.xml $(MANUAL_SRCS) $(d)/version.txt
|
||||
$(trace-gen) $(xmllint) --nonet --xinclude $< -o $@.tmp
|
||||
@mv $@.tmp $@
|
||||
|
||||
$(d)/version.txt:
|
||||
$(trace-gen) echo -n $(PACKAGE_VERSION) > $@
|
||||
|
||||
# Note: RelaxNG validation requires xmllint >= 2.7.4.
|
||||
$(d)/manual.is-valid: $(d)/manual.xmli
|
||||
$(trace-gen) $(XSLTPROC) --novalid --stringparam profile.condition manual \
|
||||
$(docbookxsl)/profiling/profile.xsl $< 2> /dev/null | \
|
||||
$(xmllint) --nonet --noout --relaxng $(docbookrng) -
|
||||
@touch $@
|
||||
|
||||
clean-files += $(d)/manual.xmli $(d)/version.txt $(d)/manual.is-valid
|
||||
|
||||
dist-files += $(d)/manual.xmli $(d)/version.txt $(d)/manual.is-valid
|
||||
|
||||
MANUAL_SRCS := $(call rwildcard, $(d)/src, *.md)
|
||||
|
||||
# Generate man pages.
|
||||
man-pages := $(foreach n, \
|
||||
|
|
@ -48,40 +11,80 @@ man-pages := $(foreach n, \
|
|||
nix.conf.5 nix-daemon.8, \
|
||||
$(d)/$(n))
|
||||
|
||||
$(firstword $(man-pages)): $(d)/manual.xmli $(d)/manual.is-valid
|
||||
$(trace-gen) $(XSLTPROC) --novalid --stringparam profile.condition manpage \
|
||||
$(docbookxsl)/profiling/profile.xsl $< 2> /dev/null | \
|
||||
(cd doc/manual && $(XSLTPROC) $(docbookxsl)/manpages/docbook.xsl -)
|
||||
|
||||
$(wordlist 2, $(words $(man-pages)), $(man-pages)): $(firstword $(man-pages))
|
||||
|
||||
clean-files += $(d)/*.1 $(d)/*.5 $(d)/*.8
|
||||
|
||||
dist-files += $(man-pages)
|
||||
# Provide a dummy environment for nix, so that it will not access files outside the macOS sandbox.
|
||||
dummy-env = env -i \
|
||||
HOME=/dummy \
|
||||
NIX_CONF_DIR=/dummy \
|
||||
NIX_SSL_CERT_FILE=/dummy/no-ca-bundle.crt \
|
||||
NIX_STATE_DIR=/dummy
|
||||
|
||||
nix-eval = $(dummy-env) $(bindir)/nix eval --experimental-features nix-command -I nix/corepkgs=corepkgs --store dummy:// --impure --raw
|
||||
|
||||
$(d)/%.1: $(d)/src/command-ref/%.md
|
||||
@printf "Title: %s\n\n" "$$(basename $@ .1)" > $^.tmp
|
||||
@cat $^ >> $^.tmp
|
||||
$(trace-gen) lowdown -sT man $^.tmp -o $@
|
||||
@rm $^.tmp
|
||||
|
||||
$(d)/%.8: $(d)/src/command-ref/%.md
|
||||
@printf "Title: %s\n\n" "$$(basename $@ .8)" > $^.tmp
|
||||
@cat $^ >> $^.tmp
|
||||
$(trace-gen) lowdown -sT man $^.tmp -o $@
|
||||
@rm $^.tmp
|
||||
|
||||
$(d)/nix.conf.5: $(d)/src/command-ref/conf-file.md
|
||||
@printf "Title: %s\n\n" "$$(basename $@ .5)" > $^.tmp
|
||||
@cat $^ >> $^.tmp
|
||||
$(trace-gen) lowdown -sT man $^.tmp -o $@
|
||||
@rm $^.tmp
|
||||
|
||||
$(d)/src/SUMMARY.md: $(d)/src/SUMMARY.md.in $(d)/src/command-ref/new-cli
|
||||
$(trace-gen) cat doc/manual/src/SUMMARY.md.in | while IFS= read line; do if [[ $$line = @manpages@ ]]; then cat doc/manual/src/command-ref/new-cli/SUMMARY.md; else echo "$$line"; fi; done > $@.tmp
|
||||
@mv $@.tmp $@
|
||||
|
||||
$(d)/src/command-ref/new-cli: $(d)/nix.json $(d)/generate-manpage.nix $(bindir)/nix
|
||||
@rm -rf $@
|
||||
$(trace-gen) $(nix-eval) --write-to $@ --expr 'import doc/manual/generate-manpage.nix (builtins.fromJSON (builtins.readFile $<))'
|
||||
|
||||
$(d)/src/command-ref/conf-file.md: $(d)/conf-file.json $(d)/generate-options.nix $(d)/src/command-ref/conf-file-prefix.md $(bindir)/nix
|
||||
@cat doc/manual/src/command-ref/conf-file-prefix.md > $@.tmp
|
||||
$(trace-gen) $(nix-eval) --expr 'import doc/manual/generate-options.nix (builtins.fromJSON (builtins.readFile $<))' >> $@.tmp
|
||||
@mv $@.tmp $@
|
||||
|
||||
$(d)/nix.json: $(bindir)/nix
|
||||
$(trace-gen) $(dummy-env) $(bindir)/nix __dump-args > $@.tmp
|
||||
@mv $@.tmp $@
|
||||
|
||||
$(d)/conf-file.json: $(bindir)/nix
|
||||
$(trace-gen) $(dummy-env) $(bindir)/nix show-config --json --experimental-features nix-command > $@.tmp
|
||||
@mv $@.tmp $@
|
||||
|
||||
$(d)/src/expressions/builtins.md: $(d)/builtins.json $(d)/generate-builtins.nix $(d)/src/expressions/builtins-prefix.md $(bindir)/nix
|
||||
@cat doc/manual/src/expressions/builtins-prefix.md > $@.tmp
|
||||
$(trace-gen) $(nix-eval) --expr 'import doc/manual/generate-builtins.nix (builtins.fromJSON (builtins.readFile $<))' >> $@.tmp
|
||||
@mv $@.tmp $@
|
||||
|
||||
$(d)/builtins.json: $(bindir)/nix
|
||||
$(trace-gen) $(dummy-env) NIX_PATH=nix/corepkgs=corepkgs $(bindir)/nix __dump-builtins > $@.tmp
|
||||
@mv $@.tmp $@
|
||||
|
||||
# Generate the HTML manual.
|
||||
$(d)/manual.html: $(d)/manual.xml $(MANUAL_SRCS) $(d)/manual.is-valid
|
||||
$(trace-gen) $(XSLTPROC) --xinclude --stringparam profile.condition manual \
|
||||
$(docbookxsl)/profiling/profile.xsl $< | \
|
||||
$(XSLTPROC) --output $@ $(docbookxsl)/xhtml/docbook.xsl -
|
||||
install: $(docdir)/manual/index.html
|
||||
|
||||
$(foreach file, $(d)/manual.html $(d)/style.css, $(eval $(call install-data-in, $(file), $(docdir)/manual)))
|
||||
|
||||
$(foreach file, $(wildcard $(d)/figures/*.png), $(eval $(call install-data-in, $(file), $(docdir)/manual/figures)))
|
||||
|
||||
$(foreach file, $(wildcard $(d)/images/callouts/*.gif), $(eval $(call install-data-in, $(file), $(docdir)/manual/images/callouts)))
|
||||
|
||||
$(eval $(call install-symlink, manual.html, $(docdir)/manual/index.html))
|
||||
|
||||
|
||||
all: $(d)/manual.html
|
||||
|
||||
|
||||
|
||||
clean-files += $(d)/manual.html
|
||||
|
||||
dist-files += $(d)/manual.html
|
||||
# Generate 'nix' manpages.
|
||||
install: $(d)/src/command-ref/new-cli
|
||||
$(trace-gen) for i in doc/manual/src/command-ref/new-cli/*.md; do \
|
||||
name=$$(basename $$i .md); \
|
||||
if [[ $$name = SUMMARY ]]; then continue; fi; \
|
||||
printf "Title: %s\n\n" "$$name" > $$i.tmp; \
|
||||
cat $$i >> $$i.tmp; \
|
||||
lowdown -sT man $$i.tmp -o $(mandir)/man1/$$name.1; \
|
||||
done
|
||||
|
||||
$(docdir)/manual/index.html: $(MANUAL_SRCS) $(d)/book.toml $(d)/custom.css $(d)/src/SUMMARY.md $(d)/src/command-ref/new-cli $(d)/src/command-ref/conf-file.md $(d)/src/expressions/builtins.md
|
||||
$(trace-gen) RUST_LOG=warn mdbook build doc/manual -d $(docdir)/manual
|
||||
@cp doc/manual/highlight.pack.js $(docdir)/manual/highlight.js
|
||||
|
||||
endif
|
||||
|
|
|
|||
|
|
@ -1,52 +0,0 @@
|
|||
<book xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0">
|
||||
|
||||
<info>
|
||||
<title>Nix Package Manager Guide</title>
|
||||
<subtitle>Version <xi:include href="version.txt" parse="text" /></subtitle>
|
||||
|
||||
<author>
|
||||
<personname>
|
||||
<firstname>Eelco</firstname>
|
||||
<surname>Dolstra</surname>
|
||||
</personname>
|
||||
<contrib>Author</contrib>
|
||||
</author>
|
||||
|
||||
<copyright>
|
||||
<year>2004-2018</year>
|
||||
<holder>Eelco Dolstra</holder>
|
||||
</copyright>
|
||||
|
||||
</info>
|
||||
|
||||
<!--
|
||||
<preface>
|
||||
<title>Preface</title>
|
||||
<para>This manual describes how to set up and use the Nix package
|
||||
manager.</para>
|
||||
</preface>
|
||||
-->
|
||||
|
||||
<xi:include href="introduction/introduction.xml" />
|
||||
<xi:include href="installation/installation.xml" />
|
||||
<xi:include href="installation/upgrading.xml" />
|
||||
<xi:include href="packages/package-management.xml" />
|
||||
<xi:include href="expressions/writing-nix-expressions.xml" />
|
||||
<xi:include href="advanced-topics/advanced-topics.xml" />
|
||||
<xi:include href="command-ref/command-ref.xml" />
|
||||
<xi:include href="glossary/glossary.xml" />
|
||||
<xi:include href="hacking.xml" />
|
||||
<xi:include href="release-notes/release-notes.xml" />
|
||||
|
||||
<!--
|
||||
<appendix>
|
||||
<title>Nix Release Notes</title>
|
||||
<xi:include href="release-notes/release-notes.xml"
|
||||
xpointer="xmlns(x=http://docbook.org/ns/docbook)xpointer(x:article/x:section)" />
|
||||
</appendix>
|
||||
-->
|
||||
|
||||
</book>
|
||||
|
|
@ -1,182 +0,0 @@
|
|||
<appendix>
|
||||
<title>Nix Language Reference</title>
|
||||
|
||||
<sect1>
|
||||
<title>Grammar</title>
|
||||
|
||||
<productionset>
|
||||
<title>Expressions</title>
|
||||
|
||||
<production id="nix.expr">
|
||||
<lhs>Expr</lhs>
|
||||
<rhs>
|
||||
<nonterminal def="#nix.expr_function" />
|
||||
</rhs>
|
||||
</production>
|
||||
|
||||
<production id="nix.expr_function">
|
||||
<lhs>ExprFunction</lhs>
|
||||
<rhs>
|
||||
'{' <nonterminal def="#nix.formals" /> '}' ':' <nonterminal def="#nix.expr_function" />
|
||||
<sbr />|
|
||||
<nonterminal def="#nix.expr_assert" />
|
||||
</rhs>
|
||||
</production>
|
||||
|
||||
<production id="nix.expr_assert">
|
||||
<lhs>ExprAssert</lhs>
|
||||
<rhs>
|
||||
'assert' <nonterminal def="#nix.expr" /> ';' <nonterminal def="#nix.expr_assert" />
|
||||
<sbr />|
|
||||
<nonterminal def="#nix.expr_if" />
|
||||
</rhs>
|
||||
</production>
|
||||
|
||||
<production id="nix.expr_if">
|
||||
<lhs>ExprIf</lhs>
|
||||
<rhs>
|
||||
'if' <nonterminal def="#nix.expr" /> 'then' <nonterminal def="#nix.expr" />
|
||||
'else' <nonterminal def="#nix.expr" />
|
||||
<sbr />|
|
||||
<nonterminal def="#nix.expr_op" />
|
||||
</rhs>
|
||||
</production>
|
||||
|
||||
<production id="nix.expr_op">
|
||||
<lhs>ExprOp</lhs>
|
||||
<rhs>
|
||||
'!' <nonterminal def="#nix.expr_op" />
|
||||
<sbr />|
|
||||
<nonterminal def="#nix.expr_op" /> '==' <nonterminal def="#nix.expr_op" />
|
||||
<sbr />|
|
||||
<nonterminal def="#nix.expr_op" /> '!=' <nonterminal def="#nix.expr_op" />
|
||||
<sbr />|
|
||||
<nonterminal def="#nix.expr_op" /> '&&' <nonterminal def="#nix.expr_op" />
|
||||
<sbr />|
|
||||
<nonterminal def="#nix.expr_op" /> '||' <nonterminal def="#nix.expr_op" />
|
||||
<sbr />|
|
||||
<nonterminal def="#nix.expr_op" /> '->' <nonterminal def="#nix.expr_op" />
|
||||
<sbr />|
|
||||
<nonterminal def="#nix.expr_op" /> '//' <nonterminal def="#nix.expr_op" />
|
||||
<sbr />|
|
||||
<nonterminal def="#nix.expr_op" /> '~' <nonterminal def="#nix.expr_op" />
|
||||
<sbr />|
|
||||
<nonterminal def="#nix.expr_op" /> '?' <nonterminal def="#nix.id" />
|
||||
<sbr />|
|
||||
<nonterminal def="#nix.expr_app" />
|
||||
</rhs>
|
||||
</production>
|
||||
|
||||
<production id="nix.expr_app">
|
||||
<lhs>ExprApp</lhs>
|
||||
<rhs>
|
||||
<nonterminal def="#nix.expr_app" /> '.' <nonterminal def="#nix.expr_select" />
|
||||
<sbr />|
|
||||
<nonterminal def="#nix.expr_select" />
|
||||
</rhs>
|
||||
</production>
|
||||
|
||||
<production id="nix.expr_select">
|
||||
<lhs>ExprSelect</lhs>
|
||||
<rhs>
|
||||
<nonterminal def="#nix.expr_select" /> <nonterminal def="#nix.id" />
|
||||
<sbr />|
|
||||
<nonterminal def="#nix.expr_simple" />
|
||||
</rhs>
|
||||
</production>
|
||||
|
||||
<production id="nix.expr_simple">
|
||||
<lhs>ExprSimple</lhs>
|
||||
<rhs>
|
||||
<nonterminal def="#nix.id" /> |
|
||||
<nonterminal def="#nix.int" /> |
|
||||
<nonterminal def="#nix.str" /> |
|
||||
<nonterminal def="#nix.path" /> |
|
||||
<nonterminal def="#nix.uri" />
|
||||
<sbr />|
|
||||
'true' | 'false' | 'null'
|
||||
<sbr />|
|
||||
'(' <nonterminal def="#nix.expr" /> ')'
|
||||
<sbr />|
|
||||
'{' <nonterminal def="#nix.bind" />* '}'
|
||||
<sbr />|
|
||||
'let' '{' <nonterminal def="#nix.bind" />* '}'
|
||||
<sbr />|
|
||||
'rec' '{' <nonterminal def="#nix.bind" />* '}'
|
||||
<sbr />|
|
||||
'[' <nonterminal def="#nix.expr_select" />* ']'
|
||||
</rhs>
|
||||
</production>
|
||||
|
||||
<production id="nix.bind">
|
||||
<lhs>Bind</lhs>
|
||||
<rhs>
|
||||
<nonterminal def="#nix.id" /> '=' <nonterminal def="#nix.expr" /> ';'
|
||||
<sbr />|
|
||||
'inherit' ('(' <nonterminal def="#nix.expr" /> ')')? <nonterminal def="#nix.id" />* ';'
|
||||
</rhs>
|
||||
</production>
|
||||
|
||||
<production id="nix.formals">
|
||||
<lhs>Formals</lhs>
|
||||
<rhs>
|
||||
<nonterminal def="#nix.formal" /> ',' <nonterminal def="#nix.formals" />
|
||||
| <nonterminal def="#nix.formal" />
|
||||
</rhs>
|
||||
</production>
|
||||
|
||||
<production id="nix.formal">
|
||||
<lhs>Formal</lhs>
|
||||
<rhs>
|
||||
<nonterminal def="#nix.id" />
|
||||
<sbr />|
|
||||
<nonterminal def="#nix.id" /> '?' <nonterminal def="#nix.expr" />
|
||||
</rhs>
|
||||
</production>
|
||||
|
||||
</productionset>
|
||||
|
||||
<productionset>
|
||||
<title>Terminals</title>
|
||||
|
||||
<production id="nix.id">
|
||||
<lhs>Id</lhs>
|
||||
<rhs>[a-zA-Z\_][a-zA-Z0-9\_\']*</rhs>
|
||||
</production>
|
||||
|
||||
<production id="nix.int">
|
||||
<lhs>Int</lhs>
|
||||
<rhs>[0-9]+</rhs>
|
||||
</production>
|
||||
|
||||
<production id="nix.str">
|
||||
<lhs>Str</lhs>
|
||||
<rhs>\"[^\n\"]*\"</rhs>
|
||||
</production>
|
||||
|
||||
<production id="nix.path">
|
||||
<lhs>Path</lhs>
|
||||
<rhs>[a-zA-Z0-9\.\_\-\+]*(\/[a-zA-Z0-9\.\_\-\+]+)+</rhs>
|
||||
</production>
|
||||
|
||||
<production id="nix.uri">
|
||||
<lhs>Uri</lhs>
|
||||
<rhs>[a-zA-Z][a-zA-Z0-9\+\-\.]*\:[a-zA-Z0-9\%\/\?\:\@\&\=\+\$\,\-\_\.\!\~\*\']+</rhs>
|
||||
</production>
|
||||
|
||||
<production id="nix.ws">
|
||||
<lhs>Whitespace</lhs>
|
||||
<rhs>
|
||||
[ \t\n]+
|
||||
<sbr />|
|
||||
\#[^\n]*
|
||||
<sbr />|
|
||||
\/\*(.|\n)*\*\/
|
||||
</rhs>
|
||||
</production>
|
||||
|
||||
</productionset>
|
||||
|
||||
</sect1>
|
||||
|
||||
</appendix>
|
||||
|
|
@ -1,194 +0,0 @@
|
|||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-basic-package-mgmt">
|
||||
|
||||
<title>Basic Package Management</title>
|
||||
|
||||
<para>The main command for package management is <link
|
||||
linkend="sec-nix-env"><command>nix-env</command></link>. You can use
|
||||
it to install, upgrade, and erase packages, and to query what
|
||||
packages are installed or are available for installation.</para>
|
||||
|
||||
<para>In Nix, different users can have different “views”
|
||||
on the set of installed applications. That is, there might be lots of
|
||||
applications present on the system (possibly in many different
|
||||
versions), but users can have a specific selection of those active —
|
||||
where “active” just means that it appears in a directory
|
||||
in the user’s <envar>PATH</envar>. Such a view on the set of
|
||||
installed applications is called a <emphasis>user
|
||||
environment</emphasis>, which is just a directory tree consisting of
|
||||
symlinks to the files of the active applications. </para>
|
||||
|
||||
<para>Components are installed from a set of <emphasis>Nix
|
||||
expressions</emphasis> that tell Nix how to build those packages,
|
||||
including, if necessary, their dependencies. There is a collection of
|
||||
Nix expressions called the Nix Package collection that contains
|
||||
packages ranging from basic development stuff such as GCC and Glibc,
|
||||
to end-user applications like Mozilla Firefox. (Nix is however not
|
||||
tied to the Nix Package collection; you could write your own Nix
|
||||
expressions based on it, or completely new ones.)</para>
|
||||
|
||||
<para>You can manually download the latest version of Nixpkgs from
|
||||
<link xlink:href='http://nixos.org/nixpkgs/download.html'/>. However,
|
||||
it’s much more convenient to use the Nixpkgs
|
||||
<emphasis>channel</emphasis>, since it makes it easy to stay up to
|
||||
date with new versions of Nixpkgs. (Channels are described in more
|
||||
detail in <xref linkend="sec-channels"/>.) Nixpkgs is automatically
|
||||
added to your list of “subscribed” channels when you install
|
||||
Nix. If this is not the case for some reason, you can add it as
|
||||
follows:
|
||||
|
||||
<screen>
|
||||
$ nix-channel --add https://nixos.org/channels/nixpkgs-unstable
|
||||
$ nix-channel --update
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<note><para>On NixOS, you’re automatically subscribed to a NixOS
|
||||
channel corresponding to your NixOS major release
|
||||
(e.g. <uri>http://nixos.org/channels/nixos-14.12</uri>). A NixOS
|
||||
channel is identical to the Nixpkgs channel, except that it contains
|
||||
only Linux binaries and is updated only if a set of regression tests
|
||||
succeed.</para></note>
|
||||
|
||||
<para>You can view the set of available packages in Nixpkgs:
|
||||
|
||||
<screen>
|
||||
$ nix-env -qa
|
||||
aterm-2.2
|
||||
bash-3.0
|
||||
binutils-2.15
|
||||
bison-1.875d
|
||||
blackdown-1.4.2
|
||||
bzip2-1.0.2
|
||||
…</screen>
|
||||
|
||||
The flag <option>-q</option> specifies a query operation, and
|
||||
<option>-a</option> means that you want to show the “available” (i.e.,
|
||||
installable) packages, as opposed to the installed packages. If you
|
||||
downloaded Nixpkgs yourself, or if you checked it out from GitHub,
|
||||
then you need to pass the path to your Nixpkgs tree using the
|
||||
<option>-f</option> flag:
|
||||
|
||||
<screen>
|
||||
$ nix-env -qaf <replaceable>/path/to/nixpkgs</replaceable>
|
||||
</screen>
|
||||
|
||||
where <replaceable>/path/to/nixpkgs</replaceable> is where you’ve
|
||||
unpacked or checked out Nixpkgs.</para>
|
||||
|
||||
<para>You can select specific packages by name:
|
||||
|
||||
<screen>
|
||||
$ nix-env -qa firefox
|
||||
firefox-34.0.5
|
||||
firefox-with-plugins-34.0.5
|
||||
</screen>
|
||||
|
||||
and using regular expressions:
|
||||
|
||||
<screen>
|
||||
$ nix-env -qa 'firefox.*'
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>It is also possible to see the <emphasis>status</emphasis> of
|
||||
available packages, i.e., whether they are installed into the user
|
||||
environment and/or present in the system:
|
||||
|
||||
<screen>
|
||||
$ nix-env -qas
|
||||
…
|
||||
-PS bash-3.0
|
||||
--S binutils-2.15
|
||||
IPS bison-1.875d
|
||||
…</screen>
|
||||
|
||||
The first character (<literal>I</literal>) indicates whether the
|
||||
package is installed in your current user environment. The second
|
||||
(<literal>P</literal>) indicates whether it is present on your system
|
||||
(in which case installing it into your user environment would be a
|
||||
very quick operation). The last one (<literal>S</literal>) indicates
|
||||
whether there is a so-called <emphasis>substitute</emphasis> for the
|
||||
package, which is Nix’s mechanism for doing binary deployment. It
|
||||
just means that Nix knows that it can fetch a pre-built package from
|
||||
somewhere (typically a network server) instead of building it
|
||||
locally.</para>
|
||||
|
||||
<para>You can install a package using <literal>nix-env -i</literal>.
|
||||
For instance,
|
||||
|
||||
<screen>
|
||||
$ nix-env -i subversion</screen>
|
||||
|
||||
will install the package called <literal>subversion</literal> (which
|
||||
is, of course, the <link
|
||||
xlink:href='http://subversion.tigris.org/'>Subversion version
|
||||
management system</link>).</para>
|
||||
|
||||
<note><para>When you ask Nix to install a package, it will first try
|
||||
to get it in pre-compiled form from a <emphasis>binary
|
||||
cache</emphasis>. By default, Nix will use the binary cache
|
||||
<uri>https://cache.nixos.org</uri>; it contains binaries for most
|
||||
packages in Nixpkgs. Only if no binary is available in the binary
|
||||
cache, Nix will build the package from source. So if <literal>nix-env
|
||||
-i subversion</literal> results in Nix building stuff from source,
|
||||
then either the package is not built for your platform by the Nixpkgs
|
||||
build servers, or your version of Nixpkgs is too old or too new. For
|
||||
instance, if you have a very recent checkout of Nixpkgs, then the
|
||||
Nixpkgs build servers may not have had a chance to build everything
|
||||
and upload the resulting binaries to
|
||||
<uri>https://cache.nixos.org</uri>. The Nixpkgs channel is only
|
||||
updated after all binaries have been uploaded to the cache, so if you
|
||||
stick to the Nixpkgs channel (rather than using a Git checkout of the
|
||||
Nixpkgs tree), you will get binaries for most packages.</para></note>
|
||||
|
||||
<para>Naturally, packages can also be uninstalled:
|
||||
|
||||
<screen>
|
||||
$ nix-env -e subversion</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Upgrading to a new version is just as easy. If you have a new
|
||||
release of Nix Packages, you can do:
|
||||
|
||||
<screen>
|
||||
$ nix-env -u subversion</screen>
|
||||
|
||||
This will <emphasis>only</emphasis> upgrade Subversion if there is a
|
||||
“newer” version in the new set of Nix expressions, as
|
||||
defined by some pretty arbitrary rules regarding ordering of version
|
||||
numbers (which generally do what you’d expect of them). To just
|
||||
unconditionally replace Subversion with whatever version is in the Nix
|
||||
expressions, use <parameter>-i</parameter> instead of
|
||||
<parameter>-u</parameter>; <parameter>-i</parameter> will remove
|
||||
whatever version is already installed.</para>
|
||||
|
||||
<para>You can also upgrade all packages for which there are newer
|
||||
versions:
|
||||
|
||||
<screen>
|
||||
$ nix-env -u</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Sometimes it’s useful to be able to ask what
|
||||
<command>nix-env</command> would do, without actually doing it. For
|
||||
instance, to find out what packages would be upgraded by
|
||||
<literal>nix-env -u</literal>, you can do
|
||||
|
||||
<screen>
|
||||
$ nix-env -u --dry-run
|
||||
(dry run; not doing anything)
|
||||
upgrading `libxslt-1.1.0' to `libxslt-1.1.10'
|
||||
upgrading `graphviz-1.10' to `graphviz-1.12'
|
||||
upgrading `coreutils-5.0' to `coreutils-5.2.1'</screen>
|
||||
|
||||
</para>
|
||||
|
||||
</chapter>
|
||||
|
|
@ -1,70 +0,0 @@
|
|||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ssec-binary-cache-substituter">
|
||||
|
||||
<title>Serving a Nix store via HTTP</title>
|
||||
|
||||
<para>You can easily share the Nix store of a machine via HTTP. This
|
||||
allows other machines to fetch store paths from that machine to speed
|
||||
up installations. It uses the same <emphasis>binary cache</emphasis>
|
||||
mechanism that Nix usually uses to fetch pre-built binaries from
|
||||
<uri>https://cache.nixos.org</uri>.</para>
|
||||
|
||||
<para>The daemon that handles binary cache requests via HTTP,
|
||||
<command>nix-serve</command>, is not part of the Nix distribution, but
|
||||
you can install it from Nixpkgs:
|
||||
|
||||
<screen>
|
||||
$ nix-env -i nix-serve
|
||||
</screen>
|
||||
|
||||
You can then start the server, listening for HTTP connections on
|
||||
whatever port you like:
|
||||
|
||||
<screen>
|
||||
$ nix-serve -p 8080
|
||||
</screen>
|
||||
|
||||
To check whether it works, try the following on the client:
|
||||
|
||||
<screen>
|
||||
$ curl http://avalon:8080/nix-cache-info
|
||||
</screen>
|
||||
|
||||
which should print something like:
|
||||
|
||||
<screen>
|
||||
StoreDir: /nix/store
|
||||
WantMassQuery: 1
|
||||
Priority: 30
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>On the client side, you can tell Nix to use your binary cache
|
||||
using <option>--option extra-binary-caches</option>, e.g.:
|
||||
|
||||
<screen>
|
||||
$ nix-env -i firefox --option extra-binary-caches http://avalon:8080/
|
||||
</screen>
|
||||
|
||||
The option <option>extra-binary-caches</option> tells Nix to use this
|
||||
binary cache in addition to your default caches, such as
|
||||
<uri>https://cache.nixos.org</uri>. Thus, for any path in the closure
|
||||
of Firefox, Nix will first check if the path is available on the
|
||||
server <literal>avalon</literal> or another binary caches. If not, it
|
||||
will fall back to building from source.</para>
|
||||
|
||||
<para>You can also tell Nix to always use your binary cache by adding
|
||||
a line to the <filename linkend="sec-conf-file">nix.conf</filename>
|
||||
configuration file like this:
|
||||
|
||||
<programlisting>
|
||||
binary-caches = http://avalon:8080/ https://cache.nixos.org/
|
||||
</programlisting>
|
||||
|
||||
</para>
|
||||
|
||||
</section>
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue