mirror of
https://github.com/CHN-beta/nixpkgs.git
synced 2026-01-12 19:00:19 +08:00
Compare commits
1 Commits
19.03
...
backups/0.
| Author | SHA1 | Date | |
|---|---|---|---|
|
f5c7d72813 |
@@ -1,28 +0,0 @@
|
||||
# EditorConfig configuration for nixpkgs
|
||||
# http://EditorConfig.org
|
||||
|
||||
# Top-most EditorConfig file
|
||||
root = true
|
||||
|
||||
# Unix-style newlines with a newline ending every file, utf-8 charset
|
||||
[*]
|
||||
end_of_line = lf
|
||||
insert_final_newline = true
|
||||
trim_trailing_whitespace = true
|
||||
charset = utf-8
|
||||
|
||||
# see https://nixos.org/nixpkgs/manual/#chap-conventions
|
||||
|
||||
# Match nix/ruby/docbook files, set indent to spaces with width of two
|
||||
[*.{nix,rb,xml}]
|
||||
indent_style = space
|
||||
indent_size = 2
|
||||
|
||||
# Match shell/python/perl scripts, set indent to spaces with width of four
|
||||
[*.{sh,py,pl}]
|
||||
indent_style = space
|
||||
indent_size = 4
|
||||
|
||||
# Match diffs, avoid to trim trailing whitespace
|
||||
[*.{diff,patch}]
|
||||
trim_trailing_whitespace = false
|
||||
16
.gitattributes
vendored
16
.gitattributes
vendored
@@ -1,16 +0,0 @@
|
||||
**/deps.nix linguist-generated
|
||||
**/node-packages.nix linguist-generated
|
||||
|
||||
pkgs/applications/editors/emacs-modes/*-generated.nix linguist-generated
|
||||
pkgs/development/r-modules/*-packages.nix linguist-generated
|
||||
pkgs/development/haskell-modules/hackage-packages.nix linguist-generated
|
||||
pkgs/development/beam-modules/hex-packages.nix linguist-generated
|
||||
|
||||
doc/** linguist-documentation
|
||||
doc/default.nix linguist-documentation=false
|
||||
|
||||
nixos/doc/** linguist-documentation
|
||||
nixos/doc/default.nix linguist-documentation=false
|
||||
|
||||
nixos/modules/module-list.nix merge=union
|
||||
# pkgs/top-level/all-packages.nix merge=union
|
||||
133
.github/CODEOWNERS
vendored
133
.github/CODEOWNERS
vendored
@@ -1,133 +0,0 @@
|
||||
# CODEOWNERS file
|
||||
#
|
||||
# This file is used to describe who owns what in this repository. This file does not
|
||||
# replace `meta.maintainers` but is instead used for other things than derivations
|
||||
# and modules, like documentation, package sets, and other assets.
|
||||
#
|
||||
# For documentation on this file, see https://help.github.com/articles/about-codeowners/
|
||||
# Mentioned users will get code review requests.
|
||||
|
||||
# This file
|
||||
/.github/CODEOWNERS @edolstra
|
||||
|
||||
# Libraries
|
||||
/lib @edolstra @nbp
|
||||
/lib/systems @nbp @ericson2314 @matthewbauer
|
||||
/lib/generators.nix @edolstra @nbp @Profpatsch
|
||||
/lib/debug.nix @edolstra @nbp @Profpatsch
|
||||
|
||||
# Nixpkgs Internals
|
||||
/default.nix @nbp
|
||||
/pkgs/top-level/default.nix @nbp @Ericson2314
|
||||
/pkgs/top-level/impure.nix @nbp @Ericson2314
|
||||
/pkgs/top-level/stage.nix @nbp @Ericson2314 @matthewbauer
|
||||
/pkgs/top-level/splice.nix @Ericson2314 @matthewbauer
|
||||
/pkgs/top-level/release-cross.nix @Ericson2314 @matthewbauer
|
||||
/pkgs/stdenv/generic @Ericson2314 @matthewbauer
|
||||
/pkgs/stdenv/cross @Ericson2314 @matthewbauer
|
||||
/pkgs/build-support/cc-wrapper @Ericson2314 @orivej
|
||||
/pkgs/build-support/bintools-wrapper @Ericson2314 @orivej
|
||||
/pkgs/build-support/setup-hooks @Ericson2314
|
||||
|
||||
# NixOS Internals
|
||||
/nixos/default.nix @nbp
|
||||
/nixos/lib/from-env.nix @nbp
|
||||
/nixos/lib/eval-config.nix @nbp
|
||||
/nixos/doc/manual/configuration/abstractions.xml @nbp
|
||||
/nixos/doc/manual/configuration/config-file.xml @nbp
|
||||
/nixos/doc/manual/configuration/config-syntax.xml @nbp
|
||||
/nixos/doc/manual/configuration/modularity.xml @nbp
|
||||
/nixos/doc/manual/development/assertions.xml @nbp
|
||||
/nixos/doc/manual/development/meta-attributes.xml @nbp
|
||||
/nixos/doc/manual/development/option-declarations.xml @nbp
|
||||
/nixos/doc/manual/development/option-def.xml @nbp
|
||||
/nixos/doc/manual/development/option-types.xml @nbp
|
||||
/nixos/doc/manual/development/replace-modules.xml @nbp
|
||||
/nixos/doc/manual/development/writing-modules.xml @nbp
|
||||
/nixos/doc/manual/man-nixos-option.xml @nbp
|
||||
/nixos/modules/installer/tools/nixos-option.sh @nbp
|
||||
|
||||
# NixOS modules
|
||||
/nixos/modules @Infinisil
|
||||
|
||||
# Python-related code and docs
|
||||
/maintainers/scripts/update-python-libraries @FRidh
|
||||
/pkgs/top-level/python-packages.nix @FRidh
|
||||
/pkgs/development/interpreters/python @FRidh
|
||||
/pkgs/development/python-modules @FRidh
|
||||
/doc/languages-frameworks/python.section.md @FRidh
|
||||
|
||||
# Haskell
|
||||
/pkgs/development/compilers/ghc @peti @ryantm @basvandijk
|
||||
/pkgs/development/haskell-modules @peti @ryantm @basvandijk
|
||||
/pkgs/development/haskell-modules/default.nix @peti @ryantm @basvandijk
|
||||
/pkgs/development/haskell-modules/generic-builder.nix @peti @ryantm @basvandijk
|
||||
/pkgs/development/haskell-modules/hoogle.nix @peti @ryantm @basvandijk
|
||||
|
||||
# Perl
|
||||
/pkgs/development/interpreters/perl @volth
|
||||
/pkgs/top-level/perl-packages.nix @volth
|
||||
/pkgs/development/perl-modules @volth
|
||||
|
||||
# R
|
||||
/pkgs/applications/science/math/R @peti
|
||||
/pkgs/development/r-modules @peti
|
||||
|
||||
# Ruby
|
||||
/pkgs/development/interpreters/ruby @alyssais @zimbatm
|
||||
/pkgs/development/ruby-modules @alyssais @zimbatm
|
||||
|
||||
# Rust
|
||||
/pkgs/development/compilers/rust @Mic92 @LnL7
|
||||
|
||||
# Darwin-related
|
||||
/pkgs/stdenv/darwin @NixOS/darwin-maintainers
|
||||
/pkgs/os-specific/darwin @NixOS/darwin-maintainers
|
||||
|
||||
# C compilers
|
||||
/pkgs/development/compilers/gcc @matthewbauer
|
||||
/pkgs/development/compilers/llvm @matthewbauer
|
||||
|
||||
# Compatibility stuff
|
||||
/pkgs/top-level/unix-tools.nix @matthewbauer
|
||||
/pkgs/development/tools/xcbuild @matthewbauer
|
||||
|
||||
# Beam-related (Erlang, Elixir, LFE, etc)
|
||||
/pkgs/development/beam-modules @gleber
|
||||
/pkgs/development/interpreters/erlang @gleber
|
||||
/pkgs/development/interpreters/lfe @gleber
|
||||
/pkgs/development/interpreters/elixir @gleber
|
||||
/pkgs/development/tools/build-managers/rebar @gleber
|
||||
/pkgs/development/tools/build-managers/rebar3 @gleber
|
||||
/pkgs/development/tools/erlang @gleber
|
||||
|
||||
# Jetbrains
|
||||
/pkgs/applications/editors/jetbrains @edwtjo
|
||||
|
||||
# Eclipse
|
||||
/pkgs/applications/editors/eclipse @rycee
|
||||
|
||||
# https://github.com/NixOS/nixpkgs/issues/31401
|
||||
/lib/licenses.nix @ghost
|
||||
|
||||
# Qt / KDE
|
||||
/pkgs/applications/kde @ttuegel
|
||||
/pkgs/desktops/plasma-5 @ttuegel
|
||||
/pkgs/development/libraries/kde-frameworks @ttuegel
|
||||
/pkgs/development/libraries/qt-5 @ttuegel
|
||||
|
||||
# PostgreSQL and related stuff
|
||||
/pkgs/servers/sql/postgresql @thoughtpolice
|
||||
/nixos/modules/services/databases/postgresql.xml @thoughtpolice
|
||||
/nixos/modules/services/databases/postgresql.nix @thoughtpolice
|
||||
/nixos/tests/postgresql.nix @thoughtpolice
|
||||
|
||||
# Dhall
|
||||
/pkgs/development/dhall-modules @Gabriel439 @Profpatsch
|
||||
/pkgs/development/interpreters/dhall @Gabriel439 @Profpatsch
|
||||
|
||||
# Idris
|
||||
/pkgs/development/idris-modules @Infinisil
|
||||
|
||||
# Bazel
|
||||
/pkgs/development/tools/build-managers/bazel @mboes @Profpatsch
|
||||
54
.github/CONTRIBUTING.md
vendored
54
.github/CONTRIBUTING.md
vendored
@@ -1,54 +0,0 @@
|
||||
# How to contribute
|
||||
|
||||
Note: contributing implies licensing those contributions
|
||||
under the terms of [COPYING](../COPYING), which is an MIT-like license.
|
||||
|
||||
## Opening issues
|
||||
|
||||
* Make sure you have a [GitHub account](https://github.com/signup/free)
|
||||
* [Submit an issue](https://github.com/NixOS/nixpkgs/issues) - assuming one does not already exist.
|
||||
* Clearly describe the issue including steps to reproduce when it is a bug.
|
||||
* Include information what version of nixpkgs and Nix are you using (nixos-version or git revision).
|
||||
|
||||
## Submitting changes
|
||||
|
||||
* Format the commit messages in the following way:
|
||||
|
||||
```
|
||||
(pkg-name | nixos/<module>): (from -> to | init at version | refactor | etc)
|
||||
|
||||
(Motivation for change. Additional information.)
|
||||
```
|
||||
|
||||
For consistency, there should not be a period at the end of the commit message's summary line (the first line of the commit message).
|
||||
|
||||
Examples:
|
||||
|
||||
* nginx: init at 2.0.1
|
||||
* firefox: 54.0.1 -> 55.0
|
||||
* nixos/hydra: add bazBaz option
|
||||
|
||||
Dual baz behavior is needed to do foo.
|
||||
* nixos/nginx: refactor config generation
|
||||
|
||||
The old config generation system used impure shell scripts and could break in specific circumstances (see #1234).
|
||||
|
||||
* `meta.description` should:
|
||||
* Be capitalized.
|
||||
* Not start with the package name.
|
||||
* Not have a period at the end.
|
||||
* `meta.license` must be set and fit the upstream license.
|
||||
* If there is no upstream license, `meta.license` should default to `stdenv.lib.licenses.unfree`.
|
||||
* `meta.maintainers` must be set.
|
||||
|
||||
See the nixpkgs manual for more details on [standard meta-attributes](https://nixos.org/nixpkgs/manual/#sec-standard-meta-attributes) and on how to [submit changes to nixpkgs](https://nixos.org/nixpkgs/manual/#chap-submitting-changes).
|
||||
|
||||
## Writing good commit messages
|
||||
|
||||
In addition to writing properly formatted commit messages, it's important to include relevant information so other developers can later understand *why* a change was made. While this information usually can be found by digging code, mailing list/Discourse archives, pull request discussions or upstream changes, it may require a lot of work.
|
||||
|
||||
For package version upgrades and such a one-line commit message is usually sufficient.
|
||||
|
||||
## Reviewing contributions
|
||||
|
||||
See the nixpkgs manual for more details on how to [Review contributions](https://nixos.org/nixpkgs/manual/#sec-reviewing-contributions).
|
||||
12
.github/ISSUE_TEMPLATE.md
vendored
12
.github/ISSUE_TEMPLATE.md
vendored
@@ -1,12 +0,0 @@
|
||||
## Issue description
|
||||
|
||||
|
||||
|
||||
### Steps to reproduce
|
||||
|
||||
|
||||
|
||||
## Technical details
|
||||
|
||||
Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the
|
||||
results.
|
||||
21
.github/PULL_REQUEST_TEMPLATE.md
vendored
21
.github/PULL_REQUEST_TEMPLATE.md
vendored
@@ -1,21 +0,0 @@
|
||||
###### Motivation for this change
|
||||
|
||||
|
||||
###### Things done
|
||||
|
||||
<!-- Please check what applies. Note that these are not hard requirements but merely serve as information for reviewers. -->
|
||||
|
||||
- [ ] Tested using sandboxing ([nix.useSandbox](http://nixos.org/nixos/manual/options.html#opt-nix.useSandbox) on NixOS, or option `sandbox` in [`nix.conf`](http://nixos.org/nix/manual/#sec-conf-file) on non-NixOS)
|
||||
- Built on platform(s)
|
||||
- [ ] NixOS
|
||||
- [ ] macOS
|
||||
- [ ] other Linux distributions
|
||||
- [ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
|
||||
- [ ] Tested compilation of all pkgs that depend on this change using `nix-shell -p nox --run "nox-review wip"`
|
||||
- [ ] Tested execution of all binary files (usually in `./result/bin/`)
|
||||
- [ ] Determined the impact on package closure size (by running `nix path-info -S` before and after)
|
||||
- [ ] Assured whether relevant documentation is up to date
|
||||
- [ ] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md).
|
||||
|
||||
---
|
||||
|
||||
17
.gitignore
vendored
17
.gitignore
vendored
@@ -1,17 +0,0 @@
|
||||
*~
|
||||
,*
|
||||
.*.swp
|
||||
.*.swo
|
||||
result
|
||||
result-*
|
||||
/doc/NEWS.html
|
||||
/doc/NEWS.txt
|
||||
/doc/manual.html
|
||||
/doc/manual.pdf
|
||||
.version-suffix
|
||||
|
||||
.DS_Store
|
||||
|
||||
/pkgs/development/libraries/qt-5/*/tmp/
|
||||
/pkgs/desktops/kde-5/*/tmp/
|
||||
/pkgs/development/mobile/androidenv/xml/*
|
||||
20
COPYING
20
COPYING
@@ -1,20 +0,0 @@
|
||||
Copyright (c) 2003-2019 Eelco Dolstra and the Nixpkgs/NixOS contributors
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining
|
||||
a copy of this software and associated documentation files (the
|
||||
"Software"), to deal in the Software without restriction, including
|
||||
without limitation the rights to use, copy, modify, merge, publish,
|
||||
distribute, sublicense, and/or sell copies of the Software, and to
|
||||
permit persons to whom the Software is furnished to do so, subject to
|
||||
the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be
|
||||
included in all copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
||||
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
||||
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
||||
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
|
||||
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
|
||||
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
|
||||
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
47
README.md
47
README.md
@@ -1,47 +0,0 @@
|
||||
[<img src="https://nixos.org/logo/nixos-hires.png" width="500px" alt="logo" />](https://nixos.org/nixos)
|
||||
|
||||
[](https://www.codetriage.com/nixos/nixpkgs)
|
||||
|
||||
Nixpkgs is a collection of packages for the [Nix](https://nixos.org/nix/) package
|
||||
manager. It is periodically built and tested by the [Hydra](https://hydra.nixos.org/)
|
||||
build daemon as so-called channels. To get channel information via git, add
|
||||
[nixpkgs-channels](https://github.com/NixOS/nixpkgs-channels.git) as a remote:
|
||||
|
||||
```
|
||||
% git remote add channels https://github.com/NixOS/nixpkgs-channels.git
|
||||
```
|
||||
|
||||
For stability and maximum binary package support, it is recommended to maintain
|
||||
custom changes on top of one of the channels, e.g. `nixos-19.03` for the latest
|
||||
release and `nixos-unstable` for the latest successful build of master:
|
||||
|
||||
```
|
||||
% git remote update channels
|
||||
% git rebase channels/nixos-19.03
|
||||
```
|
||||
|
||||
For pull requests, please rebase onto nixpkgs `master`.
|
||||
|
||||
[NixOS](https://nixos.org/nixos/) Linux distribution source code is located inside
|
||||
`nixos/` folder.
|
||||
|
||||
* [NixOS installation instructions](https://nixos.org/nixos/manual/#ch-installation)
|
||||
* [Documentation (Nix Expression Language chapter)](https://nixos.org/nix/manual/#ch-expression-language)
|
||||
* [Manual (How to write packages for Nix)](https://nixos.org/nixpkgs/manual/)
|
||||
* [Manual (NixOS)](https://nixos.org/nixos/manual/)
|
||||
* [Community maintained wiki](https://nixos.wiki/)
|
||||
* [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
|
||||
* [Continuous package builds for 19.03 release](https://hydra.nixos.org/jobset/nixos/release-19.03)
|
||||
* [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
|
||||
* [Tests for 19.03 release](https://hydra.nixos.org/job/nixos/release-19.03/tested#tabs-constituents)
|
||||
|
||||
Communication:
|
||||
|
||||
* [Discourse Forum](https://discourse.nixos.org/)
|
||||
* [IRC - #nixos on freenode.net](irc://irc.freenode.net/#nixos)
|
||||
|
||||
Note: MIT license does not apply to the packages built by Nixpkgs, merely to
|
||||
the package descriptions (Nix expressions, build scripts, and so on). It also
|
||||
might not apply to patches included in Nixpkgs, which may be derivative works
|
||||
of the packages to which they apply. The aforementioned artifacts are all
|
||||
covered by the licenses of the respective packages.
|
||||
28
default.nix
28
default.nix
@@ -1,28 +0,0 @@
|
||||
let requiredVersion = import ./lib/minver.nix; in
|
||||
|
||||
if ! builtins ? nixVersion || builtins.compareVersions requiredVersion builtins.nixVersion == 1 then
|
||||
|
||||
abort ''
|
||||
|
||||
This version of Nixpkgs requires Nix >= ${requiredVersion}, please upgrade:
|
||||
|
||||
- If you are running NixOS, `nixos-rebuild' can be used to upgrade your system.
|
||||
|
||||
- Alternatively, with Nix > 2.0 `nix upgrade-nix' can be used to imperatively
|
||||
upgrade Nix. You may use `nix-env --version' to check which version you have.
|
||||
|
||||
- If you installed Nix using the install script (https://nixos.org/nix/install),
|
||||
it is safe to upgrade by running it again:
|
||||
|
||||
curl https://nixos.org/nix/install | sh
|
||||
|
||||
For more information, please see the NixOS release notes at
|
||||
https://nixos.org/nixos/manual or locally at
|
||||
${toString ./nixos/doc/manual/release-notes}.
|
||||
|
||||
If you need further help, see https://nixos.org/nixos/support.html
|
||||
''
|
||||
|
||||
else
|
||||
|
||||
import ./pkgs/top-level/impure.nix
|
||||
7
doc/.gitignore
vendored
7
doc/.gitignore
vendored
@@ -1,7 +0,0 @@
|
||||
*.chapter.xml
|
||||
*.section.xml
|
||||
.version
|
||||
out
|
||||
manual-full.xml
|
||||
highlightjs
|
||||
functions/library/locations.xml
|
||||
112
doc/Makefile
112
doc/Makefile
@@ -1,112 +0,0 @@
|
||||
MD_TARGETS=$(addsuffix .xml, $(basename $(wildcard ./*.md ./**/*.md)))
|
||||
|
||||
.PHONY: all
|
||||
all: validate format out/html/index.html out/epub/manual.epub
|
||||
|
||||
.PHONY: debug
|
||||
debug:
|
||||
nix-shell --run "xmloscopy --docbook5 ./manual.xml ./manual-full.xml"
|
||||
|
||||
.PHONY: format
|
||||
format:
|
||||
find . -iname '*.xml' -type f | while read f; do \
|
||||
echo $$f ;\
|
||||
xmlformat --config-file "$$XMLFORMAT_CONFIG" -i $$f ;\
|
||||
done
|
||||
|
||||
.PHONY: fix-misc-xml
|
||||
fix-misc-xml:
|
||||
find . -iname '*.xml' -type f \
|
||||
-exec ../nixos/doc/varlistentry-fixer.rb {} ';'
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -f ${MD_TARGETS} .version manual-full.xml functions/library/locations.xml functions/library/generated
|
||||
rm -rf ./out/ ./highlightjs
|
||||
|
||||
.PHONY: validate
|
||||
validate: manual-full.xml
|
||||
jing "$$RNG" manual-full.xml
|
||||
|
||||
out/html/index.html: manual-full.xml style.css highlightjs
|
||||
mkdir -p out/html
|
||||
xsltproc ${xsltFlags} \
|
||||
--nonet --xinclude \
|
||||
--output $@ \
|
||||
"$$XSL/docbook/xhtml/docbook.xsl" \
|
||||
./manual-full.xml
|
||||
|
||||
mkdir -p out/html/highlightjs/
|
||||
cp -r highlightjs out/html/
|
||||
|
||||
cp ./overrides.css out/html/
|
||||
cp ./style.css out/html/style.css
|
||||
|
||||
mkdir -p out/html/images/callouts
|
||||
cp "$$XSL/docbook/images/callouts/"*.svg out/html/images/callouts/
|
||||
chmod u+w -R out/html/
|
||||
|
||||
out/epub/manual.epub: manual-full.xml
|
||||
mkdir -p out/epub/scratch
|
||||
xsltproc ${xsltFlags} --nonet \
|
||||
--output out/epub/scratch/ \
|
||||
"$$XSL/docbook/epub/docbook.xsl" \
|
||||
./manual-full.xml
|
||||
|
||||
cp ./overrides.css out/epub/scratch/OEBPS
|
||||
cp ./style.css out/epub/scratch/OEBPS
|
||||
mkdir -p out/epub/scratch/OEBPS/images/callouts/
|
||||
cp "$$XSL/docbook/images/callouts/"*.svg out/epub/scratch/OEBPS/images/callouts/
|
||||
echo "application/epub+zip" > mimetype
|
||||
zip -0Xq "out/epub/manual.epub" mimetype
|
||||
rm mimetype
|
||||
cd "out/epub/scratch/" && zip -Xr9D "../manual.epub" *
|
||||
rm -rf "out/epub/scratch/"
|
||||
|
||||
highlightjs:
|
||||
mkdir -p highlightjs
|
||||
cp -r "$$HIGHLIGHTJS/highlight.pack.js" highlightjs/
|
||||
cp -r "$$HIGHLIGHTJS/LICENSE" highlightjs/
|
||||
cp -r "$$HIGHLIGHTJS/mono-blue.css" highlightjs/
|
||||
cp -r "$$HIGHLIGHTJS/loader.js" highlightjs/
|
||||
|
||||
|
||||
manual-full.xml: ${MD_TARGETS} .version functions/library/locations.xml functions/library/generated *.xml **/*.xml **/**/*.xml
|
||||
xmllint --nonet --xinclude --noxincludenode manual.xml --output manual-full.xml
|
||||
|
||||
.version:
|
||||
nix-instantiate --eval \
|
||||
-E '(import ../lib).version' > .version
|
||||
|
||||
function_locations := $(shell nix-build --no-out-link ./lib-function-locations.nix)
|
||||
|
||||
functions/library/locations.xml:
|
||||
ln -s $(function_locations) ./functions/library/locations.xml
|
||||
|
||||
functions/library/generated:
|
||||
nix-build ./lib-function-docs.nix \
|
||||
--arg locationsXml $(function_locations)\
|
||||
--out-link ./functions/library/generated
|
||||
|
||||
%.section.xml: %.section.md
|
||||
pandoc $^ -w docbook+smart \
|
||||
-f markdown+smart \
|
||||
| sed -e 's|<ulink url=|<link xlink:href=|' \
|
||||
-e 's|</ulink>|</link>|' \
|
||||
-e 's|<sect. id=|<section xml:id=|' \
|
||||
-e 's|</sect[0-9]>|</section>|' \
|
||||
-e '1s| id=| xml:id=|' \
|
||||
-e '1s|\(<[^ ]* \)|\1xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" |' \
|
||||
| cat > $@
|
||||
|
||||
%.chapter.xml: %.chapter.md
|
||||
pandoc $^ -w docbook+smart \
|
||||
--top-level-division=chapter \
|
||||
-f markdown+smart \
|
||||
| sed -e 's|<ulink url=|<link xlink:href=|' \
|
||||
-e 's|</ulink>|</link>|' \
|
||||
-e 's|<sect. id=|<section xml:id=|' \
|
||||
-e 's|</sect[0-9]>|</section>|' \
|
||||
-e '1s| id=| xml:id=|' \
|
||||
-e '1s|\(<[^ ]* \)|\1|' \
|
||||
| cat > $@
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,546 +0,0 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="chap-packageconfig">
|
||||
<title>Global configuration</title>
|
||||
<para>
|
||||
Nix comes with certain defaults about what packages can and cannot be
|
||||
installed, based on a package's metadata. By default, Nix will prevent
|
||||
installation if any of the following criteria are true:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
The package is thought to be broken, and has had its
|
||||
<literal>meta.broken</literal> set to <literal>true</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The package isn't intended to run on the given system, as none of its
|
||||
<literal>meta.platforms</literal> match the given system.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The package's <literal>meta.license</literal> is set to a license which is
|
||||
considered to be unfree.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The package has known security vulnerabilities but has not or can not be
|
||||
updated for some reason, and a list of issues has been entered in to the
|
||||
package's <literal>meta.knownVulnerabilities</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>
|
||||
Note that all this is checked during evaluation already, and the check
|
||||
includes any package that is evaluated. In particular, all build-time
|
||||
dependencies are checked. <literal>nix-env -qa</literal> will (attempt to)
|
||||
hide any packages that would be refused.
|
||||
</para>
|
||||
<para>
|
||||
Each of these criteria can be altered in the nixpkgs configuration.
|
||||
</para>
|
||||
<para>
|
||||
The nixpkgs configuration for a NixOS system is set in the
|
||||
<literal>configuration.nix</literal>, as in the following example:
|
||||
<programlisting>
|
||||
{
|
||||
nixpkgs.config = {
|
||||
allowUnfree = true;
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
However, this does not allow unfree software for individual users. Their
|
||||
configurations are managed separately.
|
||||
</para>
|
||||
<para>
|
||||
A user's of nixpkgs configuration is stored in a user-specific configuration
|
||||
file located at <filename>~/.config/nixpkgs/config.nix</filename>. For
|
||||
example:
|
||||
<programlisting>
|
||||
{
|
||||
allowUnfree = true;
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
Note that we are not able to test or build unfree software on Hydra due to
|
||||
policy. Most unfree licenses prohibit us from either executing or
|
||||
distributing the software.
|
||||
</para>
|
||||
<section xml:id="sec-allow-broken">
|
||||
<title>Installing broken packages</title>
|
||||
|
||||
<para>
|
||||
There are two ways to try compiling a package which has been marked as
|
||||
broken.
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
For allowing the build of a broken package once, you can use an
|
||||
environment variable for a single invocation of the nix tools:
|
||||
<programlisting>$ export NIXPKGS_ALLOW_BROKEN=1</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
For permanently allowing broken packages to be built, you may add
|
||||
<literal>allowBroken = true;</literal> to your user's configuration file,
|
||||
like this:
|
||||
<programlisting>
|
||||
{
|
||||
allowBroken = true;
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section xml:id="sec-allow-unsupported-system">
|
||||
<title>Installing packages on unsupported systems</title>
|
||||
|
||||
<para>
|
||||
There are also two ways to try compiling a package which has been marked as
|
||||
unsuported for the given system.
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
For allowing the build of a broken package once, you can use an
|
||||
environment variable for a single invocation of the nix tools:
|
||||
<programlisting>$ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
For permanently allowing broken packages to be built, you may add
|
||||
<literal>allowUnsupportedSystem = true;</literal> to your user's
|
||||
configuration file, like this:
|
||||
<programlisting>
|
||||
{
|
||||
allowUnsupportedSystem = true;
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
The difference between a package being unsupported on some system and
|
||||
being broken is admittedly a bit fuzzy. If a program
|
||||
<emphasis>ought</emphasis> to work on a certain platform, but doesn't, the
|
||||
platform should be included in <literal>meta.platforms</literal>, but marked
|
||||
as broken with e.g. <literal>meta.broken =
|
||||
!hostPlatform.isWindows</literal>. Of course, this begs the question of what
|
||||
"ought" means exactly. That is left to the package maintainer.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="sec-allow-unfree">
|
||||
<title>Installing unfree packages</title>
|
||||
|
||||
<para>
|
||||
There are several ways to tweak how Nix handles a package which has been
|
||||
marked as unfree.
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
To temporarily allow all unfree packages, you can use an environment
|
||||
variable for a single invocation of the nix tools:
|
||||
<programlisting>$ export NIXPKGS_ALLOW_UNFREE=1</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
It is possible to permanently allow individual unfree packages, while
|
||||
still blocking unfree packages by default using the
|
||||
<literal>allowUnfreePredicate</literal> configuration option in the user
|
||||
configuration file.
|
||||
</para>
|
||||
<para>
|
||||
This option is a function which accepts a package as a parameter, and
|
||||
returns a boolean. The following example configuration accepts a package
|
||||
and always returns false:
|
||||
<programlisting>
|
||||
{
|
||||
allowUnfreePredicate = (pkg: false);
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
For a more useful example, try the following. This configuration
|
||||
only allows unfree packages named flash player and visual studio
|
||||
code:
|
||||
<programlisting>
|
||||
{
|
||||
allowUnfreePredicate = (pkg: builtins.elem
|
||||
(builtins.parseDrvName pkg.name).name [
|
||||
"flashplayer"
|
||||
"vscode"
|
||||
]);
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
It is also possible to whitelist and blacklist licenses that are
|
||||
specifically acceptable or not acceptable, using
|
||||
<literal>whitelistedLicenses</literal> and
|
||||
<literal>blacklistedLicenses</literal>, respectively.
|
||||
</para>
|
||||
<para>
|
||||
The following example configuration whitelists the licenses
|
||||
<literal>amd</literal> and <literal>wtfpl</literal>:
|
||||
<programlisting>
|
||||
{
|
||||
whitelistedLicenses = with stdenv.lib.licenses; [ amd wtfpl ];
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
The following example configuration blacklists the <literal>gpl3</literal>
|
||||
and <literal>agpl3</literal> licenses:
|
||||
<programlisting>
|
||||
{
|
||||
blacklistedLicenses = with stdenv.lib.licenses; [ agpl3 gpl3 ];
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
A complete list of licenses can be found in the file
|
||||
<filename>lib/licenses.nix</filename> of the nixpkgs tree.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="sec-allow-insecure">
|
||||
<title>Installing insecure packages</title>
|
||||
|
||||
<para>
|
||||
There are several ways to tweak how Nix handles a package which has been
|
||||
marked as insecure.
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
To temporarily allow all insecure packages, you can use an environment
|
||||
variable for a single invocation of the nix tools:
|
||||
<programlisting>$ export NIXPKGS_ALLOW_INSECURE=1</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
It is possible to permanently allow individual insecure packages, while
|
||||
still blocking other insecure packages by default using the
|
||||
<literal>permittedInsecurePackages</literal> configuration option in the
|
||||
user configuration file.
|
||||
</para>
|
||||
<para>
|
||||
The following example configuration permits the installation of the
|
||||
hypothetically insecure package <literal>hello</literal>, version
|
||||
<literal>1.2.3</literal>:
|
||||
<programlisting>
|
||||
{
|
||||
permittedInsecurePackages = [
|
||||
"hello-1.2.3"
|
||||
];
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
It is also possible to create a custom policy around which insecure
|
||||
packages to allow and deny, by overriding the
|
||||
<literal>allowInsecurePredicate</literal> configuration option.
|
||||
</para>
|
||||
<para>
|
||||
The <literal>allowInsecurePredicate</literal> option is a function which
|
||||
accepts a package and returns a boolean, much like
|
||||
<literal>allowUnfreePredicate</literal>.
|
||||
</para>
|
||||
<para>
|
||||
The following configuration example only allows insecure packages with
|
||||
very short names:
|
||||
<programlisting>
|
||||
{
|
||||
allowInsecurePredicate = (pkg: (builtins.stringLength (builtins.parseDrvName pkg.name).name) <= 5);
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
Note that <literal>permittedInsecurePackages</literal> is only checked if
|
||||
<literal>allowInsecurePredicate</literal> is not specified.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<!--============================================================-->
|
||||
<section xml:id="sec-modify-via-packageOverrides">
|
||||
<title>Modify packages via <literal>packageOverrides</literal></title>
|
||||
|
||||
<para>
|
||||
You can define a function called <varname>packageOverrides</varname> in your
|
||||
local <filename>~/.config/nixpkgs/config.nix</filename> to override Nix
|
||||
packages. It must be a function that takes pkgs as an argument and returns a
|
||||
modified set of packages.
|
||||
<programlisting>
|
||||
{
|
||||
packageOverrides = pkgs: rec {
|
||||
foo = pkgs.foo.override { ... };
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="sec-declarative-package-management">
|
||||
<title>Declarative Package Management</title>
|
||||
|
||||
<section xml:id="sec-building-environment">
|
||||
<title>Build an environment</title>
|
||||
|
||||
<para>
|
||||
Using <literal>packageOverrides</literal>, it is possible to manage
|
||||
packages declaratively. This means that we can list all of our desired
|
||||
packages within a declarative Nix expression. For example, to have
|
||||
<literal>aspell</literal>, <literal>bc</literal>,
|
||||
<literal>ffmpeg</literal>, <literal>coreutils</literal>,
|
||||
<literal>gdb</literal>, <literal>nixUnstable</literal>,
|
||||
<literal>emscripten</literal>, <literal>jq</literal>,
|
||||
<literal>nox</literal>, and <literal>silver-searcher</literal>, we could
|
||||
use the following in <filename>~/.config/nixpkgs/config.nix</filename>:
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
{
|
||||
packageOverrides = pkgs: with pkgs; {
|
||||
myPackages = pkgs.buildEnv {
|
||||
name = "my-packages";
|
||||
paths = [
|
||||
aspell
|
||||
bc
|
||||
coreutils
|
||||
gdb
|
||||
ffmpeg
|
||||
nixUnstable
|
||||
emscripten
|
||||
jq
|
||||
nox
|
||||
silver-searcher
|
||||
];
|
||||
};
|
||||
};
|
||||
}
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
To install it into our environment, you can just run <literal>nix-env -iA
|
||||
nixpkgs.myPackages</literal>. If you want to load the packages to be built
|
||||
from a working copy of <literal>nixpkgs</literal> you just run
|
||||
<literal>nix-env -f. -iA myPackages</literal>. To explore what's been
|
||||
installed, just look through <filename>~/.nix-profile/</filename>. You can
|
||||
see that a lot of stuff has been installed. Some of this stuff is useful
|
||||
some of it isn't. Let's tell Nixpkgs to only link the stuff that we want:
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
{
|
||||
packageOverrides = pkgs: with pkgs; {
|
||||
myPackages = pkgs.buildEnv {
|
||||
name = "my-packages";
|
||||
paths = [
|
||||
aspell
|
||||
bc
|
||||
coreutils
|
||||
gdb
|
||||
ffmpeg
|
||||
nixUnstable
|
||||
emscripten
|
||||
jq
|
||||
nox
|
||||
silver-searcher
|
||||
];
|
||||
pathsToLink = [ "/share" "/bin" ];
|
||||
};
|
||||
};
|
||||
}
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
<literal>pathsToLink</literal> tells Nixpkgs to only link the paths listed
|
||||
which gets rid of the extra stuff in the profile. <filename>/bin</filename>
|
||||
and <filename>/share</filename> are good defaults for a user environment,
|
||||
getting rid of the clutter. If you are running on Nix on MacOS, you may
|
||||
want to add another path as well, <filename>/Applications</filename>, that
|
||||
makes GUI apps available.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-getting-documentation">
|
||||
<title>Getting documentation</title>
|
||||
|
||||
<para>
|
||||
After building that new environment, look through
|
||||
<filename>~/.nix-profile</filename> to make sure everything is there that
|
||||
we wanted. Discerning readers will note that some files are missing. Look
|
||||
inside <filename>~/.nix-profile/share/man/man1/</filename> to verify this.
|
||||
There are no man pages for any of the Nix tools! This is because some
|
||||
packages like Nix have multiple outputs for things like documentation (see
|
||||
section 4). Let's make Nix install those as well.
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
{
|
||||
packageOverrides = pkgs: with pkgs; {
|
||||
myPackages = pkgs.buildEnv {
|
||||
name = "my-packages";
|
||||
paths = [
|
||||
aspell
|
||||
bc
|
||||
coreutils
|
||||
ffmpeg
|
||||
nixUnstable
|
||||
emscripten
|
||||
jq
|
||||
nox
|
||||
silver-searcher
|
||||
];
|
||||
pathsToLink = [ "/share/man" "/share/doc" "/bin" ];
|
||||
extraOutputsToInstall = [ "man" "doc" ];
|
||||
};
|
||||
};
|
||||
}
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
This provides us with some useful documentation for using our packages.
|
||||
However, if we actually want those manpages to be detected by man, we need
|
||||
to set up our environment. This can also be managed within Nix expressions.
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
{
|
||||
packageOverrides = pkgs: with pkgs; rec {
|
||||
myProfile = writeText "my-profile" ''
|
||||
export PATH=$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/sbin:/bin:/usr/sbin:/usr/bin
|
||||
export MANPATH=$HOME/.nix-profile/share/man:/nix/var/nix/profiles/default/share/man:/usr/share/man
|
||||
'';
|
||||
myPackages = pkgs.buildEnv {
|
||||
name = "my-packages";
|
||||
paths = [
|
||||
(runCommand "profile" {} ''
|
||||
mkdir -p $out/etc/profile.d
|
||||
cp ${myProfile} $out/etc/profile.d/my-profile.sh
|
||||
'')
|
||||
aspell
|
||||
bc
|
||||
coreutils
|
||||
ffmpeg
|
||||
man
|
||||
nixUnstable
|
||||
emscripten
|
||||
jq
|
||||
nox
|
||||
silver-searcher
|
||||
];
|
||||
pathsToLink = [ "/share/man" "/share/doc" "/bin" "/etc" ];
|
||||
extraOutputsToInstall = [ "man" "doc" ];
|
||||
};
|
||||
};
|
||||
}
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
For this to work fully, you must also have this script sourced when you are
|
||||
logged in. Try adding something like this to your
|
||||
<filename>~/.profile</filename> file:
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
#!/bin/sh
|
||||
if [ -d $HOME/.nix-profile/etc/profile.d ]; then
|
||||
for i in $HOME/.nix-profile/etc/profile.d/*.sh; do
|
||||
if [ -r $i ]; then
|
||||
. $i
|
||||
fi
|
||||
done
|
||||
fi
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
Now just run <literal>source $HOME/.profile</literal> and you can starting
|
||||
loading man pages from your environent.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-gnu-info-setup">
|
||||
<title>GNU info setup</title>
|
||||
|
||||
<para>
|
||||
Configuring GNU info is a little bit trickier than man pages. To work
|
||||
correctly, info needs a database to be generated. This can be done with
|
||||
some small modifications to our environment scripts.
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
{
|
||||
packageOverrides = pkgs: with pkgs; rec {
|
||||
myProfile = writeText "my-profile" ''
|
||||
export PATH=$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/sbin:/bin:/usr/sbin:/usr/bin
|
||||
export MANPATH=$HOME/.nix-profile/share/man:/nix/var/nix/profiles/default/share/man:/usr/share/man
|
||||
export INFOPATH=$HOME/.nix-profile/share/info:/nix/var/nix/profiles/default/share/info:/usr/share/info
|
||||
'';
|
||||
myPackages = pkgs.buildEnv {
|
||||
name = "my-packages";
|
||||
paths = [
|
||||
(runCommand "profile" {} ''
|
||||
mkdir -p $out/etc/profile.d
|
||||
cp ${myProfile} $out/etc/profile.d/my-profile.sh
|
||||
'')
|
||||
aspell
|
||||
bc
|
||||
coreutils
|
||||
ffmpeg
|
||||
man
|
||||
nixUnstable
|
||||
emscripten
|
||||
jq
|
||||
nox
|
||||
silver-searcher
|
||||
texinfoInteractive
|
||||
];
|
||||
pathsToLink = [ "/share/man" "/share/doc" "/share/info" "/bin" "/etc" ];
|
||||
extraOutputsToInstall = [ "man" "doc" "info" ];
|
||||
postBuild = ''
|
||||
if [ -x $out/bin/install-info -a -w $out/share/info ]; then
|
||||
shopt -s nullglob
|
||||
for i in $out/share/info/*.info $out/share/info/*.info.gz; do
|
||||
$out/bin/install-info $i $out/share/info/dir
|
||||
done
|
||||
fi
|
||||
'';
|
||||
};
|
||||
};
|
||||
}
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
<literal>postBuild</literal> tells Nixpkgs to run a command after building
|
||||
the environment. In this case, <literal>install-info</literal> adds the
|
||||
installed info pages to <literal>dir</literal> which is GNU info's default
|
||||
root node. Note that <literal>texinfoInteractive</literal> is added to the
|
||||
environment to give the <literal>install-info</literal> command.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
</chapter>
|
||||
@@ -1,35 +0,0 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="chap-contributing">
|
||||
<title>Contributing to this documentation</title>
|
||||
<para>
|
||||
The DocBook sources of the Nixpkgs manual are in the
|
||||
<filename
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/tree/master/doc">doc</filename>
|
||||
subdirectory of the Nixpkgs repository.
|
||||
</para>
|
||||
<para>
|
||||
You can quickly check your edits with <command>make</command>:
|
||||
</para>
|
||||
<screen>
|
||||
$ cd /path/to/nixpkgs/doc
|
||||
$ nix-shell
|
||||
[nix-shell]$ make
|
||||
</screen>
|
||||
<para>
|
||||
If you experience problems, run <command>make debug</command> to help
|
||||
understand the docbook errors.
|
||||
</para>
|
||||
<para>
|
||||
After making modifications to the manual, it's important to build it before
|
||||
committing. You can do that as follows:
|
||||
<screen>
|
||||
$ cd /path/to/nixpkgs/doc
|
||||
$ nix-shell
|
||||
[nix-shell]$ make clean
|
||||
[nix-shell]$ nix-build .
|
||||
</screen>
|
||||
If the build succeeds, the manual will be in
|
||||
<filename>./result/share/doc/nixpkgs/manual.html</filename>.
|
||||
</para>
|
||||
</chapter>
|
||||
@@ -1,468 +0,0 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="chap-cross">
|
||||
<title>Cross-compilation</title>
|
||||
<section xml:id="sec-cross-intro">
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>
|
||||
"Cross-compilation" means compiling a program on one machine for another type
|
||||
of machine. For example, a typical use of cross-compilation is to compile
|
||||
programs for embedded devices. These devices often don't have the computing
|
||||
power and memory to compile their own programs. One might think that
|
||||
cross-compilation is a fairly niche concern. However, there are significant
|
||||
advantages to rigorously distinguishing between build-time and run-time
|
||||
environments! This applies even when one is developing and deploying on the
|
||||
same machine. Nixpkgs is increasingly adopting the opinion that packages
|
||||
should be written with cross-compilation in mind, and nixpkgs should evaluate
|
||||
in a similar way (by minimizing cross-compilation-specific special cases)
|
||||
whether or not one is cross-compiling.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This chapter will be organized in three parts. First, it will describe the
|
||||
basics of how to package software in a way that supports cross-compilation.
|
||||
Second, it will describe how to use Nixpkgs when cross-compiling. Third, it
|
||||
will describe the internal infrastructure supporting cross-compilation.
|
||||
</para>
|
||||
</section>
|
||||
<!--============================================================-->
|
||||
<section xml:id="sec-cross-packaging">
|
||||
<title>Packaging in a cross-friendly manner</title>
|
||||
|
||||
<section xml:id="sec-cross-platform-parameters">
|
||||
<title>Platform parameters</title>
|
||||
|
||||
<para>
|
||||
Nixpkgs follows the <link
|
||||
xlink:href="https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html">conventions
|
||||
of GNU autoconf</link>. We distinguish between 3 types of platforms when
|
||||
building a derivation: <wordasword>build</wordasword>,
|
||||
<wordasword>host</wordasword>, and <wordasword>target</wordasword>. In
|
||||
summary, <wordasword>build</wordasword> is the platform on which a package
|
||||
is being built, <wordasword>host</wordasword> is the platform on which it
|
||||
will run. The third attribute, <wordasword>target</wordasword>, is relevant
|
||||
only for certain specific compilers and build tools.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In Nixpkgs, these three platforms are defined as attribute sets under the
|
||||
names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>,
|
||||
and <literal>targetPlatform</literal>. They are always defined as
|
||||
attributes in the standard environment. That means one can access them
|
||||
like:
|
||||
<programlisting>{ stdenv, fooDep, barDep, .. }: ...stdenv.buildPlatform...</programlisting>
|
||||
.
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>buildPlatform</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The "build platform" is the platform on which a package is built. Once
|
||||
someone has a built package, or pre-built binary package, the build
|
||||
platform should not matter and can be ignored.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>hostPlatform</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The "host platform" is the platform on which a package will be run. This
|
||||
is the simplest platform to understand, but also the one with the worst
|
||||
name.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>targetPlatform</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The "target platform" attribute is, unlike the other two attributes, not
|
||||
actually fundamental to the process of building software. Instead, it is
|
||||
only relevant for compatibility with building certain specific compilers
|
||||
and build tools. It can be safely ignored for all other packages.
|
||||
</para>
|
||||
<para>
|
||||
The build process of certain compilers is written in such a way that the
|
||||
compiler resulting from a single build can itself only produce binaries
|
||||
for a single platform. The task of specifying this single "target
|
||||
platform" is thus pushed to build time of the compiler. The root cause of
|
||||
this that the compiler (which will be run on the host) and the standard
|
||||
library/runtime (which will be run on the target) are built by a single
|
||||
build process.
|
||||
</para>
|
||||
<para>
|
||||
There is no fundamental need to think about a single target ahead of
|
||||
time like this. If the tool supports modular or pluggable backends, both
|
||||
the need to specify the target at build time and the constraint of
|
||||
having only a single target disappear. An example of such a tool is
|
||||
LLVM.
|
||||
</para>
|
||||
<para>
|
||||
Although the existence of a "target platfom" is arguably a historical
|
||||
mistake, it is a common one: examples of tools that suffer from it are
|
||||
GCC, Binutils, GHC and Autoconf. Nixpkgs tries to avoid sharing in the
|
||||
mistake where possible. Still, because the concept of a target platform
|
||||
is so ingrained, it is best to support it as is.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>
|
||||
The exact schema these fields follow is a bit ill-defined due to a long and
|
||||
convoluted evolution, but this is slowly being cleaned up. You can see
|
||||
examples of ones used in practice in
|
||||
<literal>lib.systems.examples</literal>; note how they are not all very
|
||||
consistent. For now, here are few fields can count on them containing:
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>system</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This is a two-component shorthand for the platform. Examples of this
|
||||
would be "x86_64-darwin" and "i686-linux"; see
|
||||
<literal>lib.systems.doubles</literal> for more. The first component
|
||||
corresponds to the CPU architecture of the platform and the second to the
|
||||
operating system of the platform (<literal>[cpu]-[os]</literal>). This
|
||||
format has built-in support in Nix, such as the
|
||||
<varname>builtins.currentSystem</varname> impure string.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>config</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This is a 3- or 4- component shorthand for the platform. Examples of this
|
||||
would be <literal>x86_64-unknown-linux-gnu</literal> and
|
||||
<literal>aarch64-apple-darwin14</literal>. This is a standard format
|
||||
called the "LLVM target triple", as they are pioneered by LLVM. In the
|
||||
4-part form, this corresponds to
|
||||
<literal>[cpu]-[vendor]-[os]-[abi]</literal>. This format is strictly
|
||||
more informative than the "Nix host double", as the previous format could
|
||||
analogously be termed. This needs a better name than
|
||||
<varname>config</varname>!
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>parsed</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This is a Nix representation of a parsed LLVM target triple
|
||||
with white-listed components. This can be specified directly,
|
||||
or actually parsed from the <varname>config</varname>. See
|
||||
<literal>lib.systems.parse</literal> for the exact
|
||||
representation.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>libc</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This is a string identifying the standard C library used. Valid
|
||||
identifiers include "glibc" for GNU libc, "libSystem" for Darwin's
|
||||
Libsystem, and "uclibc" for µClibc. It should probably be refactored to
|
||||
use the module system, like <varname>parse</varname>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>is*</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
These predicates are defined in <literal>lib.systems.inspect</literal>,
|
||||
and slapped onto every platform. They are superior to the ones in
|
||||
<varname>stdenv</varname> as they force the user to be explicit about
|
||||
which platform they are inspecting. Please use these instead of those.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>platform</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This is, quite frankly, a dumping ground of ad-hoc settings (it's an
|
||||
attribute set). See <literal>lib.systems.platforms</literal> for
|
||||
examples—there's hopefully one in there that will work verbatim for
|
||||
each platform that is working. Please help us triage these flags and
|
||||
give them better homes!
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-cross-specifying-dependencies">
|
||||
<title>Specifying Dependencies</title>
|
||||
|
||||
<para>
|
||||
In this section we explore the relationship between both runtime and
|
||||
build-time dependencies and the 3 Autoconf platforms.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A runtime dependency between 2 packages implies that between them both the
|
||||
host and target platforms match. This is directly implied by the meaning of
|
||||
"host platform" and "runtime dependency": The package dependency exists
|
||||
while both packages are running on a single host platform.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A build time dependency, however, implies a shift in platforms between the
|
||||
depending package and the depended-on package. The meaning of a build time
|
||||
dependency is that to build the depending package we need to be able to run
|
||||
the depended-on's package. The depending package's build platform is
|
||||
therefore equal to the depended-on package's host platform. Analogously,
|
||||
the depending package's host platform is equal to the depended-on package's
|
||||
target platform.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In this manner, given the 3 platforms for one package, we can determine the
|
||||
three platforms for all its transitive dependencies. This is the most
|
||||
important guiding principle behind cross-compilation with Nixpkgs, and will
|
||||
be called the <wordasword>sliding window principle</wordasword>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Some examples will make this clearer. If a package is being built with a
|
||||
<literal>(build, host, target)</literal> platform triple of <literal>(foo,
|
||||
bar, bar)</literal>, then its build-time dependencies would have a triple of
|
||||
<literal>(foo, foo, bar)</literal>, and <emphasis>those packages'</emphasis>
|
||||
build-time dependencies would have a triple of <literal>(foo, foo,
|
||||
foo)</literal>. In other words, it should take two "rounds" of following
|
||||
build-time dependency edges before one reaches a fixed point where, by the
|
||||
sliding window principle, the platform triple no longer changes. Indeed,
|
||||
this happens with cross-compilation, where only rounds of native
|
||||
dependencies starting with the second necessarily coincide with native
|
||||
packages.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
The depending package's target platform is unconstrained by the sliding
|
||||
window principle, which makes sense in that one can in principle build
|
||||
cross compilers targeting arbitrary platforms.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
How does this work in practice? Nixpkgs is now structured so that build-time
|
||||
dependencies are taken from <varname>buildPackages</varname>, whereas
|
||||
run-time dependencies are taken from the top level attribute set. For
|
||||
example, <varname>buildPackages.gcc</varname> should be used at build-time,
|
||||
while <varname>gcc</varname> should be used at run-time. Now, for most of
|
||||
Nixpkgs's history, there was no <varname>buildPackages</varname>, and most
|
||||
packages have not been refactored to use it explicitly. Instead, one can use
|
||||
the six (<emphasis>gasp</emphasis>) attributes used for specifying
|
||||
dependencies as documented in <xref linkend="ssec-stdenv-dependencies"/>. We
|
||||
"splice" together the run-time and build-time package sets with
|
||||
<varname>callPackage</varname>, and then <varname>mkDerivation</varname> for
|
||||
each of four attributes pulls the right derivation out. This splicing can be
|
||||
skipped when not cross-compiling as the package sets are the same, but is a
|
||||
bit slow for cross-compiling. Because of this, a best-of-both-worlds
|
||||
solution is in the works with no splicing or explicit access of
|
||||
<varname>buildPackages</varname> needed. For now, feel free to use either
|
||||
method.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
There is also a "backlink" <varname>targetPackages</varname>, yielding a
|
||||
package set whose <varname>buildPackages</varname> is the current package
|
||||
set. This is a hack, though, to accommodate compilers with lousy build
|
||||
systems. Please do not use this unless you are absolutely sure you are
|
||||
packaging such a compiler and there is no other way.
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-cross-cookbook">
|
||||
<title>Cross packaging cookbook</title>
|
||||
|
||||
<para>
|
||||
Some frequently encountered problems when packaging for cross-compilation
|
||||
should be answered here. Ideally, the information above is exhaustive, so
|
||||
this section cannot provide any new information, but it is ludicrous and
|
||||
cruel to expect everyone to spend effort working through the interaction of
|
||||
many features just to figure out the same answer to the same common problem.
|
||||
Feel free to add to this list!
|
||||
</para>
|
||||
|
||||
<qandaset>
|
||||
<qandaentry xml:id="cross-qa-build-c-program-in-build-environment">
|
||||
<question>
|
||||
<para>
|
||||
What if my package's build system needs to build a C program to be run
|
||||
under the build environment?
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
<programlisting>depsBuildBuild = [ buildPackages.stdenv.cc ];</programlisting>
|
||||
Add it to your <function>mkDerivation</function> invocation.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
<qandaentry xml:id="cross-qa-fails-to-find-ar">
|
||||
<question>
|
||||
<para>
|
||||
My package fails to find <command>ar</command>.
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
Many packages assume that an unprefixed <command>ar</command> is
|
||||
available, but Nix doesn't provide one. It only provides a prefixed one,
|
||||
just as it only does for all the other binutils programs. It may be
|
||||
necessary to patch the package to fix the build system to use a prefixed
|
||||
`ar`.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
<qandaentry xml:id="cross-testsuite-runs-host-code">
|
||||
<question>
|
||||
<para>
|
||||
My package's testsuite needs to run host platform code.
|
||||
</para>
|
||||
</question>
|
||||
<answer>
|
||||
<para>
|
||||
<programlisting>doCheck = stdenv.hostPlatform != stdenv.buildPlatfrom;</programlisting>
|
||||
Add it to your <function>mkDerivation</function> invocation.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
</qandaset>
|
||||
</section>
|
||||
</section>
|
||||
<!--============================================================-->
|
||||
<section xml:id="sec-cross-usage">
|
||||
<title>Cross-building packages</title>
|
||||
|
||||
<para>
|
||||
Nixpkgs can be instantiated with <varname>localSystem</varname> alone, in
|
||||
which case there is no cross-compiling and everything is built by and for
|
||||
that system, or also with <varname>crossSystem</varname>, in which case
|
||||
packages run on the latter, but all building happens on the former. Both
|
||||
parameters take the same schema as the 3 (build, host, and target) platforms
|
||||
defined in the previous section. As mentioned above,
|
||||
<literal>lib.systems.examples</literal> has some platforms which are used as
|
||||
arguments for these parameters in practice. You can use them
|
||||
programmatically, or on the command line:
|
||||
<programlisting>
|
||||
nix-build <nixpkgs> --arg crossSystem '(import <nixpkgs/lib>).systems.examples.fooBarBaz' -A whatever</programlisting>
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Eventually we would like to make these platform examples an unnecessary
|
||||
convenience so that
|
||||
<programlisting>
|
||||
nix-build <nixpkgs> --arg crossSystem '{ config = "<arch>-<os>-<vendor>-<abi>"; }' -A whatever</programlisting>
|
||||
works in the vast majority of cases. The problem today is dependencies on
|
||||
other sorts of configuration which aren't given proper defaults. We rely on
|
||||
the examples to crudely to set those configuration parameters in some
|
||||
vaguely sane manner on the users behalf. Issue
|
||||
<link xlink:href="https://github.com/NixOS/nixpkgs/issues/34274">#34274</link>
|
||||
tracks this inconvenience along with its root cause in crufty configuration
|
||||
options.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
While one is free to pass both parameters in full, there's a lot of logic to
|
||||
fill in missing fields. As discussed in the previous section, only one of
|
||||
<varname>system</varname>, <varname>config</varname>, and
|
||||
<varname>parsed</varname> is needed to infer the other two. Additionally,
|
||||
<varname>libc</varname> will be inferred from <varname>parse</varname>.
|
||||
Finally, <literal>localSystem.system</literal> is also
|
||||
<emphasis>impurely</emphasis> inferred based on the platform evaluation
|
||||
occurs. This means it is often not necessary to pass
|
||||
<varname>localSystem</varname> at all, as in the command-line example in the
|
||||
previous paragraph.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Many sources (manual, wiki, etc) probably mention passing
|
||||
<varname>system</varname>, <varname>platform</varname>, along with the
|
||||
optional <varname>crossSystem</varname> to nixpkgs: <literal>import
|
||||
<nixpkgs> { system = ..; platform = ..; crossSystem = ..;
|
||||
}</literal>. Passing those two instead of <varname>localSystem</varname> is
|
||||
still supported for compatibility, but is discouraged. Indeed, much of the
|
||||
inference we do for these parameters is motivated by compatibility as much
|
||||
as convenience.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
One would think that <varname>localSystem</varname> and
|
||||
<varname>crossSystem</varname> overlap horribly with the three
|
||||
<varname>*Platforms</varname> (<varname>buildPlatform</varname>,
|
||||
<varname>hostPlatform,</varname> and <varname>targetPlatform</varname>; see
|
||||
<varname>stage.nix</varname> or the manual). Actually, those identifiers are
|
||||
purposefully not used here to draw a subtle but important distinction: While
|
||||
the granularity of having 3 platforms is necessary to properly *build*
|
||||
packages, it is overkill for specifying the user's *intent* when making a
|
||||
build plan or package set. A simple "build vs deploy" dichotomy is adequate:
|
||||
the sliding window principle described in the previous section shows how to
|
||||
interpolate between the these two "end points" to get the 3 platform triple
|
||||
for each bootstrapping stage. That means for any package a given package set,
|
||||
even those not bound on the top level but only reachable via dependencies or
|
||||
<varname>buildPackages</varname>, the three platforms will be defined as one
|
||||
of <varname>localSystem</varname> or <varname>crossSystem</varname>, with the
|
||||
former replacing the latter as one traverses build-time dependencies. A last
|
||||
simple difference is that <varname>crossSystem</varname> should be null when
|
||||
one doesn't want to cross-compile, while the <varname>*Platform</varname>s
|
||||
are always non-null. <varname>localSystem</varname> is always non-null.
|
||||
</para>
|
||||
</section>
|
||||
<!--============================================================-->
|
||||
<section xml:id="sec-cross-infra">
|
||||
<title>Cross-compilation infrastructure</title>
|
||||
|
||||
<para>
|
||||
To be written.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
If one explores Nixpkgs, they will see derivations with names like
|
||||
<literal>gccCross</literal>. Such <literal>*Cross</literal> derivations is a
|
||||
holdover from before we properly distinguished between the host and target
|
||||
platforms—the derivation with "Cross" in the name covered the <literal>build
|
||||
= host != target</literal> case, while the other covered the <literal>host =
|
||||
target</literal>, with build platform the same or not based on whether one
|
||||
was using its <literal>.nativeDrv</literal> or <literal>.crossDrv</literal>.
|
||||
This ugliness will disappear soon.
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
</chapter>
|
||||
@@ -1,51 +0,0 @@
|
||||
{ pkgs ? (import ./.. { }), nixpkgs ? { }}:
|
||||
let
|
||||
lib = pkgs.lib;
|
||||
locationsXml = import ./lib-function-locations.nix { inherit pkgs nixpkgs; };
|
||||
functionDocs = import ./lib-function-docs.nix { inherit locationsXml pkgs; };
|
||||
in pkgs.stdenv.mkDerivation {
|
||||
name = "nixpkgs-manual";
|
||||
|
||||
buildInputs = with pkgs; [ pandoc libxml2 libxslt zip jing xmlformat ];
|
||||
|
||||
src = ./.;
|
||||
|
||||
# Hacking on these variables? Make sure to close and open
|
||||
# nix-shell between each test, maybe even:
|
||||
# $ nix-shell --run "make clean all"
|
||||
# otherwise they won't reapply :)
|
||||
HIGHLIGHTJS = pkgs.documentation-highlighter;
|
||||
XSL = "${pkgs.docbook_xsl_ns}/xml/xsl";
|
||||
RNG = "${pkgs.docbook5}/xml/rng/docbook/docbook.rng";
|
||||
XMLFORMAT_CONFIG = ../nixos/doc/xmlformat.conf;
|
||||
xsltFlags = lib.concatStringsSep " " [
|
||||
"--param section.autolabel 1"
|
||||
"--param section.label.includes.component.label 1"
|
||||
"--stringparam html.stylesheet 'style.css overrides.css highlightjs/mono-blue.css'"
|
||||
"--stringparam html.script './highlightjs/highlight.pack.js ./highlightjs/loader.js'"
|
||||
"--param xref.with.number.and.title 1"
|
||||
"--param toc.section.depth 3"
|
||||
"--stringparam admon.style ''"
|
||||
"--stringparam callout.graphics.extension .svg"
|
||||
];
|
||||
|
||||
postPatch = ''
|
||||
rm -rf ./functions/library/locations.xml
|
||||
ln -s ${locationsXml} ./functions/library/locations.xml
|
||||
ln -s ${functionDocs} ./functions/library/generated
|
||||
echo ${lib.version} > .version
|
||||
'';
|
||||
|
||||
installPhase = ''
|
||||
dest="$out/share/doc/nixpkgs"
|
||||
mkdir -p "$(dirname "$dest")"
|
||||
mv out/html "$dest"
|
||||
mv "$dest/index.html" "$dest/manual.html"
|
||||
|
||||
mv out/epub/manual.epub "$dest/nixpkgs-manual.epub"
|
||||
|
||||
mkdir -p $out/nix-support/
|
||||
echo "doc manual $dest manual.html" >> $out/nix-support/hydra-build-products
|
||||
echo "doc manual $dest nixpkgs-manual.epub" >> $out/nix-support/hydra-build-products
|
||||
'';
|
||||
}
|
||||
@@ -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"
|
||||
xml:id="chap-functions">
|
||||
<title>Functions reference</title>
|
||||
<para>
|
||||
The nixpkgs repository has several utility functions to manipulate Nix
|
||||
expressions.
|
||||
</para>
|
||||
<xi:include href="functions/library.xml" />
|
||||
<xi:include href="functions/overrides.xml" />
|
||||
<xi:include href="functions/generators.xml" />
|
||||
<xi:include href="functions/debug.xml" />
|
||||
<xi:include href="functions/fetchers.xml" />
|
||||
<xi:include href="functions/trivial-builders.xml" />
|
||||
<xi:include href="functions/fhs-environments.xml" />
|
||||
<xi:include href="functions/shell.xml" />
|
||||
<xi:include href="functions/dockertools.xml" />
|
||||
<xi:include href="functions/appimagetools.xml" />
|
||||
<xi:include href="functions/prefer-remote-fetch.xml" />
|
||||
<xi:include href="functions/nix-gitignore.xml" />
|
||||
</chapter>
|
||||
@@ -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"
|
||||
xml:id="sec-pkgs-appimageTools">
|
||||
<title>pkgs.appimageTools</title>
|
||||
|
||||
<para>
|
||||
<varname>pkgs.appimageTools</varname> is a set of functions for extracting and wrapping
|
||||
<link xlink:href="https://appimage.org/">AppImage</link> files.
|
||||
|
||||
They are meant to be used if traditional packaging from source is infeasible, or it would take too long.
|
||||
To quickly run an AppImage file, <literal>pkgs.appimage-run</literal> can be used as well.
|
||||
</para>
|
||||
|
||||
<warning>
|
||||
<para>
|
||||
The <varname>appimageTools</varname> API is unstable and may be subject to
|
||||
backwards-incompatible changes in the future.
|
||||
</para>
|
||||
</warning>
|
||||
|
||||
|
||||
<section xml:id="ssec-pkgs-appimageTools-formats">
|
||||
<title>AppImage formats</title>
|
||||
|
||||
<para>
|
||||
There are different formats for AppImages, see
|
||||
<link xlink:href="https://github.com/AppImage/AppImageSpec/blob/74ad9ca2f94bf864a4a0dac1f369dd4f00bd1c28/draft.md#image-format">the specification</link> for details.
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Type 1 images are ISO 9660 files that are also ELF executables.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Type 2 images are ELF executables with an appended filesystem.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
They can be told apart with <command>file -k</command>:
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
<prompt>$ </prompt>file -k type1.AppImage
|
||||
type1.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) ISO 9660 CD-ROM filesystem data 'AppImage' (Lepton 3.x), scale 0-0,
|
||||
spot sensor temperature 0.000000, unit celsius, color scheme 0, calibration: offset 0.000000, slope 0.000000, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=d629f6099d2344ad82818172add1d38c5e11bc6d, stripped\012- data
|
||||
|
||||
<prompt>$ </prompt>file -k type2.AppImage
|
||||
type2.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) (Lepton 3.x), scale 232-60668, spot sensor temperature -4.187500, color scheme 15, show scale bar, calibration: offset -0.000000, slope 0.000000 (Lepton 2.x), scale 4111-45000, spot sensor temperature 412442.250000, color scheme 3, minimum point enabled, calibration: offset -75402534979642766821519867692934234112.000000, slope 5815371847733706829839455140374904832.000000, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=79dcc4e55a61c293c5e19edbd8d65b202842579f, stripped\012- data
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
Note how the type 1 AppImage is described as an <literal>ISO 9660 CD-ROM filesystem</literal>, and the type 2 AppImage is not.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="ssec-pkgs-appimageTools-wrapping">
|
||||
<title>Wrapping</title>
|
||||
|
||||
<para>
|
||||
Depending on the type of AppImage you're wrapping, you'll have to use
|
||||
<varname>wrapType1</varname> or <varname>wrapType2</varname>.
|
||||
</para>
|
||||
|
||||
|
||||
<programlisting>
|
||||
appimageTools.wrapType2 { # or wrapType1
|
||||
name = "patchwork"; <co xml:id='ex-appimageTools-wrapping-1' />
|
||||
src = fetchurl { <co xml:id='ex-appimageTools-wrapping-2' />
|
||||
url = https://github.com/ssbc/patchwork/releases/download/v3.11.4/Patchwork-3.11.4-linux-x86_64.AppImage;
|
||||
sha256 = "1blsprpkvm0ws9b96gb36f0rbf8f5jgmw4x6dsb1kswr4ysf591s";
|
||||
};
|
||||
extraPkgs = pkgs: with pkgs; [ ]; <co xml:id='ex-appimageTools-wrapping-3' />
|
||||
}</programlisting>
|
||||
|
||||
|
||||
<calloutlist>
|
||||
<callout arearefs='ex-appimageTools-wrapping-1'>
|
||||
<para>
|
||||
<varname>name</varname> specifies the name of the resulting image.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-appimageTools-wrapping-2'>
|
||||
<para>
|
||||
<varname>src</varname> specifies the AppImage file to extract.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-appimageTools-wrapping-2'>
|
||||
<para>
|
||||
<varname>extraPkgs</varname> allows you to pass a function to include additional packages
|
||||
inside the FHS environment your AppImage is going to run in.
|
||||
|
||||
There are a few ways to learn which dependencies an application needs:
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Looking through the extracted AppImage files, reading its scripts and running <command>patchelf</command> and <command>ldd</command> on its executables.
|
||||
This can also be done in <command>appimage-run</command>, by setting <command>APPIMAGE_DEBUG_EXEC=bash</command>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Running <command>strace -vfefile</command> on the wrapped executable, looking for libraries that can't be found.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</para>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
|
||||
</section>
|
||||
</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"
|
||||
xml:id="sec-debug">
|
||||
<title>Debugging Nix Expressions</title>
|
||||
|
||||
<para>
|
||||
Nix is a unityped, dynamic language, this means every value can potentially
|
||||
appear anywhere. Since it is also non-strict, evaluation order and what
|
||||
ultimately is evaluated might surprise you. Therefore it is important to be
|
||||
able to debug nix expressions.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the <literal>lib/debug.nix</literal> file you will find a number of
|
||||
functions that help (pretty-)printing values while evaluation is runnnig. You
|
||||
can even specify how deep these values should be printed recursively, and
|
||||
transform them on the fly. Please consult the docstrings in
|
||||
<literal>lib/debug.nix</literal> for usage information.
|
||||
</para>
|
||||
</section>
|
||||
@@ -1,564 +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"
|
||||
xml:id="sec-pkgs-dockerTools">
|
||||
<title>pkgs.dockerTools</title>
|
||||
|
||||
<para>
|
||||
<varname>pkgs.dockerTools</varname> is a set of functions for creating and
|
||||
manipulating Docker images according to the
|
||||
<link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#docker-image-specification-v120">
|
||||
Docker Image Specification v1.2.0 </link>. Docker itself is not used to
|
||||
perform any of the operations done by these functions.
|
||||
</para>
|
||||
|
||||
<warning>
|
||||
<para>
|
||||
The <varname>dockerTools</varname> API is unstable and may be subject to
|
||||
backwards-incompatible changes in the future.
|
||||
</para>
|
||||
</warning>
|
||||
|
||||
<section xml:id="ssec-pkgs-dockerTools-buildImage">
|
||||
<title>buildImage</title>
|
||||
|
||||
<para>
|
||||
This function is analogous to the <command>docker build</command> command,
|
||||
in that it can be used to build a Docker-compatible repository tarball containing
|
||||
a single image with one or multiple layers. As such, the result is suitable
|
||||
for being loaded in Docker with <command>docker load</command>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The parameters of <varname>buildImage</varname> with relative example values
|
||||
are described below:
|
||||
</para>
|
||||
|
||||
<example xml:id='ex-dockerTools-buildImage'>
|
||||
<title>Docker build</title>
|
||||
<programlisting>
|
||||
buildImage {
|
||||
name = "redis"; <co xml:id='ex-dockerTools-buildImage-1' />
|
||||
tag = "latest"; <co xml:id='ex-dockerTools-buildImage-2' />
|
||||
|
||||
fromImage = someBaseImage; <co xml:id='ex-dockerTools-buildImage-3' />
|
||||
fromImageName = null; <co xml:id='ex-dockerTools-buildImage-4' />
|
||||
fromImageTag = "latest"; <co xml:id='ex-dockerTools-buildImage-5' />
|
||||
|
||||
contents = pkgs.redis; <co xml:id='ex-dockerTools-buildImage-6' />
|
||||
runAsRoot = '' <co xml:id='ex-dockerTools-buildImage-runAsRoot' />
|
||||
#!${pkgs.runtimeShell}
|
||||
mkdir -p /data
|
||||
'';
|
||||
|
||||
config = { <co xml:id='ex-dockerTools-buildImage-8' />
|
||||
Cmd = [ "/bin/redis-server" ];
|
||||
WorkingDir = "/data";
|
||||
Volumes = {
|
||||
"/data" = {};
|
||||
};
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<para>
|
||||
The above example will build a Docker image <literal>redis/latest</literal>
|
||||
from the given base image. Loading and running this image in Docker results
|
||||
in <literal>redis-server</literal> being started automatically.
|
||||
</para>
|
||||
|
||||
<calloutlist>
|
||||
<callout arearefs='ex-dockerTools-buildImage-1'>
|
||||
<para>
|
||||
<varname>name</varname> specifies the name of the resulting image. This is
|
||||
the only required argument for <varname>buildImage</varname>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-2'>
|
||||
<para>
|
||||
<varname>tag</varname> specifies the tag of the resulting image. By
|
||||
default it's <literal>null</literal>, which indicates that the nix output
|
||||
hash will be used as tag.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-3'>
|
||||
<para>
|
||||
<varname>fromImage</varname> is the repository tarball containing the base
|
||||
image. It must be a valid Docker image, such as exported by
|
||||
<command>docker save</command>. By default it's <literal>null</literal>,
|
||||
which can be seen as equivalent to <literal>FROM scratch</literal> of a
|
||||
<filename>Dockerfile</filename>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-4'>
|
||||
<para>
|
||||
<varname>fromImageName</varname> can be used to further specify the base
|
||||
image within the repository, in case it contains multiple images. By
|
||||
default it's <literal>null</literal>, in which case
|
||||
<varname>buildImage</varname> will peek the first image available in the
|
||||
repository.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-5'>
|
||||
<para>
|
||||
<varname>fromImageTag</varname> can be used to further specify the tag of
|
||||
the base image within the repository, in case an image contains multiple
|
||||
tags. By default it's <literal>null</literal>, in which case
|
||||
<varname>buildImage</varname> will peek the first tag available for the
|
||||
base image.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-6'>
|
||||
<para>
|
||||
<varname>contents</varname> is a derivation that will be copied in the new
|
||||
layer of the resulting image. This can be similarly seen as <command>ADD
|
||||
contents/ /</command> in a <filename>Dockerfile</filename>. By default
|
||||
it's <literal>null</literal>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-runAsRoot'>
|
||||
<para>
|
||||
<varname>runAsRoot</varname> is a bash script that will run as root in an
|
||||
environment that overlays the existing layers of the base image with the
|
||||
new resulting layer, including the previously copied
|
||||
<varname>contents</varname> derivation. This can be similarly seen as
|
||||
<command>RUN ...</command> in a <filename>Dockerfile</filename>.
|
||||
<note>
|
||||
<para>
|
||||
Using this parameter requires the <literal>kvm</literal> device to be
|
||||
available.
|
||||
</para>
|
||||
</note>
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-buildImage-8'>
|
||||
<para>
|
||||
<varname>config</varname> is used to specify the configuration of the
|
||||
containers that will be started off the built image in Docker. The
|
||||
available options are listed in the
|
||||
<link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions">
|
||||
Docker Image Specification v1.2.0 </link>.
|
||||
</para>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
|
||||
<para>
|
||||
After the new layer has been created, its closure (to which
|
||||
<varname>contents</varname>, <varname>config</varname> and
|
||||
<varname>runAsRoot</varname> contribute) will be copied in the layer itself.
|
||||
Only new dependencies that are not already in the existing layers will be
|
||||
copied.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
At the end of the process, only one new single layer will be produced and
|
||||
added to the resulting image.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The resulting repository will only list the single image
|
||||
<varname>image/tag</varname>. In the case of
|
||||
<xref linkend='ex-dockerTools-buildImage'/> it would be
|
||||
<varname>redis/latest</varname>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It is possible to inspect the arguments with which an image was built using
|
||||
its <varname>buildArgs</varname> attribute.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
If you see errors similar to <literal>getProtocolByName: does not exist (no
|
||||
such protocol name: tcp)</literal> you may need to add
|
||||
<literal>pkgs.iana-etc</literal> to <varname>contents</varname>.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
If you see errors similar to <literal>Error_Protocol ("certificate has
|
||||
unknown CA",True,UnknownCa)</literal> you may need to add
|
||||
<literal>pkgs.cacert</literal> to <varname>contents</varname>.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<example xml:id="example-pkgs-dockerTools-buildImage-creation-date">
|
||||
<title>Impurely Defining a Docker Layer's Creation Date</title>
|
||||
<para>
|
||||
By default <function>buildImage</function> will use a static date of one
|
||||
second past the UNIX Epoch. This allows <function>buildImage</function> to
|
||||
produce binary reproducible images. When listing images with
|
||||
<command>docker images</command>, the newly created images will be
|
||||
listed like this:
|
||||
</para>
|
||||
<screen><![CDATA[
|
||||
$ docker images
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
hello latest 08c791c7846e 48 years ago 25.2MB
|
||||
]]></screen>
|
||||
<para>
|
||||
You can break binary reproducibility but have a sorted, meaningful
|
||||
<literal>CREATED</literal> column by setting <literal>created</literal> to
|
||||
<literal>now</literal>.
|
||||
</para>
|
||||
<programlisting><![CDATA[
|
||||
pkgs.dockerTools.buildImage {
|
||||
name = "hello";
|
||||
tag = "latest";
|
||||
created = "now";
|
||||
contents = pkgs.hello;
|
||||
|
||||
config.Cmd = [ "/bin/hello" ];
|
||||
}
|
||||
]]></programlisting>
|
||||
<para>
|
||||
and now the Docker CLI will display a reasonable date and sort the images
|
||||
as expected:
|
||||
<screen><![CDATA[
|
||||
$ docker images
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
hello latest de2bf4786de6 About a minute ago 25.2MB
|
||||
]]></screen>
|
||||
however, the produced images will not be binary reproducible.
|
||||
</para>
|
||||
</example>
|
||||
</section>
|
||||
|
||||
<section xml:id="ssec-pkgs-dockerTools-buildLayeredImage">
|
||||
<title>buildLayeredImage</title>
|
||||
|
||||
<para>
|
||||
Create a Docker image with many of the store paths being on their own layer
|
||||
to improve sharing between images.
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>name</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The name of the resulting image.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>tag</varname> <emphasis>optional</emphasis>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Tag of the generated image.
|
||||
</para>
|
||||
<para>
|
||||
<emphasis>Default:</emphasis> the output path's hash
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>contents</varname> <emphasis>optional</emphasis>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Top level paths in the container. Either a single derivation, or a list
|
||||
of derivations.
|
||||
</para>
|
||||
<para>
|
||||
<emphasis>Default:</emphasis> <literal>[]</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>config</varname> <emphasis>optional</emphasis>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Run-time configuration of the container. A full list of the options are
|
||||
available at in the
|
||||
<link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions">
|
||||
Docker Image Specification v1.2.0 </link>.
|
||||
</para>
|
||||
<para>
|
||||
<emphasis>Default:</emphasis> <literal>{}</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>created</varname> <emphasis>optional</emphasis>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Date and time the layers were created. Follows the same
|
||||
<literal>now</literal> exception supported by
|
||||
<literal>buildImage</literal>.
|
||||
</para>
|
||||
<para>
|
||||
<emphasis>Default:</emphasis> <literal>1970-01-01T00:00:01Z</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>maxLayers</varname> <emphasis>optional</emphasis>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Maximum number of layers to create.
|
||||
</para>
|
||||
<para>
|
||||
<emphasis>Default:</emphasis> <literal>24</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<section xml:id="dockerTools-buildLayeredImage-arg-contents">
|
||||
<title>Behavior of <varname>contents</varname> in the final image</title>
|
||||
|
||||
<para>
|
||||
Each path directly listed in <varname>contents</varname> will have a
|
||||
symlink in the root of the image.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For example:
|
||||
<programlisting><![CDATA[
|
||||
pkgs.dockerTools.buildLayeredImage {
|
||||
name = "hello";
|
||||
contents = [ pkgs.hello ];
|
||||
}
|
||||
]]></programlisting>
|
||||
will create symlinks for all the paths in the <literal>hello</literal>
|
||||
package:
|
||||
<screen><![CDATA[
|
||||
/bin/hello -> /nix/store/h1zb1padqbbb7jicsvkmrym3r6snphxg-hello-2.10/bin/hello
|
||||
/share/info/hello.info -> /nix/store/h1zb1padqbbb7jicsvkmrym3r6snphxg-hello-2.10/share/info/hello.info
|
||||
/share/locale/bg/LC_MESSAGES/hello.mo -> /nix/store/h1zb1padqbbb7jicsvkmrym3r6snphxg-hello-2.10/share/locale/bg/LC_MESSAGES/hello.mo
|
||||
]]></screen>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="dockerTools-buildLayeredImage-arg-config">
|
||||
<title>Automatic inclusion of <varname>config</varname> references</title>
|
||||
|
||||
<para>
|
||||
The closure of <varname>config</varname> is automatically included in the
|
||||
closure of the final image.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This allows you to make very simple Docker images with very little code.
|
||||
This container will start up and run <command>hello</command>:
|
||||
<programlisting><![CDATA[
|
||||
pkgs.dockerTools.buildLayeredImage {
|
||||
name = "hello";
|
||||
config.Cmd = [ "${pkgs.hello}/bin/hello" ];
|
||||
}
|
||||
]]></programlisting>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="dockerTools-buildLayeredImage-arg-maxLayers">
|
||||
<title>Adjusting <varname>maxLayers</varname></title>
|
||||
|
||||
<para>
|
||||
Increasing the <varname>maxLayers</varname> increases the number of layers
|
||||
which have a chance to be shared between different images.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Modern Docker installations support up to 128 layers, however older
|
||||
versions support as few as 42.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If the produced image will not be extended by other Docker builds, it is
|
||||
safe to set <varname>maxLayers</varname> to <literal>128</literal>. However
|
||||
it will be impossible to extend the image further.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The first (<literal>maxLayers-2</literal>) most "popular" paths will have
|
||||
their own individual layers, then layer #<literal>maxLayers-1</literal>
|
||||
will contain all the remaining "unpopular" paths, and finally layer
|
||||
#<literal>maxLayers</literal> will contain the Image configuration.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Docker's Layers are not inherently ordered, they are content-addressable
|
||||
and are not explicitly layered until they are composed in to an Image.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section xml:id="ssec-pkgs-dockerTools-fetchFromRegistry">
|
||||
<title>pullImage</title>
|
||||
|
||||
<para>
|
||||
This function is analogous to the <command>docker pull</command> command, in
|
||||
that it can be used to pull a Docker image from a Docker registry. By default
|
||||
<link xlink:href="https://hub.docker.com/">Docker Hub</link> is used to pull
|
||||
images.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Its parameters are described in the example below:
|
||||
</para>
|
||||
|
||||
<example xml:id='ex-dockerTools-pullImage'>
|
||||
<title>Docker pull</title>
|
||||
<programlisting>
|
||||
pullImage {
|
||||
imageName = "nixos/nix"; <co xml:id='ex-dockerTools-pullImage-1' />
|
||||
imageDigest = "sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b"; <co xml:id='ex-dockerTools-pullImage-2' />
|
||||
finalImageTag = "1.11"; <co xml:id='ex-dockerTools-pullImage-3' />
|
||||
sha256 = "0mqjy3zq2v6rrhizgb9nvhczl87lcfphq9601wcprdika2jz7qh8"; <co xml:id='ex-dockerTools-pullImage-4' />
|
||||
os = "linux"; <co xml:id='ex-dockerTools-pullImage-5' />
|
||||
arch = "x86_64"; <co xml:id='ex-dockerTools-pullImage-6' />
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<calloutlist>
|
||||
<callout arearefs='ex-dockerTools-pullImage-1'>
|
||||
<para>
|
||||
<varname>imageName</varname> specifies the name of the image to be
|
||||
downloaded, which can also include the registry namespace (e.g.
|
||||
<literal>nixos</literal>). This argument is required.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-pullImage-2'>
|
||||
<para>
|
||||
<varname>imageDigest</varname> specifies the digest of the image to be
|
||||
downloaded. Skopeo can be used to get the digest of an image, with its
|
||||
<varname>inspect</varname> subcommand. Since a given
|
||||
<varname>imageName</varname> may transparently refer to a manifest list of
|
||||
images which support multiple architectures and/or operating systems,
|
||||
supply the `--override-os` and `--override-arch` arguments to specify
|
||||
exactly which image you want. By default it will match the OS and
|
||||
architecture of the host the command is run on.
|
||||
<programlisting>
|
||||
$ nix-shell --packages skopeo jq --command "skopeo --override-os linux --override-arch x86_64 inspect docker://docker.io/nixos/nix:1.11 | jq -r '.Digest'"
|
||||
sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b
|
||||
</programlisting>
|
||||
This argument is required.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-pullImage-3'>
|
||||
<para>
|
||||
<varname>finalImageTag</varname>, if specified, this is the tag of the
|
||||
image to be created. Note it is never used to fetch the image since we
|
||||
prefer to rely on the immutable digest ID. By default it's
|
||||
<literal>latest</literal>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-pullImage-4'>
|
||||
<para>
|
||||
<varname>sha256</varname> is the checksum of the whole fetched image. This
|
||||
argument is required.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-pullImage-5'>
|
||||
<para>
|
||||
<varname>os</varname>, if specified, is the operating system of the
|
||||
fetched image. By default it's <literal>linux</literal>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-dockerTools-pullImage-6'>
|
||||
<para>
|
||||
<varname>arch</varname>, if specified, is the cpu architecture of the
|
||||
fetched image. By default it's <literal>x86_64</literal>.
|
||||
</para>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
</section>
|
||||
|
||||
<section xml:id="ssec-pkgs-dockerTools-exportImage">
|
||||
<title>exportImage</title>
|
||||
|
||||
<para>
|
||||
This function is analogous to the <command>docker export</command> command,
|
||||
in that it can be used to flatten a Docker image that contains multiple layers. It
|
||||
is in fact the result of the merge of all the layers of the image. As such,
|
||||
the result is suitable for being imported in Docker with <command>docker
|
||||
import</command>.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Using this function requires the <literal>kvm</literal> device to be
|
||||
available.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
The parameters of <varname>exportImage</varname> are the following:
|
||||
</para>
|
||||
|
||||
<example xml:id='ex-dockerTools-exportImage'>
|
||||
<title>Docker export</title>
|
||||
<programlisting>
|
||||
exportImage {
|
||||
fromImage = someLayeredImage;
|
||||
fromImageName = null;
|
||||
fromImageTag = null;
|
||||
|
||||
name = someLayeredImage.name;
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<para>
|
||||
The parameters relative to the base image have the same synopsis as
|
||||
described in <xref linkend='ssec-pkgs-dockerTools-buildImage'/>, except that
|
||||
<varname>fromImage</varname> is the only required argument in this case.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <varname>name</varname> argument is the name of the derivation output,
|
||||
which defaults to <varname>fromImage.name</varname>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="ssec-pkgs-dockerTools-shadowSetup">
|
||||
<title>shadowSetup</title>
|
||||
|
||||
<para>
|
||||
This constant string is a helper for setting up the base files for managing
|
||||
users and groups, only if such files don't exist already. It is suitable for
|
||||
being used in a <varname>runAsRoot</varname>
|
||||
<xref linkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like
|
||||
in the example below:
|
||||
</para>
|
||||
|
||||
<example xml:id='ex-dockerTools-shadowSetup'>
|
||||
<title>Shadow base files</title>
|
||||
<programlisting>
|
||||
buildImage {
|
||||
name = "shadow-basic";
|
||||
|
||||
runAsRoot = ''
|
||||
#!${pkgs.runtimeShell}
|
||||
${shadowSetup}
|
||||
groupadd -r redis
|
||||
useradd -r -g redis redis
|
||||
mkdir /data
|
||||
chown redis:redis /data
|
||||
'';
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<para>
|
||||
Creating base files like <literal>/etc/passwd</literal> or
|
||||
<literal>/etc/login.defs</literal> is necessary for shadow-utils to
|
||||
manipulate users and groups.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
@@ -1,206 +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"
|
||||
xml:id="sec-pkgs-fetchers">
|
||||
<title>Fetcher functions</title>
|
||||
|
||||
<para>
|
||||
When using Nix, you will frequently need to download source code
|
||||
and other files from the internet. Nixpkgs comes with a few helper
|
||||
functions that allow you to fetch fixed-output derivations in a
|
||||
structured way.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The two fetcher primitives are <function>fetchurl</function> and
|
||||
<function>fetchzip</function>. Both of these have two required
|
||||
arguments, a URL and a hash. The hash is typically
|
||||
<literal>sha256</literal>, although many more hash algorithms are
|
||||
supported. Nixpkgs contributors are currently recommended to use
|
||||
<literal>sha256</literal>. This hash will be used by Nix to
|
||||
identify your source. A typical usage of fetchurl is provided
|
||||
below.
|
||||
</para>
|
||||
|
||||
<programlisting><![CDATA[
|
||||
{ stdenv, fetchurl }:
|
||||
|
||||
stdenv.mkDerivation {
|
||||
name = "hello";
|
||||
src = fetchurl {
|
||||
url = "http://www.example.org/hello.tar.gz";
|
||||
sha256 = "1111111111111111111111111111111111111111111111111111";
|
||||
};
|
||||
}
|
||||
]]></programlisting>
|
||||
|
||||
<para>
|
||||
The main difference between <function>fetchurl</function> and
|
||||
<function>fetchzip</function> is in how they store the contents.
|
||||
<function>fetchurl</function> will store the unaltered contents of
|
||||
the URL within the Nix store. <function>fetchzip</function> on the
|
||||
other hand will decompress the archive for you, making files and
|
||||
directories directly accessible in the future.
|
||||
<function>fetchzip</function> can only be used with archives.
|
||||
Despite the name, <function>fetchzip</function> is not limited to
|
||||
.zip files and can also be used with any tarball.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<function>fetchpatch</function> works very similarly to
|
||||
<function>fetchurl</function> with the same arguments expected. It
|
||||
expects patch files as a source and and performs normalization on
|
||||
them before computing the checksum. For example it will remove
|
||||
comments or other unstable parts that are sometimes added by
|
||||
version control systems and can change over time.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Other fetcher functions allow you to add source code directly from
|
||||
a VCS such as subversion or git. These are mostly straightforward
|
||||
names based on the name of the command used with the VCS system.
|
||||
Because they give you a working repository, they act most like
|
||||
<function>fetchzip</function>.
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>fetchsvn</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Used with Subversion. Expects <literal>url</literal> to a
|
||||
Subversion directory, <literal>rev</literal>, and
|
||||
<literal>sha256</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>fetchgit</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Used with Git. Expects <literal>url</literal> to a Git repo,
|
||||
<literal>rev</literal>, and <literal>sha256</literal>.
|
||||
<literal>rev</literal> in this case can be full the git commit
|
||||
id (SHA1 hash) or a tag name like
|
||||
<literal>refs/tags/v1.0</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>fetchfossil</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Used with Fossil. Expects <literal>url</literal> to a Fossil
|
||||
archive, <literal>rev</literal>, and <literal>sha256</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>fetchcvs</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Used with CVS. Expects <literal>cvsRoot</literal>,
|
||||
<literal>tag</literal>, and <literal>sha256</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>fetchhg</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Used with Mercurial. Expects <literal>url</literal>,
|
||||
<literal>rev</literal>, and <literal>sha256</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>
|
||||
A number of fetcher functions wrap part of
|
||||
<function>fetchurl</function> and <function>fetchzip</function>.
|
||||
They are mainly convenience functions intended for commonly used
|
||||
destinations of source code in Nixpkgs. These wrapper fetchers are
|
||||
listed below.
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>fetchFromGitHub</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
<function>fetchFromGitHub</function> expects four arguments.
|
||||
<literal>owner</literal> is a string corresponding to the
|
||||
GitHub user or organization that controls this repository.
|
||||
<literal>repo</literal> corresponds to the name of the
|
||||
software repository. These are located at the top of every
|
||||
GitHub HTML page as
|
||||
<literal>owner</literal>/<literal>repo</literal>.
|
||||
<literal>rev</literal> corresponds to the Git commit hash or
|
||||
tag (e.g <literal>v1.0</literal>) that will be downloaded from
|
||||
Git. Finally, <literal>sha256</literal> corresponds to the
|
||||
hash of the extracted directory. Again, other hash algorithms
|
||||
are also available but <literal>sha256</literal> is currently
|
||||
preferred.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>fetchFromGitLab</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This is used with GitLab repositories. The arguments expected
|
||||
are very similar to fetchFromGitHub above.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>fetchFromBitbucket</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This is used with BitBucket repositories. The arguments expected
|
||||
are very similar to fetchFromGitHub above.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>fetchFromSavannah</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This is used with Savannah repositories. The arguments expected
|
||||
are very similar to fetchFromGitHub above.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>fetchFromRepoOrCz</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This is used with repo.or.cz repositories. The arguments
|
||||
expected are very similar to fetchFromGitHub above.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
</section>
|
||||
@@ -1,142 +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"
|
||||
xml:id="sec-fhs-environments">
|
||||
<title>buildFHSUserEnv</title>
|
||||
|
||||
<para>
|
||||
<function>buildFHSUserEnv</function> provides a way to build and run
|
||||
FHS-compatible lightweight sandboxes. It creates an isolated root with bound
|
||||
<filename>/nix/store</filename>, so its footprint in terms of disk space
|
||||
needed is quite small. This allows one to run software which is hard or
|
||||
unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions,
|
||||
games distributed as tarballs, software with integrity checking and/or
|
||||
external self-updated binaries. It uses Linux namespaces feature to create
|
||||
temporary lightweight environments which are destroyed after all child
|
||||
processes exit, without root user rights requirement. Accepted arguments are:
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>name</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Environment name.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>targetPkgs</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Packages to be installed for the main host's architecture (i.e. x86_64 on
|
||||
x86_64 installations). Along with libraries binaries are also installed.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>multiPkgs</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Packages to be installed for all architectures supported by a host (i.e.
|
||||
i686 and x86_64 on x86_64 installations). Only libraries are installed by
|
||||
default.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>extraBuildCommands</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Additional commands to be executed for finalizing the directory structure.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>extraBuildCommandsMulti</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Like <literal>extraBuildCommands</literal>, but executed only on multilib
|
||||
architectures.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>extraOutputsToInstall</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Additional derivation outputs to be linked for both target and
|
||||
multi-architecture packages.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>extraInstallCommands</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Additional commands to be executed for finalizing the derivation with
|
||||
runner script.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>runScript</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
A command that would be executed inside the sandbox and passed all the
|
||||
command line arguments. It defaults to <literal>bash</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>
|
||||
One can create a simple environment using a <literal>shell.nix</literal> like
|
||||
that:
|
||||
</para>
|
||||
|
||||
<programlisting><![CDATA[
|
||||
{ pkgs ? import <nixpkgs> {} }:
|
||||
|
||||
(pkgs.buildFHSUserEnv {
|
||||
name = "simple-x11-env";
|
||||
targetPkgs = pkgs: (with pkgs;
|
||||
[ udev
|
||||
alsaLib
|
||||
]) ++ (with pkgs.xorg;
|
||||
[ libX11
|
||||
libXcursor
|
||||
libXrandr
|
||||
]);
|
||||
multiPkgs = pkgs: (with pkgs;
|
||||
[ udev
|
||||
alsaLib
|
||||
]);
|
||||
runScript = "bash";
|
||||
}).env
|
||||
]]></programlisting>
|
||||
|
||||
<para>
|
||||
Running <literal>nix-shell</literal> would then drop you into a shell with
|
||||
these libraries and binaries available. You can use this to run closed-source
|
||||
applications which expect FHS structure without hassles: simply change
|
||||
<literal>runScript</literal> to the application path, e.g.
|
||||
<filename>./bin/start.sh</filename> -- relative paths are supported.
|
||||
</para>
|
||||
</section>
|
||||
@@ -1,89 +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"
|
||||
xml:id="sec-generators">
|
||||
<title>Generators</title>
|
||||
|
||||
<para>
|
||||
Generators are functions that create file formats from nix data structures,
|
||||
e. g. for configuration files. There are generators available for:
|
||||
<literal>INI</literal>, <literal>JSON</literal> and <literal>YAML</literal>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
All generators follow a similar call interface: <code>generatorName
|
||||
configFunctions data</code>, where <literal>configFunctions</literal> is an
|
||||
attrset of user-defined functions that format nested parts of the content.
|
||||
They each have common defaults, so often they do not need to be set manually.
|
||||
An example is <code>mkSectionName ? (name: libStr.escape [ "[" "]" ]
|
||||
name)</code> from the <literal>INI</literal> generator. It receives the name
|
||||
of a section and sanitizes it. The default <literal>mkSectionName</literal>
|
||||
escapes <literal>[</literal> and <literal>]</literal> with a backslash.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Generators can be fine-tuned to produce exactly the file format required by
|
||||
your application/service. One example is an INI-file format which uses
|
||||
<literal>: </literal> as separator, the strings
|
||||
<literal>"yes"</literal>/<literal>"no"</literal> as boolean values and
|
||||
requires all string values to be quoted:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
with lib;
|
||||
let
|
||||
customToINI = generators.toINI {
|
||||
# specifies how to format a key/value pair
|
||||
mkKeyValue = generators.mkKeyValueDefault {
|
||||
# specifies the generated string for a subset of nix values
|
||||
mkValueString = v:
|
||||
if v == true then ''"yes"''
|
||||
else if v == false then ''"no"''
|
||||
else if isString v then ''"${v}"''
|
||||
# and delegats all other values to the default generator
|
||||
else generators.mkValueStringDefault {} v;
|
||||
} ":";
|
||||
};
|
||||
|
||||
# the INI file can now be given as plain old nix values
|
||||
in customToINI {
|
||||
main = {
|
||||
pushinfo = true;
|
||||
autopush = false;
|
||||
host = "localhost";
|
||||
port = 42;
|
||||
};
|
||||
mergetool = {
|
||||
merge = "diff3";
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
This will produce the following INI file as nix string:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
[main]
|
||||
autopush:"no"
|
||||
host:"localhost"
|
||||
port:42
|
||||
pushinfo:"yes"
|
||||
str\:ange:"very::strange"
|
||||
|
||||
[mergetool]
|
||||
merge:"diff3"
|
||||
</programlisting>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Nix store paths can be converted to strings by enclosing a derivation
|
||||
attribute like so: <code>"${drv}"</code>.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
Detailed documentation for each generator can be found in
|
||||
<literal>lib/generators.nix</literal>.
|
||||
</para>
|
||||
</section>
|
||||
@@ -1,24 +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"
|
||||
xml:id="sec-functions-library">
|
||||
<title>Nixpkgs Library Functions</title>
|
||||
|
||||
<para>
|
||||
Nixpkgs provides a standard library at <varname>pkgs.lib</varname>, or
|
||||
through <code>import <nixpkgs/lib></code>.
|
||||
</para>
|
||||
|
||||
<xi:include href="./library/asserts.xml" />
|
||||
|
||||
<xi:include href="./library/attrsets.xml" />
|
||||
|
||||
<!-- These docs are generated via nixdoc. To add another generated
|
||||
library function file to this list, the file
|
||||
`lib-function-docs.nix` must also be updated. -->
|
||||
<xi:include href="./library/generated/strings.xml" />
|
||||
<xi:include href="./library/generated/trivial.xml" />
|
||||
<xi:include href="./library/generated/lists.xml" />
|
||||
<xi:include href="./library/generated/debug.xml" />
|
||||
<xi:include href="./library/generated/options.xml" />
|
||||
</section>
|
||||
@@ -1,117 +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"
|
||||
xml:id="sec-functions-library-asserts">
|
||||
<title>Assert functions</title>
|
||||
|
||||
<section xml:id="function-library-lib.asserts.assertMsg">
|
||||
<title><function>lib.asserts.assertMsg</function></title>
|
||||
|
||||
<subtitle><literal>assertMsg :: Bool -> String -> Bool</literal>
|
||||
</subtitle>
|
||||
|
||||
<xi:include href="./locations.xml" xpointer="lib.asserts.assertMsg" />
|
||||
|
||||
<para>
|
||||
Print a trace message if <literal>pred</literal> is false.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Intended to be used to augment asserts with helpful error messages.
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>pred</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Condition under which the <varname>msg</varname> should
|
||||
<emphasis>not</emphasis> be printed.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>msg</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Message to print.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<example xml:id="function-library-lib.asserts.assertMsg-example-false">
|
||||
<title>Printing when the predicate is false</title>
|
||||
<programlisting><![CDATA[
|
||||
assert lib.asserts.assertMsg ("foo" == "bar") "foo is not bar, silly"
|
||||
stderr> trace: foo is not bar, silly
|
||||
stderr> assert failed
|
||||
]]></programlisting>
|
||||
</example>
|
||||
</section>
|
||||
|
||||
<section xml:id="function-library-lib.asserts.assertOneOf">
|
||||
<title><function>lib.asserts.assertOneOf</function></title>
|
||||
|
||||
<subtitle><literal>assertOneOf :: String -> String ->
|
||||
StringList -> Bool</literal>
|
||||
</subtitle>
|
||||
|
||||
<xi:include href="./locations.xml" xpointer="lib.asserts.assertOneOf" />
|
||||
|
||||
<para>
|
||||
Specialized <function>asserts.assertMsg</function> for checking if
|
||||
<varname>val</varname> is one of the elements of <varname>xs</varname>.
|
||||
Useful for checking enums.
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>name</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The name of the variable the user entered <varname>val</varname> into,
|
||||
for inclusion in the error message.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>val</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The value of what the user provided, to be compared against the values in
|
||||
<varname>xs</varname>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>xs</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The list of valid values.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<example xml:id="function-library-lib.asserts.assertOneOf-example">
|
||||
<title>Ensuring a user provided a possible value</title>
|
||||
<programlisting><![CDATA[
|
||||
let sslLibrary = "bearssl";
|
||||
in lib.asserts.assertOneOf "sslLibrary" sslLibrary [ "openssl" "bearssl" ];
|
||||
=> false
|
||||
stderr> trace: sslLibrary must be one of "openssl", "libressl", but is: "bearssl"
|
||||
]]></programlisting>
|
||||
</example>
|
||||
</section>
|
||||
</section>
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,78 +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"
|
||||
xml:id="sec-pkgs-nix-gitignore">
|
||||
<title>pkgs.nix-gitignore</title>
|
||||
|
||||
<para>
|
||||
<function>pkgs.nix-gitignore</function> is a function that acts similarly to
|
||||
<literal>builtins.filterSource</literal> but also allows filtering with the
|
||||
help of the gitignore format.
|
||||
</para>
|
||||
|
||||
<section xml:id="sec-pkgs-nix-gitignore-usage">
|
||||
<title>Usage</title>
|
||||
|
||||
<para>
|
||||
<literal>pkgs.nix-gitignore</literal> exports a number of functions, but
|
||||
you'll most likely need either <literal>gitignoreSource</literal> or
|
||||
<literal>gitignoreSourcePure</literal>. As their first argument, they both
|
||||
accept either 1. a file with gitignore lines or 2. a string
|
||||
with gitignore lines, or 3. a list of either of the two. They will be
|
||||
concatenated into a single big string.
|
||||
</para>
|
||||
|
||||
<programlisting><![CDATA[
|
||||
{ pkgs ? import <nixpkgs> {} }:
|
||||
|
||||
nix-gitignore.gitignoreSource [] ./source
|
||||
# Simplest version
|
||||
|
||||
nix-gitignore.gitignoreSource "supplemental-ignores\n" ./source
|
||||
# This one reads the ./source/.gitignore and concats the auxiliary ignores
|
||||
|
||||
nix-gitignore.gitignoreSourcePure "ignore-this\nignore-that\n" ./source
|
||||
# Use this string as gitignore, don't read ./source/.gitignore.
|
||||
|
||||
nix-gitignore.gitignoreSourcePure ["ignore-this\nignore-that\n", ~/.gitignore] ./source
|
||||
# It also accepts a list (of strings and paths) that will be concatenated
|
||||
# once the paths are turned to strings via readFile.
|
||||
]]></programlisting>
|
||||
|
||||
<para>
|
||||
These functions are derived from the <literal>Filter</literal> functions
|
||||
by setting the first filter argument to <literal>(_: _: true)</literal>:
|
||||
</para>
|
||||
|
||||
<programlisting><![CDATA[
|
||||
gitignoreSourcePure = gitignoreFilterSourcePure (_: _: true);
|
||||
gitignoreSource = gitignoreFilterSource (_: _: true);
|
||||
]]></programlisting>
|
||||
|
||||
<para>
|
||||
Those filter functions accept the same arguments the <literal>builtins.filterSource</literal> function would pass to its filters, thus <literal>fn: gitignoreFilterSourcePure fn ""</literal> should be extensionally equivalent to <literal>filterSource</literal>. The file is blacklisted iff it's blacklisted by either your filter or the gitignoreFilter.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you want to make your own filter from scratch, you may use
|
||||
</para>
|
||||
|
||||
<programlisting><![CDATA[
|
||||
gitignoreFilter = ign: root: filterPattern (gitignoreToPatterns ign) root;
|
||||
]]></programlisting>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-pkgs-nix-gitignore-usage-recursive">
|
||||
<title>gitignore files in subdirectories</title>
|
||||
|
||||
<para>
|
||||
If you wish to use a filter that would search for .gitignore files in subdirectories, just like git does by default, use this function:
|
||||
</para>
|
||||
|
||||
<programlisting><![CDATA[
|
||||
gitignoreFilterRecursiveSource = filter: patterns: root:
|
||||
# OR
|
||||
gitignoreRecursiveSource = gitignoreFilterSourcePure (_: _: true);
|
||||
]]></programlisting>
|
||||
</section>
|
||||
</section>
|
||||
@@ -1,212 +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"
|
||||
xml:id="sec-overrides">
|
||||
<title>Overriding</title>
|
||||
|
||||
<para>
|
||||
Sometimes one wants to override parts of <literal>nixpkgs</literal>, e.g.
|
||||
derivation attributes, the results of derivations.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
These functions are used to make changes to packages, returning only single
|
||||
packages. <link xlink:href="#chap-overlays">Overlays</link>, on the other
|
||||
hand, can be used to combine the overridden packages across the entire
|
||||
package set of Nixpkgs.
|
||||
</para>
|
||||
|
||||
<section xml:id="sec-pkg-override">
|
||||
<title><pkg>.override</title>
|
||||
|
||||
<para>
|
||||
The function <varname>override</varname> is usually available for all the
|
||||
derivations in the nixpkgs expression (<varname>pkgs</varname>).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It is used to override the arguments passed to a function.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Example usages:
|
||||
<programlisting>pkgs.foo.override { arg1 = val1; arg2 = val2; ... }</programlisting>
|
||||
<!-- TODO: move below programlisting to a new section about extending and overlays
|
||||
and reference it
|
||||
-->
|
||||
<programlisting>
|
||||
import pkgs.path { overlays = [ (self: super: {
|
||||
foo = super.foo.override { barSupport = true ; };
|
||||
})]};
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
mypkg = pkgs.callPackage ./mypkg.nix {
|
||||
mydep = pkgs.mydep.override { ... };
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the first example, <varname>pkgs.foo</varname> is the result of a
|
||||
function call with some default arguments, usually a derivation. Using
|
||||
<varname>pkgs.foo.override</varname> will call the same function with the
|
||||
given new arguments.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-pkg-overrideAttrs">
|
||||
<title><pkg>.overrideAttrs</title>
|
||||
|
||||
<para>
|
||||
The function <varname>overrideAttrs</varname> allows overriding the
|
||||
attribute set passed to a <varname>stdenv.mkDerivation</varname> call,
|
||||
producing a new derivation based on the original one. This function is
|
||||
available on all derivations produced by the
|
||||
<varname>stdenv.mkDerivation</varname> function, which is most packages in
|
||||
the nixpkgs expression <varname>pkgs</varname>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Example usage:
|
||||
<programlisting>
|
||||
helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
|
||||
separateDebugInfo = true;
|
||||
});
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the above example, the <varname>separateDebugInfo</varname> attribute is
|
||||
overridden to be true, thus building debug info for
|
||||
<varname>helloWithDebug</varname>, while all other attributes will be
|
||||
retained from the original <varname>hello</varname> package.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The argument <varname>oldAttrs</varname> is conventionally used to refer to
|
||||
the attr set originally passed to <varname>stdenv.mkDerivation</varname>.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Note that <varname>separateDebugInfo</varname> is processed only by the
|
||||
<varname>stdenv.mkDerivation</varname> function, not the generated, raw Nix
|
||||
derivation. Thus, using <varname>overrideDerivation</varname> will not work
|
||||
in this case, as it overrides only the attributes of the final derivation.
|
||||
It is for this reason that <varname>overrideAttrs</varname> should be
|
||||
preferred in (almost) all cases to <varname>overrideDerivation</varname>,
|
||||
i.e. to allow using <varname>stdenv.mkDerivation</varname> to process input
|
||||
arguments, as well as the fact that it is easier to use (you can use the
|
||||
same attribute names you see in your Nix code, instead of the ones
|
||||
generated (e.g. <varname>buildInputs</varname> vs
|
||||
<varname>nativeBuildInputs</varname>), and it involves less typing).
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-pkg-overrideDerivation">
|
||||
<title><pkg>.overrideDerivation</title>
|
||||
|
||||
<warning>
|
||||
<para>
|
||||
You should prefer <varname>overrideAttrs</varname> in almost all cases, see
|
||||
its documentation for the reasons why.
|
||||
<varname>overrideDerivation</varname> is not deprecated and will continue
|
||||
to work, but is less nice to use and does not have as many abilities as
|
||||
<varname>overrideAttrs</varname>.
|
||||
</para>
|
||||
</warning>
|
||||
|
||||
<warning>
|
||||
<para>
|
||||
Do not use this function in Nixpkgs as it evaluates a Derivation before
|
||||
modifying it, which breaks package abstraction and removes error-checking
|
||||
of function arguments. In addition, this evaluation-per-function
|
||||
application incurs a performance penalty, which can become a problem if
|
||||
many overrides are used. It is only intended for ad-hoc customisation, such
|
||||
as in <filename>~/.config/nixpkgs/config.nix</filename>.
|
||||
</para>
|
||||
</warning>
|
||||
|
||||
<para>
|
||||
The function <varname>overrideDerivation</varname> creates a new derivation
|
||||
based on an existing one by overriding the original's attributes with the
|
||||
attribute set produced by the specified function. This function is available
|
||||
on all derivations defined using the <varname>makeOverridable</varname>
|
||||
function. Most standard derivation-producing functions, such as
|
||||
<varname>stdenv.mkDerivation</varname>, are defined using this function,
|
||||
which means most packages in the nixpkgs expression,
|
||||
<varname>pkgs</varname>, have this function.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Example usage:
|
||||
<programlisting>
|
||||
mySed = pkgs.gnused.overrideDerivation (oldAttrs: {
|
||||
name = "sed-4.2.2-pre";
|
||||
src = fetchurl {
|
||||
url = ftp://alpha.gnu.org/gnu/sed/sed-4.2.2-pre.tar.bz2;
|
||||
sha256 = "11nq06d131y4wmf3drm0yk502d2xc6n5qy82cg88rb9nqd2lj41k";
|
||||
};
|
||||
patches = [];
|
||||
});
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the above example, the <varname>name</varname>, <varname>src</varname>,
|
||||
and <varname>patches</varname> of the derivation will be overridden, while
|
||||
all other attributes will be retained from the original derivation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The argument <varname>oldAttrs</varname> is used to refer to the attribute
|
||||
set of the original derivation.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
A package's attributes are evaluated *before* being modified by the
|
||||
<varname>overrideDerivation</varname> function. For example, the
|
||||
<varname>name</varname> attribute reference in <varname>url =
|
||||
"mirror://gnu/hello/${name}.tar.gz";</varname> is filled-in *before* the
|
||||
<varname>overrideDerivation</varname> function modifies the attribute set.
|
||||
This means that overriding the <varname>name</varname> attribute, in this
|
||||
example, *will not* change the value of the <varname>url</varname>
|
||||
attribute. Instead, we need to override both the <varname>name</varname>
|
||||
*and* <varname>url</varname> attributes.
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-lib-makeOverridable">
|
||||
<title>lib.makeOverridable</title>
|
||||
|
||||
<para>
|
||||
The function <varname>lib.makeOverridable</varname> is used to make the
|
||||
result of a function easily customizable. This utility only makes sense for
|
||||
functions that accept an argument set and return an attribute set.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Example usage:
|
||||
<programlisting>
|
||||
f = { a, b }: { result = a+b; };
|
||||
c = lib.makeOverridable f { a = 1; b = 2; };
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The variable <varname>c</varname> is the value of the <varname>f</varname>
|
||||
function applied with some default arguments. Hence the value of
|
||||
<varname>c.result</varname> is <literal>3</literal>, in this example.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The variable <varname>c</varname> however also has some additional
|
||||
functions, like <link linkend="sec-pkg-override">c.override</link> which can
|
||||
be used to override the default arguments. In this example the value of
|
||||
<varname>(c.override { a = 4; }).result</varname> is 6.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
@@ -1,27 +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"
|
||||
xml:id="sec-prefer-remote-fetch">
|
||||
<title>prefer-remote-fetch overlay</title>
|
||||
|
||||
<para>
|
||||
<function>prefer-remote-fetch</function> is an overlay that download sources
|
||||
on remote builder. This is useful when the evaluating machine has a slow
|
||||
upload while the builder can fetch faster directly from the source.
|
||||
To use it, put the following snippet as a new overlay:
|
||||
<programlisting>
|
||||
self: super:
|
||||
(super.prefer-remote-fetch self super)
|
||||
</programlisting>
|
||||
|
||||
A full configuration example for that sets the overlay up for your own account,
|
||||
could look like this
|
||||
|
||||
<programlisting>
|
||||
$ mkdir ~/.config/nixpkgs/overlays/
|
||||
$ cat > ~/.config/nixpkgs/overlays/prefer-remote-fetch.nix <<EOF
|
||||
self: super: super.prefer-remote-fetch self super
|
||||
EOF
|
||||
</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
@@ -1,26 +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"
|
||||
xml:id="sec-pkgs-mkShell">
|
||||
<title>pkgs.mkShell</title>
|
||||
|
||||
<para>
|
||||
<function>pkgs.mkShell</function> is a special kind of derivation that is
|
||||
only useful when using it combined with <command>nix-shell</command>. It will
|
||||
in fact fail to instantiate when invoked with <command>nix-build</command>.
|
||||
</para>
|
||||
|
||||
<section xml:id="sec-pkgs-mkShell-usage">
|
||||
<title>Usage</title>
|
||||
|
||||
<programlisting><![CDATA[
|
||||
{ pkgs ? import <nixpkgs> {} }:
|
||||
pkgs.mkShell {
|
||||
# this will make all the build inputs from hello and gnutar
|
||||
# available to the shell environment
|
||||
inputsFrom = with pkgs; [ hello gnutar ];
|
||||
buildInputs = [ pkgs.gnumake ];
|
||||
}
|
||||
]]></programlisting>
|
||||
</section>
|
||||
</section>
|
||||
@@ -1,124 +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"
|
||||
xml:id="sec-trivial-builders">
|
||||
<title>Trivial builders</title>
|
||||
|
||||
<para>
|
||||
Nixpkgs provides a couple of functions that help with building
|
||||
derivations. The most important one,
|
||||
<function>stdenv.mkDerivation</function>, has already been
|
||||
documented above. The following functions wrap
|
||||
<function>stdenv.mkDerivation</function>, making it easier to use
|
||||
in certain cases.
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>runCommand</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This takes three arguments, <literal>name</literal>,
|
||||
<literal>env</literal>, and <literal>buildCommand</literal>.
|
||||
<literal>name</literal> is just the name that Nix will append
|
||||
to the store path in the same way that
|
||||
<literal>stdenv.mkDerivation</literal> uses its
|
||||
<literal>name</literal> attribute. <literal>env</literal> is an
|
||||
attribute set specifying environment variables that will be set
|
||||
for this derivation. These attributes are then passed to the
|
||||
wrapped <literal>stdenv.mkDerivation</literal>.
|
||||
<literal>buildCommand</literal> specifies the commands that
|
||||
will be run to create this derivation. Note that you will need
|
||||
to create <literal>$out</literal> for Nix to register the
|
||||
command as successful.
|
||||
</para>
|
||||
<para>
|
||||
An example of using <literal>runCommand</literal> is provided
|
||||
below.
|
||||
</para>
|
||||
<programlisting>
|
||||
(import <nixpkgs> {}).runCommand "my-example" {} ''
|
||||
echo My example command is running
|
||||
|
||||
mkdir $out
|
||||
|
||||
echo I can write data to the Nix store > $out/message
|
||||
|
||||
echo I can also run basic commands like:
|
||||
|
||||
echo ls
|
||||
ls
|
||||
|
||||
echo whoami
|
||||
whoami
|
||||
|
||||
echo date
|
||||
date
|
||||
''
|
||||
</programlisting>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>runCommandCC</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This works just like <literal>runCommand</literal>. The only
|
||||
difference is that it also provides a C compiler in
|
||||
<literal>buildCommand</literal>’s environment. To minimize your
|
||||
dependencies, you should only use this if you are sure you will
|
||||
need a C compiler as part of running your command.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>writeTextFile</literal>, <literal>writeText</literal>,
|
||||
<literal>writeTextDir</literal>, <literal>writeScript</literal>,
|
||||
<literal>writeScriptBin</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
These functions write <literal>text</literal> to the Nix store.
|
||||
This is useful for creating scripts from Nix expressions.
|
||||
<literal>writeTextFile</literal> takes an attribute set and
|
||||
expects two arguments, <literal>name</literal> and
|
||||
<literal>text</literal>. <literal>name</literal> corresponds to
|
||||
the name used in the Nix store path. <literal>text</literal>
|
||||
will be the contents of the file. You can also set
|
||||
<literal>executable</literal> to true to make this file have
|
||||
the executable bit set.
|
||||
</para>
|
||||
<para>
|
||||
Many more commands wrap <literal>writeTextFile</literal>
|
||||
including <literal>writeText</literal>,
|
||||
<literal>writeTextDir</literal>,
|
||||
<literal>writeScript</literal>, and
|
||||
<literal>writeScriptBin</literal>. These are convenience
|
||||
functions over <literal>writeTextFile</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>symlinkJoin</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This can be used to put many derivations into the same directory
|
||||
structure. It works by creating a new derivation and adding
|
||||
symlinks to each of the paths listed. It expects two arguments,
|
||||
<literal>name</literal>, and <literal>paths</literal>.
|
||||
<literal>name</literal> is the name used in the Nix store path
|
||||
for the created derivation. <literal>paths</literal> is a list of
|
||||
paths that will be symlinked. These paths can be to Nix store
|
||||
derivations or any other subdirectory contained within.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
</section>
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
title: Introduction
|
||||
author: Frederik Rietdijk
|
||||
date: 2015-11-25
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
The Nix Packages collection (Nixpkgs) is a set of thousands of packages for the
|
||||
[Nix package manager](http://nixos.org/nix/), released under a
|
||||
[permissive MIT/X11 license](https://github.com/NixOS/nixpkgs/blob/master/COPYING).
|
||||
Packages are available for several platforms, and can be used with the Nix
|
||||
package manager on most GNU/Linux distributions as well as NixOS.
|
||||
|
||||
This manual primarily describes how to write packages for the Nix Packages collection
|
||||
(Nixpkgs). Thus it’s mainly for packagers and developers who want to add packages to
|
||||
Nixpkgs. If you like to learn more about the Nix package manager and the Nix
|
||||
expression language, then you are kindly referred to the [Nix manual](http://nixos.org/nix/manual/).
|
||||
|
||||
## Overview of Nixpkgs
|
||||
|
||||
Nix expressions describe how to build packages from source and are collected in
|
||||
the [nixpkgs repository](https://github.com/NixOS/nixpkgs). Also included in the
|
||||
collection are Nix expressions for
|
||||
[NixOS modules](http://nixos.org/nixos/manual/index.html#sec-writing-modules).
|
||||
With these expressions the Nix package manager can build binary packages.
|
||||
|
||||
Packages, including the Nix packages collection, are distributed through
|
||||
[channels](http://nixos.org/nix/manual/#sec-channels). The collection is
|
||||
distributed for users of Nix on non-NixOS distributions through the channel
|
||||
`nixpkgs`. Users of NixOS generally use one of the `nixos-*` channels, e.g.
|
||||
`nixos-16.03`, which includes all packages and modules for the stable NixOS
|
||||
16.03. Stable NixOS releases are generally only given
|
||||
security updates. More up to date packages and modules are available via the
|
||||
`nixos-unstable` channel.
|
||||
|
||||
Both `nixos-unstable` and `nixpkgs` follow the `master` branch of the Nixpkgs
|
||||
repository, although both do lag the `master` branch by generally
|
||||
[a couple of days](http://howoldis.herokuapp.com/). Updates to a channel are
|
||||
distributed as soon as all tests for that channel pass, e.g.
|
||||
[this table](http://hydra.nixos.org/job/nixpkgs/trunk/unstable#tabs-constituents)
|
||||
shows the status of tests for the `nixpkgs` channel.
|
||||
|
||||
The tests are conducted by a cluster called [Hydra](http://nixos.org/hydra/),
|
||||
which also builds binary packages from the Nix expressions in Nixpkgs for
|
||||
`x86_64-linux`, `i686-linux` and `x86_64-darwin`.
|
||||
The binaries are made available via a [binary cache](https://cache.nixos.org).
|
||||
|
||||
The current Nix expressions of the channels are available in the
|
||||
[`nixpkgs-channels`](https://github.com/NixOS/nixpkgs-channels) repository,
|
||||
which has branches corresponding to the available channels.
|
||||
@@ -1,240 +0,0 @@
|
||||
---
|
||||
title: Android
|
||||
author: Sander van der Burg
|
||||
date: 2018-11-18
|
||||
---
|
||||
# Android
|
||||
|
||||
The Android build environment provides three major features and a number of
|
||||
supporting features.
|
||||
|
||||
Deploying an Android SDK installation with plugins
|
||||
--------------------------------------------------
|
||||
The first use case is deploying the SDK with a desired set of plugins or subsets
|
||||
of an SDK.
|
||||
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
|
||||
let
|
||||
androidComposition = androidenv.composeAndroidPackages {
|
||||
toolsVersion = "25.2.5";
|
||||
platformToolsVersion = "27.0.1";
|
||||
buildToolsVersions = [ "27.0.3" ];
|
||||
includeEmulator = false;
|
||||
emulatorVersion = "27.2.0";
|
||||
platformVersions = [ "24" ];
|
||||
includeSources = false;
|
||||
includeDocs = false;
|
||||
includeSystemImages = false;
|
||||
systemImageTypes = [ "default" ];
|
||||
abiVersions = [ "armeabi-v7a" ];
|
||||
lldbVersions = [ "2.0.2558144" ];
|
||||
cmakeVersions = [ "3.6.4111459" ];
|
||||
includeNDK = false;
|
||||
ndkVersion = "16.1.4479499";
|
||||
useGoogleAPIs = false;
|
||||
useGoogleTVAddOns = false;
|
||||
includeExtras = [
|
||||
"extras;google;gcm"
|
||||
];
|
||||
};
|
||||
in
|
||||
androidComposition.androidsdk
|
||||
```
|
||||
|
||||
The above function invocation states that we want an Android SDK with the above
|
||||
specified plugin versions. By default, most plugins are disabled. Notable
|
||||
exceptions are the tools, platform-tools and build-tools sub packages.
|
||||
|
||||
The following parameters are supported:
|
||||
|
||||
* `toolsVersion`, specifies the version of the tools package to use
|
||||
* `platformsToolsVersion` specifies the version of the `platform-tools` plugin
|
||||
* `buildToolsVersion` specifies the versions of the `build-tools` plugins to
|
||||
use.
|
||||
* `includeEmulator` specifies whether to deploy the emulator package (`false`
|
||||
by default). When enabled, the version of the emulator to deploy can be
|
||||
specified by setting the `emulatorVersion` parameter.
|
||||
* `includeDocs` specifies whether the documentation catalog should be included.
|
||||
* `lldbVersions` specifies what LLDB versions should be deployed.
|
||||
* `cmakeVersions` specifies which CMake versions should be deployed.
|
||||
* `includeNDK` specifies that the Android NDK bundle should be included.
|
||||
Defaults to: `false`.
|
||||
* `ndkVersion` specifies the NDK version that we want to use.
|
||||
* `includeExtras` is an array of identifier strings referring to arbitrary
|
||||
add-on packages that should be installed.
|
||||
* `platformVersions` specifies which platform SDK versions should be included.
|
||||
|
||||
For each platform version that has been specified, we can apply the following
|
||||
options:
|
||||
|
||||
* `includeSystemImages` specifies whether a system image for each platform SDK
|
||||
should be included.
|
||||
* `includeSources` specifies whether the sources for each SDK version should be
|
||||
included.
|
||||
* `useGoogleAPIs` specifies that for each selected platform version the
|
||||
Google API should be included.
|
||||
* `useGoogleTVAddOns` specifies that for each selected platform version the
|
||||
Google TV add-on should be included.
|
||||
|
||||
For each requested system image we can specify the following options:
|
||||
|
||||
* `systemImageTypes` specifies what kind of system images should be included.
|
||||
Defaults to: `default`.
|
||||
* `abiVersions` specifies what kind of ABI version of each system image should
|
||||
be included. Defaults to: `armeabi-v7a`.
|
||||
|
||||
Most of the function arguments have reasonable default settings.
|
||||
|
||||
When building the above expression with:
|
||||
|
||||
```bash
|
||||
$ nix-build
|
||||
```
|
||||
|
||||
The Android SDK gets deployed with all desired plugin versions.
|
||||
|
||||
We can also deploy subsets of the Android SDK. For example, to only the the
|
||||
`platform-tools` package, you can evaluate the following expression:
|
||||
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
|
||||
let
|
||||
androidComposition = androidenv.composeAndroidPackages {
|
||||
# ...
|
||||
};
|
||||
in
|
||||
androidComposition.platform-tools
|
||||
```
|
||||
|
||||
Using predefine Android package compositions
|
||||
--------------------------------------------
|
||||
In addition to composing an Android package set manually, it is also possible
|
||||
to use a predefined composition that contains all basic packages for a specific
|
||||
Android version, such as version 9.0 (API-level 28).
|
||||
|
||||
The following Nix expression can be used to deploy the entire SDK with all basic
|
||||
plugins:
|
||||
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
|
||||
androidenv.androidPkgs_9_0.androidsdk
|
||||
```
|
||||
|
||||
It is also possible to use one plugin only:
|
||||
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
|
||||
androidenv.androidPkgs_9_0.platform-tools
|
||||
```
|
||||
|
||||
Building an Android application
|
||||
-------------------------------
|
||||
In addition to the SDK, it is also possible to build an Ant-based Android
|
||||
project and automatically deploy all the Android plugins that a project
|
||||
requires.
|
||||
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
|
||||
androidenv.buildApp {
|
||||
name = "MyAndroidApp";
|
||||
src = ./myappsources;
|
||||
release = true;
|
||||
|
||||
# If release is set to true, you need to specify the following parameters
|
||||
keyStore = ./keystore;
|
||||
keyAlias = "myfirstapp";
|
||||
keyStorePassword = "mykeystore";
|
||||
keyAliasPassword = "myfirstapp";
|
||||
|
||||
# Any Android SDK parameters that install all the relevant plugins that a
|
||||
# build requires
|
||||
platformVersions = [ "24" ];
|
||||
|
||||
# When we include the NDK, then ndk-build is invoked before Ant gets invoked
|
||||
includeNDK = true;
|
||||
}
|
||||
```
|
||||
|
||||
Aside from the app-specific build parameters (`name`, `src`, `release` and
|
||||
keystore parameters), the `buildApp {}` function supports all the function
|
||||
parameters that the SDK composition function (the function shown in the
|
||||
previous section) supports.
|
||||
|
||||
This build function is particularly useful when it is desired to use
|
||||
[Hydra](http://nixos.org/hydra): the Nix-based continuous integration solution
|
||||
to build Android apps. An Android APK gets exposed as a build product and can be
|
||||
installed on any Android device with a web browser by navigating to the build
|
||||
result page.
|
||||
|
||||
Spawning emulator instances
|
||||
---------------------------
|
||||
For testing purposes, it can also be quite convenient to automatically generate
|
||||
scripts that spawn emulator instances with all desired configuration settings.
|
||||
|
||||
An emulator spawn script can be configured by invoking the `emulateApp {}`
|
||||
function:
|
||||
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
|
||||
androidenv.emulateApp {
|
||||
name = "emulate-MyAndroidApp";
|
||||
platformVersion = "24";
|
||||
abiVersion = "armeabi-v7a"; # mips, x86 or x86_64
|
||||
systemImageType = "default";
|
||||
useGoogleAPIs = false;
|
||||
}
|
||||
```
|
||||
|
||||
It is also possible to specify an APK to deploy inside the emulator
|
||||
and the package and activity names to launch it:
|
||||
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
|
||||
androidenv.emulateApp {
|
||||
name = "emulate-MyAndroidApp";
|
||||
platformVersion = "24";
|
||||
abiVersion = "armeabi-v7a"; # mips, x86 or x86_64
|
||||
systemImageType = "default";
|
||||
useGoogleAPIs = false;
|
||||
app = ./MyApp.apk;
|
||||
package = "MyApp";
|
||||
activity = "MainActivity";
|
||||
}
|
||||
```
|
||||
|
||||
In addition to prebuilt APKs, you can also bind the APK parameter to a
|
||||
`buildApp {}` function invocation shown in the previous example.
|
||||
|
||||
Querying the available versions of each plugin
|
||||
----------------------------------------------
|
||||
When using any of the previously shown functions, it may be a bit inconvenient
|
||||
to find out what options are supported, since the Android SDK provides many
|
||||
plugins.
|
||||
|
||||
A shell script in the `pkgs/development/mobile/androidenv/` sub directory can be used to retrieve all
|
||||
possible options:
|
||||
|
||||
```bash
|
||||
sh ./querypackages.sh packages build-tools
|
||||
```
|
||||
|
||||
The above command-line instruction queries all build-tools versions in the
|
||||
generated `packages.nix` expression.
|
||||
|
||||
Updating the generated expressions
|
||||
----------------------------------
|
||||
Most of the Nix expressions are generated from XML files that the Android
|
||||
package manager uses. To update the expressions run the `generate.sh` script
|
||||
that is stored in the `pkgs/development/mobile/androidenv/` sub directory:
|
||||
|
||||
```bash
|
||||
sh ./generate.sh
|
||||
```
|
||||
@@ -1,528 +0,0 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="sec-beam">
|
||||
<title>BEAM Languages (Erlang, Elixir & LFE)</title>
|
||||
|
||||
<section xml:id="beam-introduction">
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>
|
||||
In this document and related Nix expressions, we use the term,
|
||||
<emphasis>BEAM</emphasis>, to describe the environment. BEAM is the name of
|
||||
the Erlang Virtual Machine and, as far as we're concerned, from a packaging
|
||||
perspective, all languages that run on the BEAM are interchangeable. That
|
||||
which varies, like the build system, is transparent to users of any given
|
||||
BEAM package, so we make no distinction.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="beam-structure">
|
||||
<title>Structure</title>
|
||||
|
||||
<para>
|
||||
All BEAM-related expressions are available via the top-level
|
||||
<literal>beam</literal> attribute, which includes:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>interpreters</literal>: a set of compilers running on the BEAM,
|
||||
including multiple Erlang/OTP versions
|
||||
(<literal>beam.interpreters.erlangR19</literal>, etc), Elixir
|
||||
(<literal>beam.interpreters.elixir</literal>) and LFE
|
||||
(<literal>beam.interpreters.lfe</literal>).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>packages</literal>: a set of package sets, each compiled with a
|
||||
specific Erlang/OTP version, e.g.
|
||||
<literal>beam.packages.erlangR19</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
The default Erlang compiler, defined by
|
||||
<literal>beam.interpreters.erlang</literal>, is aliased as
|
||||
<literal>erlang</literal>. The default BEAM package set is defined by
|
||||
<literal>beam.packages.erlang</literal> and aliased at the top level as
|
||||
<literal>beamPackages</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To create a package set built with a custom Erlang version, use the lambda,
|
||||
<literal>beam.packagesWith</literal>, which accepts an Erlang/OTP derivation
|
||||
and produces a package set similar to
|
||||
<literal>beam.packages.erlang</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Many Erlang/OTP distributions available in
|
||||
<literal>beam.interpreters</literal> have versions with ODBC and/or Java
|
||||
enabled. For example, there's
|
||||
<literal>beam.interpreters.erlangR19_odbc_javac</literal>, which corresponds
|
||||
to <literal>beam.interpreters.erlangR19</literal>.
|
||||
</para>
|
||||
|
||||
<para xml:id="erlang-call-package">
|
||||
We also provide the lambda,
|
||||
<literal>beam.packages.erlang.callPackage</literal>, which simplifies
|
||||
writing BEAM package definitions by injecting all packages from
|
||||
<literal>beam.packages.erlang</literal> into the top-level context.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="build-tools">
|
||||
<title>Build Tools</title>
|
||||
|
||||
<section xml:id="build-tools-rebar3">
|
||||
<title>Rebar3</title>
|
||||
|
||||
<para>
|
||||
By default, Rebar3 wants to manage its own dependencies. This is perfectly
|
||||
acceptable in the normal, non-Nix setup, but in the Nix world, it is not.
|
||||
To rectify this, we provide two versions of Rebar3:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>rebar3</literal>: patched to remove the ability to download
|
||||
anything. When not running it via <literal>nix-shell</literal> or
|
||||
<literal>nix-build</literal>, it's probably not going to work as
|
||||
desired.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>rebar3-open</literal>: the normal, unmodified Rebar3. It should
|
||||
work exactly as would any other version of Rebar3. Any Erlang package
|
||||
should rely on <literal>rebar3</literal> instead. See
|
||||
<xref
|
||||
linkend="rebar3-packages"/>.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="build-tools-other">
|
||||
<title>Mix & Erlang.mk</title>
|
||||
|
||||
<para>
|
||||
Both Mix and Erlang.mk work exactly as expected. There is a bootstrap
|
||||
process that needs to be run for both, however, which is supported by the
|
||||
<literal>buildMix</literal> and <literal>buildErlangMk</literal>
|
||||
derivations, respectively.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section xml:id="how-to-install-beam-packages">
|
||||
<title>How to Install BEAM Packages</title>
|
||||
|
||||
<para>
|
||||
BEAM packages are not registered at the top level, simply because they are
|
||||
not relevant to the vast majority of Nix users. They are installable using
|
||||
the <literal>beam.packages.erlang</literal> attribute set (aliased as
|
||||
<literal>beamPackages</literal>), which points to packages built by the
|
||||
default Erlang/OTP version in Nixpkgs, as defined by
|
||||
<literal>beam.interpreters.erlang</literal>. To list the available packages
|
||||
in <literal>beamPackages</literal>, use the following command:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
$ nix-env -f "<nixpkgs>" -qaP -A beamPackages
|
||||
beamPackages.esqlite esqlite-0.2.1
|
||||
beamPackages.goldrush goldrush-0.1.7
|
||||
beamPackages.ibrowse ibrowse-4.2.2
|
||||
beamPackages.jiffy jiffy-0.14.5
|
||||
beamPackages.lager lager-3.0.2
|
||||
beamPackages.meck meck-0.8.3
|
||||
beamPackages.rebar3-pc pc-1.1.0
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
To install any of those packages into your profile, refer to them by their
|
||||
attribute path (first column):
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
$ nix-env -f "<nixpkgs>" -iA beamPackages.ibrowse
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
The attribute path of any BEAM package corresponds to the name of that
|
||||
particular package in <link xlink:href="https://hex.pm">Hex</link> or its
|
||||
OTP Application/Release name.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="packaging-beam-applications">
|
||||
<title>Packaging BEAM Applications</title>
|
||||
|
||||
<section xml:id="packaging-erlang-applications">
|
||||
<title>Erlang Applications</title>
|
||||
|
||||
<section xml:id="rebar3-packages">
|
||||
<title>Rebar3 Packages</title>
|
||||
|
||||
<para>
|
||||
The Nix function, <literal>buildRebar3</literal>, defined in
|
||||
<literal>beam.packages.erlang.buildRebar3</literal> and aliased at the top
|
||||
level, can be used to build a derivation that understands how to build a
|
||||
Rebar3 project. For example, we can build
|
||||
<link
|
||||
xlink:href="https://github.com/erlang-nix/hex2nix">hex2nix</link>
|
||||
as follows:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
{ stdenv, fetchFromGitHub, buildRebar3, ibrowse, jsx, erlware_commons }:
|
||||
|
||||
buildRebar3 rec {
|
||||
name = "hex2nix";
|
||||
version = "0.0.1";
|
||||
|
||||
src = fetchFromGitHub {
|
||||
owner = "ericbmerritt";
|
||||
repo = "hex2nix";
|
||||
rev = "${version}";
|
||||
sha256 = "1w7xjidz1l5yjmhlplfx7kphmnpvqm67w99hd2m7kdixwdxq0zqg";
|
||||
};
|
||||
|
||||
beamDeps = [ ibrowse jsx erlware_commons ];
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
Such derivations are callable with
|
||||
<literal>beam.packages.erlang.callPackage</literal> (see
|
||||
<xref
|
||||
linkend="erlang-call-package"/>). To call this package using
|
||||
the normal <literal>callPackage</literal>, refer to dependency packages
|
||||
via <literal>beamPackages</literal>, e.g.
|
||||
<literal>beamPackages.ibrowse</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Notably, <literal>buildRebar3</literal> includes
|
||||
<literal>beamDeps</literal>, while <literal>stdenv.mkDerivation</literal>
|
||||
does not. BEAM dependencies added there will be correctly handled by the
|
||||
system.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If a package needs to compile native code via Rebar3's port compilation
|
||||
mechanism, add <literal>compilePort = true;</literal> to the derivation.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="erlang-mk-packages">
|
||||
<title>Erlang.mk Packages</title>
|
||||
|
||||
<para>
|
||||
Erlang.mk functions similarly to Rebar3, except we use
|
||||
<literal>buildErlangMk</literal> instead of
|
||||
<literal>buildRebar3</literal>.
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
{ buildErlangMk, fetchHex, cowlib, ranch }:
|
||||
|
||||
buildErlangMk {
|
||||
name = "cowboy";
|
||||
version = "1.0.4";
|
||||
|
||||
src = fetchHex {
|
||||
pkg = "cowboy";
|
||||
version = "1.0.4";
|
||||
sha256 = "6a0edee96885fae3a8dd0ac1f333538a42e807db638a9453064ccfdaa6b9fdac";
|
||||
};
|
||||
|
||||
beamDeps = [ cowlib ranch ];
|
||||
|
||||
meta = {
|
||||
description = ''
|
||||
Small, fast, modular HTTP server written in Erlang
|
||||
'';
|
||||
license = stdenv.lib.licenses.isc;
|
||||
homepage = https://github.com/ninenines/cowboy;
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
</section>
|
||||
|
||||
<section xml:id="mix-packages">
|
||||
<title>Mix Packages</title>
|
||||
|
||||
<para>
|
||||
Mix functions similarly to Rebar3, except we use
|
||||
<literal>buildMix</literal> instead of <literal>buildRebar3</literal>.
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
{ buildMix, fetchHex, plug, absinthe }:
|
||||
|
||||
buildMix {
|
||||
name = "absinthe_plug";
|
||||
version = "1.0.0";
|
||||
|
||||
src = fetchHex {
|
||||
pkg = "absinthe_plug";
|
||||
version = "1.0.0";
|
||||
sha256 = "08459823fe1fd4f0325a8bf0c937a4520583a5a26d73b193040ab30a1dfc0b33";
|
||||
};
|
||||
|
||||
beamDeps = [ plug absinthe ];
|
||||
|
||||
meta = {
|
||||
description = ''
|
||||
A plug for Absinthe, an experimental GraphQL toolkit
|
||||
'';
|
||||
license = stdenv.lib.licenses.bsd3;
|
||||
homepage = https://github.com/CargoSense/absinthe_plug;
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
Alternatively, we can use <literal>buildHex</literal> as a shortcut:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
{ buildHex, buildMix, plug, absinthe }:
|
||||
|
||||
buildHex {
|
||||
name = "absinthe_plug";
|
||||
version = "1.0.0";
|
||||
|
||||
sha256 = "08459823fe1fd4f0325a8bf0c937a4520583a5a26d73b193040ab30a1dfc0b33";
|
||||
|
||||
builder = buildMix;
|
||||
|
||||
beamDeps = [ plug absinthe ];
|
||||
|
||||
meta = {
|
||||
description = ''
|
||||
A plug for Absinthe, an experimental GraphQL toolkit
|
||||
'';
|
||||
license = stdenv.lib.licenses.bsd3;
|
||||
homepage = https://github.com/CargoSense/absinthe_plug;
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section xml:id="how-to-develop">
|
||||
<title>How to Develop</title>
|
||||
|
||||
<section xml:id="accessing-an-environment">
|
||||
<title>Accessing an Environment</title>
|
||||
|
||||
<para>
|
||||
Often, we simply want to access a valid environment that contains a
|
||||
specific package and its dependencies. We can accomplish that with the
|
||||
<literal>env</literal> attribute of a derivation. For example, let's say we
|
||||
want to access an Erlang REPL with <literal>ibrowse</literal> loaded up. We
|
||||
could do the following:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
$ nix-shell -A beamPackages.ibrowse.env --run "erl"
|
||||
Erlang/OTP 18 [erts-7.0] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]
|
||||
|
||||
Eshell V7.0 (abort with ^G)
|
||||
1> m(ibrowse).
|
||||
Module: ibrowse
|
||||
MD5: 3b3e0137d0cbb28070146978a3392945
|
||||
Compiled: January 10 2016, 23:34
|
||||
Object file: /nix/store/g1rlf65rdgjs4abbyj4grp37ry7ywivj-ibrowse-4.2.2/lib/erlang/lib/ibrowse-4.2.2/ebin/ibrowse.beam
|
||||
Compiler options: [{outdir,"/tmp/nix-build-ibrowse-4.2.2.drv-0/hex-source-ibrowse-4.2.2/_build/default/lib/ibrowse/ebin"},
|
||||
debug_info,debug_info,nowarn_shadow_vars,
|
||||
warn_unused_import,warn_unused_vars,warnings_as_errors,
|
||||
{i,"/tmp/nix-build-ibrowse-4.2.2.drv-0/hex-source-ibrowse-4.2.2/_build/default/lib/ibrowse/include"}]
|
||||
Exports:
|
||||
add_config/1 send_req_direct/7
|
||||
all_trace_off/0 set_dest/3
|
||||
code_change/3 set_max_attempts/3
|
||||
get_config_value/1 set_max_pipeline_size/3
|
||||
get_config_value/2 set_max_sessions/3
|
||||
get_metrics/0 show_dest_status/0
|
||||
get_metrics/2 show_dest_status/1
|
||||
handle_call/3 show_dest_status/2
|
||||
handle_cast/2 spawn_link_worker_process/1
|
||||
handle_info/2 spawn_link_worker_process/2
|
||||
init/1 spawn_worker_process/1
|
||||
module_info/0 spawn_worker_process/2
|
||||
module_info/1 start/0
|
||||
rescan_config/0 start_link/0
|
||||
rescan_config/1 stop/0
|
||||
send_req/3 stop_worker_process/1
|
||||
send_req/4 stream_close/1
|
||||
send_req/5 stream_next/1
|
||||
send_req/6 terminate/2
|
||||
send_req_direct/4 trace_off/0
|
||||
send_req_direct/5 trace_off/2
|
||||
send_req_direct/6 trace_on/0
|
||||
trace_on/2
|
||||
ok
|
||||
2>
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
Notice the <literal>-A beamPackages.ibrowse.env</literal>. That is the key
|
||||
to this functionality.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="creating-a-shell">
|
||||
<title>Creating a Shell</title>
|
||||
|
||||
<para>
|
||||
Getting access to an environment often isn't enough to do real development.
|
||||
Usually, we need to create a <literal>shell.nix</literal> file and do our
|
||||
development inside of the environment specified therein. This file looks a
|
||||
lot like the packaging described above, except that <literal>src</literal>
|
||||
points to the project root and we call the package directly.
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
{ pkgs ? import "<nixpkgs"> {} }:
|
||||
|
||||
with pkgs;
|
||||
|
||||
let
|
||||
|
||||
f = { buildRebar3, ibrowse, jsx, erlware_commons }:
|
||||
buildRebar3 {
|
||||
name = "hex2nix";
|
||||
version = "0.1.0";
|
||||
src = ./.;
|
||||
beamDeps = [ ibrowse jsx erlware_commons ];
|
||||
};
|
||||
drv = beamPackages.callPackage f {};
|
||||
|
||||
in
|
||||
|
||||
drv
|
||||
</programlisting>
|
||||
|
||||
<section xml:id="building-in-a-shell">
|
||||
<title>Building in a Shell (for Mix Projects)</title>
|
||||
|
||||
<para>
|
||||
We can leverage the support of the derivation, irrespective of the build
|
||||
derivation, by calling the commands themselves.
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
# =============================================================================
|
||||
# Variables
|
||||
# =============================================================================
|
||||
|
||||
NIX_TEMPLATES := "$(CURDIR)/nix-templates"
|
||||
|
||||
TARGET := "$(PREFIX)"
|
||||
|
||||
PROJECT_NAME := thorndyke
|
||||
|
||||
NIXPKGS=../nixpkgs
|
||||
NIX_PATH=nixpkgs=$(NIXPKGS)
|
||||
NIX_SHELL=nix-shell -I "$(NIX_PATH)" --pure
|
||||
# =============================================================================
|
||||
# Rules
|
||||
# =============================================================================
|
||||
.PHONY= all test clean repl shell build test analyze configure install \
|
||||
test-nix-install publish plt analyze
|
||||
|
||||
all: build
|
||||
|
||||
guard-%:
|
||||
@ if [ "${${*}}" == "" ]; then \
|
||||
echo "Environment variable $* not set"; \
|
||||
exit 1; \
|
||||
fi
|
||||
|
||||
clean:
|
||||
rm -rf _build
|
||||
rm -rf .cache
|
||||
|
||||
repl:
|
||||
$(NIX_SHELL) --run "iex -pa './_build/prod/lib/*/ebin'"
|
||||
|
||||
shell:
|
||||
$(NIX_SHELL)
|
||||
|
||||
configure:
|
||||
$(NIX_SHELL) --command 'eval "$$configurePhase"'
|
||||
|
||||
build: configure
|
||||
$(NIX_SHELL) --command 'eval "$$buildPhase"'
|
||||
|
||||
install:
|
||||
$(NIX_SHELL) --command 'eval "$$installPhase"'
|
||||
|
||||
test:
|
||||
$(NIX_SHELL) --command 'mix test --no-start --no-deps-check'
|
||||
|
||||
plt:
|
||||
$(NIX_SHELL) --run "mix dialyzer.plt --no-deps-check"
|
||||
|
||||
analyze: build plt
|
||||
$(NIX_SHELL) --run "mix dialyzer --no-compile"
|
||||
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
Using a <literal>shell.nix</literal> as described (see
|
||||
<xref
|
||||
linkend="creating-a-shell"/>) should just work. Aside from
|
||||
<literal>test</literal>, <literal>plt</literal>, and
|
||||
<literal>analyze</literal>, the Make targets work just fine for all of the
|
||||
build derivations.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section xml:id="generating-packages-from-hex-with-hex2nix">
|
||||
<title>Generating Packages from Hex with <literal>hex2nix</literal></title>
|
||||
|
||||
<para>
|
||||
Updating the <link xlink:href="https://hex.pm">Hex</link> package set
|
||||
requires
|
||||
<link
|
||||
xlink:href="https://github.com/erlang-nix/hex2nix">hex2nix</link>.
|
||||
Given the path to the Erlang modules (usually
|
||||
<literal>pkgs/development/erlang-modules</literal>), it will dump a file
|
||||
called <literal>hex-packages.nix</literal>, containing all the packages that
|
||||
use a recognized build system in
|
||||
<link
|
||||
xlink:href="https://hex.pm">Hex</link>. It can't be determined,
|
||||
however, whether every package is buildable.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To make life easier for our users, try to build every
|
||||
<link
|
||||
xlink:href="https://hex.pm">Hex</link> package and remove those
|
||||
that fail. To do that, simply run the following command in the root of your
|
||||
<literal>nixpkgs</literal> repository:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
$ nix-build -A beamPackages
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
That will attempt to build every package in <literal>beamPackages</literal>.
|
||||
Then manually remove those that fail. Hopefully, someone will improve
|
||||
<link
|
||||
xlink:href="https://github.com/erlang-nix/hex2nix">hex2nix</link>
|
||||
in the future to automate the process.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
@@ -1,229 +0,0 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="sec-bower">
|
||||
<title>Bower</title>
|
||||
|
||||
<para>
|
||||
<link xlink:href="http://bower.io">Bower</link> is a package manager for web
|
||||
site front-end components. Bower packages (comprising of build artefacts and
|
||||
sometimes sources) are stored in <command>git</command> repositories,
|
||||
typically on Github. The package registry is run by the Bower team with
|
||||
package metadata coming from the <filename>bower.json</filename> file within
|
||||
each package.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The end result of running Bower is a <filename>bower_components</filename>
|
||||
directory which can be included in the web app's build process.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Bower can be run interactively, by installing
|
||||
<varname>nodePackages.bower</varname>. More interestingly, the Bower
|
||||
components can be declared in a Nix derivation, with the help of
|
||||
<varname>nodePackages.bower2nix</varname>.
|
||||
</para>
|
||||
|
||||
<section xml:id="ssec-bower2nix-usage">
|
||||
<title><command>bower2nix</command> usage</title>
|
||||
|
||||
<para>
|
||||
Suppose you have a <filename>bower.json</filename> with the following
|
||||
contents:
|
||||
<example xml:id="ex-bowerJson">
|
||||
<title><filename>bower.json</filename></title>
|
||||
<programlisting language="json">
|
||||
<![CDATA[{
|
||||
"name": "my-web-app",
|
||||
"dependencies": {
|
||||
"angular": "~1.5.0",
|
||||
"bootstrap": "~3.3.6"
|
||||
}
|
||||
}]]>
|
||||
</programlisting>
|
||||
</example>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Running <command>bower2nix</command> will produce something like the
|
||||
following output:
|
||||
<programlisting language="nix">
|
||||
<![CDATA[{ fetchbower, buildEnv }:
|
||||
buildEnv { name = "bower-env"; ignoreCollisions = true; paths = [
|
||||
(fetchbower "angular" "1.5.3" "~1.5.0" "1749xb0firxdra4rzadm4q9x90v6pzkbd7xmcyjk6qfza09ykk9y")
|
||||
(fetchbower "bootstrap" "3.3.6" "~3.3.6" "1vvqlpbfcy0k5pncfjaiskj3y6scwifxygfqnw393sjfxiviwmbv")
|
||||
(fetchbower "jquery" "2.2.2" "1.9.1 - 2" "10sp5h98sqwk90y4k6hbdviwqzvzwqf47r3r51pakch5ii2y7js1")
|
||||
]; }]]>
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Using the <command>bower2nix</command> command line arguments, the output
|
||||
can be redirected to a file. A name like
|
||||
<filename>bower-packages.nix</filename> would be fine.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The resulting derivation is a union of all the downloaded Bower packages
|
||||
(and their dependencies). To use it, they still need to be linked together
|
||||
by Bower, which is where <varname>buildBowerComponents</varname> is useful.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="ssec-build-bower-components">
|
||||
<title><varname>buildBowerComponents</varname> function</title>
|
||||
|
||||
<para>
|
||||
The function is implemented in
|
||||
<link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/bower-modules/generic/default.nix">
|
||||
<filename>pkgs/development/bower-modules/generic/default.nix</filename></link>.
|
||||
Example usage:
|
||||
<example xml:id="ex-buildBowerComponents">
|
||||
<title>buildBowerComponents</title>
|
||||
<programlisting language="nix">
|
||||
bowerComponents = buildBowerComponents {
|
||||
name = "my-web-app";
|
||||
generated = ./bower-packages.nix; <co xml:id="ex-buildBowerComponents-1" />
|
||||
src = myWebApp; <co xml:id="ex-buildBowerComponents-2" />
|
||||
};
|
||||
</programlisting>
|
||||
</example>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In <xref linkend="ex-buildBowerComponents" />, the following arguments are
|
||||
of special significance to the function:
|
||||
<calloutlist>
|
||||
<callout arearefs="ex-buildBowerComponents-1">
|
||||
<para>
|
||||
<varname>generated</varname> specifies the file which was created by
|
||||
<command>bower2nix</command>.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs="ex-buildBowerComponents-2">
|
||||
<para>
|
||||
<varname>src</varname> is your project's sources. It needs to contain a
|
||||
<filename>bower.json</filename> file.
|
||||
</para>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<varname>buildBowerComponents</varname> will run Bower to link together the
|
||||
output of <command>bower2nix</command>, resulting in a
|
||||
<filename>bower_components</filename> directory which can be used.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Here is an example of a web frontend build process using
|
||||
<command>gulp</command>. You might use <command>grunt</command>, or anything
|
||||
else.
|
||||
</para>
|
||||
|
||||
<example xml:id="ex-bowerGulpFile">
|
||||
<title>Example build script (<filename>gulpfile.js</filename>)</title>
|
||||
<programlisting language="javascript">
|
||||
<![CDATA[var gulp = require('gulp');
|
||||
|
||||
gulp.task('default', [], function () {
|
||||
gulp.start('build');
|
||||
});
|
||||
|
||||
gulp.task('build', [], function () {
|
||||
console.log("Just a dummy gulp build");
|
||||
gulp
|
||||
.src(["./bower_components/**/*"])
|
||||
.pipe(gulp.dest("./gulpdist/"));
|
||||
});]]>
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<example xml:id="ex-buildBowerComponentsDefaultNix">
|
||||
<title>Full example — <filename>default.nix</filename></title>
|
||||
<programlisting language="nix">
|
||||
{ myWebApp ? { outPath = ./.; name = "myWebApp"; }
|
||||
, pkgs ? import <nixpkgs> {}
|
||||
}:
|
||||
|
||||
pkgs.stdenv.mkDerivation {
|
||||
name = "my-web-app-frontend";
|
||||
src = myWebApp;
|
||||
|
||||
buildInputs = [ pkgs.nodePackages.gulp ];
|
||||
|
||||
bowerComponents = pkgs.buildBowerComponents { <co xml:id="ex-buildBowerComponentsDefault-1" />
|
||||
name = "my-web-app";
|
||||
generated = ./bower-packages.nix;
|
||||
src = myWebApp;
|
||||
};
|
||||
|
||||
buildPhase = ''
|
||||
cp --reflink=auto --no-preserve=mode -R $bowerComponents/bower_components . <co xml:id="ex-buildBowerComponentsDefault-2" />
|
||||
export HOME=$PWD <co xml:id="ex-buildBowerComponentsDefault-3" />
|
||||
${pkgs.nodePackages.gulp}/bin/gulp build <co xml:id="ex-buildBowerComponentsDefault-4" />
|
||||
'';
|
||||
|
||||
installPhase = "mv gulpdist $out";
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<para>
|
||||
A few notes about <xref linkend="ex-buildBowerComponentsDefaultNix" />:
|
||||
<calloutlist>
|
||||
<callout arearefs="ex-buildBowerComponentsDefault-1">
|
||||
<para>
|
||||
The result of <varname>buildBowerComponents</varname> is an input to the
|
||||
frontend build.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs="ex-buildBowerComponentsDefault-2">
|
||||
<para>
|
||||
Whether to symlink or copy the <filename>bower_components</filename>
|
||||
directory depends on the build tool in use. In this case a copy is used
|
||||
to avoid <command>gulp</command> silliness with permissions.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs="ex-buildBowerComponentsDefault-3">
|
||||
<para>
|
||||
<command>gulp</command> requires <varname>HOME</varname> to refer to a
|
||||
writeable directory.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs="ex-buildBowerComponentsDefault-4">
|
||||
<para>
|
||||
The actual build command. Other tools could be used.
|
||||
</para>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="ssec-bower2nix-troubleshooting">
|
||||
<title>Troubleshooting</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>ENOCACHE</literal> errors from <varname>buildBowerComponents</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This means that Bower was looking for a package version which doesn't
|
||||
exist in the generated <filename>bower-packages.nix</filename>.
|
||||
</para>
|
||||
<para>
|
||||
If <filename>bower.json</filename> has been updated, then run
|
||||
<command>bower2nix</command> again.
|
||||
</para>
|
||||
<para>
|
||||
It could also be a bug in <command>bower2nix</command> or
|
||||
<command>fetchbower</command>. If possible, try reformulating the version
|
||||
specification in <filename>bower.json</filename>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</section>
|
||||
</section>
|
||||
@@ -1,64 +0,0 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="sec-language-coq">
|
||||
<title>Coq</title>
|
||||
|
||||
<para>
|
||||
Coq libraries should be installed in
|
||||
<literal>$(out)/lib/coq/${coq.coq-version}/user-contrib/</literal>. Such
|
||||
directories are automatically added to the <literal>$COQPATH</literal>
|
||||
environment variable by the hook defined in the Coq derivation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Some extensions (plugins) might require OCaml and sometimes other OCaml
|
||||
packages. The <literal>coq.ocamlPackages</literal> attribute can be used to
|
||||
depend on the same package set Coq was built against.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Coq libraries may be compatible with some specific versions of Coq only. The
|
||||
<literal>compatibleCoqVersions</literal> attribute is used to precisely
|
||||
select those versions of Coq that are compatible with this derivation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Here is a simple package example. It is a pure Coq library, thus it depends
|
||||
on Coq. It builds on the Mathematical Components library, thus it also takes
|
||||
<literal>mathcomp</literal> as <literal>buildInputs</literal>. Its
|
||||
<literal>Makefile</literal> has been generated using
|
||||
<literal>coq_makefile</literal> so we only have to set the
|
||||
<literal>$COQLIB</literal> variable at install time.
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
{ stdenv, fetchFromGitHub, coq, mathcomp }:
|
||||
|
||||
stdenv.mkDerivation rec {
|
||||
name = "coq${coq.coq-version}-multinomials-${version}";
|
||||
version = "1.0";
|
||||
src = fetchFromGitHub {
|
||||
owner = "math-comp";
|
||||
repo = "multinomials";
|
||||
rev = version;
|
||||
sha256 = "1qmbxp1h81cy3imh627pznmng0kvv37k4hrwi2faa101s6bcx55m";
|
||||
};
|
||||
|
||||
buildInputs = [ coq ];
|
||||
propagatedBuildInputs = [ mathcomp ];
|
||||
|
||||
installFlags = "COQLIB=$(out)/lib/coq/${coq.coq-version}/";
|
||||
|
||||
meta = {
|
||||
description = "A Coq/SSReflect Library for Monoidal Rings and Multinomials";
|
||||
inherit (src.meta) homepage;
|
||||
license = stdenv.lib.licenses.cecill-b;
|
||||
inherit (coq.meta) platforms;
|
||||
};
|
||||
|
||||
passthru = {
|
||||
compatibleCoqVersions = v: builtins.elem v [ "8.5" "8.6" "8.7" ];
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
</section>
|
||||
@@ -1,185 +0,0 @@
|
||||
# User's Guide to Emscripten in Nixpkgs
|
||||
|
||||
[Emscripten](https://github.com/kripken/emscripten): An LLVM-to-JavaScript Compiler
|
||||
|
||||
This section of the manual covers how to use `emscripten` in nixpkgs.
|
||||
|
||||
Minimal requirements:
|
||||
|
||||
* nix
|
||||
* nixpkgs
|
||||
|
||||
Modes of use of `emscripten`:
|
||||
|
||||
* **Imperative usage** (on the command line):
|
||||
|
||||
If you want to work with `emcc`, `emconfigure` and `emmake` as you are used to from Ubuntu and similar distributions you can use these commands:
|
||||
|
||||
* `nix-env -i emscripten`
|
||||
* `nix-shell -p emscripten`
|
||||
|
||||
* **Declarative usage**:
|
||||
|
||||
This mode is far more power full since this makes use of `nix` for dependency management of emscripten libraries and targets by using the `mkDerivation` which is implemented by `pkgs.emscriptenStdenv` and `pkgs.buildEmscriptenPackage`. The source for the packages is in `pkgs/top-level/emscripten-packages.nix` and the abstraction behind it in `pkgs/development/em-modules/generic/default.nix`.
|
||||
* build and install all packages:
|
||||
* `nix-env -iA emscriptenPackages`
|
||||
|
||||
* dev-shell for zlib implementation hacking:
|
||||
* `nix-shell -A emscriptenPackages.zlib`
|
||||
|
||||
|
||||
## Imperative usage
|
||||
|
||||
A few things to note:
|
||||
|
||||
* `export EMCC_DEBUG=2` is nice for debugging
|
||||
* `~/.emscripten`, the build artifact cache sometimes creates issues and needs to be removed from time to time
|
||||
|
||||
|
||||
## Declarative usage
|
||||
|
||||
Let's see two different examples from `pkgs/top-level/emscripten-packages.nix`:
|
||||
|
||||
* `pkgs.zlib.override`
|
||||
* `pkgs.buildEmscriptenPackage`
|
||||
|
||||
Both are interesting concepts.
|
||||
|
||||
A special requirement of the `pkgs.buildEmscriptenPackage` is the `doCheck = true` is a default meaning that each emscriptenPackage requires a `checkPhase` implemented.
|
||||
|
||||
* Use `export EMCC_DEBUG=2` from within a emscriptenPackage's `phase` to get more detailed debug output what is going wrong.
|
||||
* ~/.emscripten cache is requiring us to set `HOME=$TMPDIR` in individual phases. This makes compilation slower but also makes it more deterministic.
|
||||
|
||||
### Usage 1: pkgs.zlib.override
|
||||
|
||||
This example uses `zlib` from nixpkgs but instead of compiling **C** to **ELF** it compiles **C** to **JS** since we were using `pkgs.zlib.override` and changed stdenv to `pkgs.emscriptenStdenv`. A few adaptions and hacks were set in place to make it working. One advantage is that when `pkgs.zlib` is updated, it will automatically update this package as well. However, this can also be the downside...
|
||||
|
||||
See the `zlib` example:
|
||||
|
||||
zlib = (pkgs.zlib.override {
|
||||
stdenv = pkgs.emscriptenStdenv;
|
||||
}).overrideDerivation
|
||||
(old: rec {
|
||||
buildInputs = old.buildInputs ++ [ pkgconfig ];
|
||||
# we need to reset this setting!
|
||||
NIX_CFLAGS_COMPILE="";
|
||||
configurePhase = ''
|
||||
# FIXME: Some tests require writing at $HOME
|
||||
HOME=$TMPDIR
|
||||
runHook preConfigure
|
||||
|
||||
#export EMCC_DEBUG=2
|
||||
emconfigure ./configure --prefix=$out --shared
|
||||
|
||||
runHook postConfigure
|
||||
'';
|
||||
dontStrip = true;
|
||||
outputs = [ "out" ];
|
||||
buildPhase = ''
|
||||
emmake make
|
||||
'';
|
||||
installPhase = ''
|
||||
emmake make install
|
||||
'';
|
||||
checkPhase = ''
|
||||
echo "================= testing zlib using node ================="
|
||||
|
||||
echo "Compiling a custom test"
|
||||
set -x
|
||||
emcc -O2 -s EMULATE_FUNCTION_POINTER_CASTS=1 test/example.c -DZ_SOLO \
|
||||
libz.so.${old.version} -I . -o example.js
|
||||
|
||||
echo "Using node to execute the test"
|
||||
${pkgs.nodejs}/bin/node ./example.js
|
||||
|
||||
set +x
|
||||
if [ $? -ne 0 ]; then
|
||||
echo "test failed for some reason"
|
||||
exit 1;
|
||||
else
|
||||
echo "it seems to work! very good."
|
||||
fi
|
||||
echo "================= /testing zlib using node ================="
|
||||
'';
|
||||
|
||||
postPatch = pkgs.stdenv.lib.optionalString pkgs.stdenv.isDarwin ''
|
||||
substituteInPlace configure \
|
||||
--replace '/usr/bin/libtool' 'ar' \
|
||||
--replace 'AR="libtool"' 'AR="ar"' \
|
||||
--replace 'ARFLAGS="-o"' 'ARFLAGS="-r"'
|
||||
'';
|
||||
});
|
||||
|
||||
### Usage 2: pkgs.buildEmscriptenPackage
|
||||
|
||||
This `xmlmirror` example features a emscriptenPackage which is defined completely from this context and no `pkgs.zlib.override` is used.
|
||||
|
||||
xmlmirror = pkgs.buildEmscriptenPackage rec {
|
||||
name = "xmlmirror";
|
||||
|
||||
buildInputs = [ pkgconfig autoconf automake libtool gnumake libxml2 nodejs openjdk json_c ];
|
||||
nativeBuildInputs = [ pkgconfig zlib ];
|
||||
|
||||
src = pkgs.fetchgit {
|
||||
url = "https://gitlab.com/odfplugfest/xmlmirror.git";
|
||||
rev = "4fd7e86f7c9526b8f4c1733e5c8b45175860a8fd";
|
||||
sha256 = "1jasdqnbdnb83wbcnyrp32f36w3xwhwp0wq8lwwmhqagxrij1r4b";
|
||||
};
|
||||
|
||||
configurePhase = ''
|
||||
rm -f fastXmlLint.js*
|
||||
# a fix for ERROR:root:For asm.js, TOTAL_MEMORY must be a multiple of 16MB, was 234217728
|
||||
# https://gitlab.com/odfplugfest/xmlmirror/issues/8
|
||||
sed -e "s/TOTAL_MEMORY=234217728/TOTAL_MEMORY=268435456/g" -i Makefile.emEnv
|
||||
# https://github.com/kripken/emscripten/issues/6344
|
||||
# https://gitlab.com/odfplugfest/xmlmirror/issues/9
|
||||
sed -e "s/\$(JSONC_LDFLAGS) \$(ZLIB_LDFLAGS) \$(LIBXML20_LDFLAGS)/\$(JSONC_LDFLAGS) \$(LIBXML20_LDFLAGS) \$(ZLIB_LDFLAGS) /g" -i Makefile.emEnv
|
||||
# https://gitlab.com/odfplugfest/xmlmirror/issues/11
|
||||
sed -e "s/-o fastXmlLint.js/-s EXTRA_EXPORTED_RUNTIME_METHODS='[\"ccall\", \"cwrap\"]' -o fastXmlLint.js/g" -i Makefile.emEnv
|
||||
'';
|
||||
|
||||
buildPhase = ''
|
||||
HOME=$TMPDIR
|
||||
make -f Makefile.emEnv
|
||||
'';
|
||||
|
||||
outputs = [ "out" "doc" ];
|
||||
|
||||
installPhase = ''
|
||||
mkdir -p $out/share
|
||||
mkdir -p $doc/share/${name}
|
||||
|
||||
cp Demo* $out/share
|
||||
cp -R codemirror-5.12 $out/share
|
||||
cp fastXmlLint.js* $out/share
|
||||
cp *.xsd $out/share
|
||||
cp *.js $out/share
|
||||
cp *.xhtml $out/share
|
||||
cp *.html $out/share
|
||||
cp *.json $out/share
|
||||
cp *.rng $out/share
|
||||
cp README.md $doc/share/${name}
|
||||
'';
|
||||
checkPhase = ''
|
||||
|
||||
'';
|
||||
};
|
||||
|
||||
### Declarative debugging
|
||||
|
||||
Use `nix-shell -I nixpkgs=/some/dir/nixpkgs -A emscriptenPackages.libz` and from there you can go trough the individual steps. This makes it easy to build a good `unit test` or list the files of the project.
|
||||
|
||||
1. `nix-shell -I nixpkgs=/some/dir/nixpkgs -A emscriptenPackages.libz`
|
||||
2. `cd /tmp/`
|
||||
3. `unpackPhase`
|
||||
4. cd libz-1.2.3
|
||||
5. `configurePhase`
|
||||
6. `buildPhase`
|
||||
7. ... happy hacking...
|
||||
|
||||
## Summary
|
||||
|
||||
Using this toolchain makes it easy to leverage `nix` from NixOS, MacOSX or even Windows (WSL+ubuntu+nix). This toolchain is reproducible, behaves like the rest of the packages from nixpkgs and contains a set of well working examples to learn and adapt from.
|
||||
|
||||
If in trouble, ask the maintainers.
|
||||
|
||||
@@ -1,241 +0,0 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="sec-language-go">
|
||||
<title>Go</title>
|
||||
|
||||
<section xml:id="ssec-go-modules">
|
||||
<title>Go modules</title>
|
||||
|
||||
<para>
|
||||
The function <varname> buildGoModule </varname> builds Go programs managed
|
||||
with Go modules. It builds a
|
||||
<link xlink:href="https://github.com/golang/go/wiki/Modules">Go
|
||||
modules</link> through a two phase build:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
An intermediate fetcher derivation. This derivation will be used to fetch
|
||||
all of the dependencies of the Go module.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
A final derivation will use the output of the intermediate derivation to
|
||||
build the binaries and produce the final output.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<example xml:id='ex-buildGoModule'>
|
||||
<title>buildGoModule</title>
|
||||
<programlisting>
|
||||
pet = buildGoModule rec {
|
||||
name = "pet-${version}";
|
||||
version = "0.3.4";
|
||||
|
||||
src = fetchFromGitHub {
|
||||
owner = "knqyf263";
|
||||
repo = "pet";
|
||||
rev = "v${version}";
|
||||
sha256 = "0m2fzpqxk7hrbxsgqplkg7h2p7gv6s1miymv3gvw0cz039skag0s";
|
||||
};
|
||||
|
||||
modSha256 = "1879j77k96684wi554rkjxydrj8g3hpp0kvxz03sd8dmwr3lh83j"; <co xml:id='ex-buildGoModule-1' />
|
||||
|
||||
subPackages = [ "." ]; <co xml:id='ex-buildGoModule-2' />
|
||||
|
||||
meta = with lib; {
|
||||
description = "Simple command-line snippet manager, written in Go";
|
||||
homepage = https://github.com/knqyf263/pet;
|
||||
license = licenses.mit;
|
||||
maintainers = with maintainers; [ kalbasit ];
|
||||
platforms = platforms.linux ++ platforms.darwin;
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<para>
|
||||
<xref linkend='ex-buildGoModule'/> is an example expression using
|
||||
buildGoModule, the following arguments are of special significance to the
|
||||
function:
|
||||
<calloutlist>
|
||||
<callout arearefs='ex-buildGoModule-1'>
|
||||
<para>
|
||||
<varname>modSha256</varname> is the hash of the output of the
|
||||
intermediate fetcher derivation.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-buildGoModule-2'>
|
||||
<para>
|
||||
<varname>subPackages</varname> limits the builder from building child
|
||||
packages that have not been listed. If <varname>subPackages</varname> is
|
||||
not specified, all child packages will be built.
|
||||
</para>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="ssec-go-legacy">
|
||||
<title>Go legacy</title>
|
||||
|
||||
<para>
|
||||
The function <varname> buildGoPackage </varname> builds legacy Go programs,
|
||||
not supporting Go modules.
|
||||
</para>
|
||||
|
||||
<example xml:id='ex-buildGoPackage'>
|
||||
<title>buildGoPackage</title>
|
||||
<programlisting>
|
||||
deis = buildGoPackage rec {
|
||||
name = "deis-${version}";
|
||||
version = "1.13.0";
|
||||
|
||||
goPackagePath = "github.com/deis/deis"; <co xml:id='ex-buildGoPackage-1' />
|
||||
subPackages = [ "client" ]; <co xml:id='ex-buildGoPackage-2' />
|
||||
|
||||
src = fetchFromGitHub {
|
||||
owner = "deis";
|
||||
repo = "deis";
|
||||
rev = "v${version}";
|
||||
sha256 = "1qv9lxqx7m18029lj8cw3k7jngvxs4iciwrypdy0gd2nnghc68sw";
|
||||
};
|
||||
|
||||
goDeps = ./deps.nix; <co xml:id='ex-buildGoPackage-3' />
|
||||
|
||||
buildFlags = "--tags release"; <co xml:id='ex-buildGoPackage-4' />
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<para>
|
||||
<xref linkend='ex-buildGoPackage'/> is an example expression using
|
||||
buildGoPackage, the following arguments are of special significance to the
|
||||
function:
|
||||
<calloutlist>
|
||||
<callout arearefs='ex-buildGoPackage-1'>
|
||||
<para>
|
||||
<varname>goPackagePath</varname> specifies the package's canonical Go
|
||||
import path.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-buildGoPackage-2'>
|
||||
<para>
|
||||
<varname>subPackages</varname> limits the builder from building child
|
||||
packages that have not been listed. If <varname>subPackages</varname> is
|
||||
not specified, all child packages will be built.
|
||||
</para>
|
||||
<para>
|
||||
In this example only <literal>github.com/deis/deis/client</literal> will
|
||||
be built.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-buildGoPackage-3'>
|
||||
<para>
|
||||
<varname>goDeps</varname> is where the Go dependencies of a Go program
|
||||
are listed as a list of package source identified by Go import path. It
|
||||
could be imported as a separate <varname>deps.nix</varname> file for
|
||||
readability. The dependency data structure is described below.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-buildGoPackage-4'>
|
||||
<para>
|
||||
<varname>buildFlags</varname> is a list of flags passed to the go build
|
||||
command.
|
||||
</para>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <varname>goDeps</varname> attribute can be imported from a separate
|
||||
<varname>nix</varname> file that defines which Go libraries are needed and
|
||||
should be included in <varname>GOPATH</varname> for
|
||||
<varname>buildPhase</varname>.
|
||||
</para>
|
||||
|
||||
<example xml:id='ex-goDeps'>
|
||||
<title>deps.nix</title>
|
||||
<programlisting>
|
||||
[ <co xml:id='ex-goDeps-1' />
|
||||
{
|
||||
goPackagePath = "gopkg.in/yaml.v2"; <co xml:id='ex-goDeps-2' />
|
||||
fetch = {
|
||||
type = "git"; <co xml:id='ex-goDeps-3' />
|
||||
url = "https://gopkg.in/yaml.v2";
|
||||
rev = "a83829b6f1293c91addabc89d0571c246397bbf4";
|
||||
sha256 = "1m4dsmk90sbi17571h6pld44zxz7jc4lrnl4f27dpd1l8g5xvjhh";
|
||||
};
|
||||
}
|
||||
{
|
||||
goPackagePath = "github.com/docopt/docopt-go";
|
||||
fetch = {
|
||||
type = "git";
|
||||
url = "https://github.com/docopt/docopt-go";
|
||||
rev = "784ddc588536785e7299f7272f39101f7faccc3f";
|
||||
sha256 = "0wwz48jl9fvl1iknvn9dqr4gfy1qs03gxaikrxxp9gry6773v3sj";
|
||||
};
|
||||
}
|
||||
]
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<para>
|
||||
<calloutlist>
|
||||
<callout arearefs='ex-goDeps-1'>
|
||||
<para>
|
||||
<varname>goDeps</varname> is a list of Go dependencies.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-goDeps-2'>
|
||||
<para>
|
||||
<varname>goPackagePath</varname> specifies Go package import path.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='ex-goDeps-3'>
|
||||
<para>
|
||||
<varname>fetch type</varname> that needs to be used to get package
|
||||
source. If <varname>git</varname> is used there should be
|
||||
<varname>url</varname>, <varname>rev</varname> and
|
||||
<varname>sha256</varname> defined next to it.
|
||||
</para>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To extract dependency information from a Go package in automated way use
|
||||
<link xlink:href="https://github.com/kamilchm/go2nix">go2nix</link>. It can
|
||||
produce complete derivation and <varname>goDeps</varname> file for Go
|
||||
programs.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<varname>buildGoPackage</varname> produces
|
||||
<xref linkend='chap-multiple-output' xrefstyle="select: title" /> where
|
||||
<varname>bin</varname> includes program binaries. You can test build a Go
|
||||
binary as follows:
|
||||
<screen>
|
||||
$ nix-build -A deis.bin
|
||||
</screen>
|
||||
or build all outputs with:
|
||||
<screen>
|
||||
$ nix-build -A deis.all
|
||||
</screen>
|
||||
<varname>bin</varname> output will be installed by default with
|
||||
<varname>nix-env -i</varname> or <varname>systemPackages</varname>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You may use Go packages installed into the active Nix profiles by adding the
|
||||
following to your ~/.bashrc:
|
||||
<screen>
|
||||
for p in $NIX_PROFILES; do
|
||||
GOPATH="$p/share/go:$GOPATH"
|
||||
done
|
||||
</screen>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,115 +0,0 @@
|
||||
# Idris packages
|
||||
|
||||
## Installing Idris
|
||||
|
||||
The easiest way to get a working idris version is to install the `idris` attribute:
|
||||
|
||||
```
|
||||
$ # On NixOS
|
||||
$ nix-env -i nixos.idris
|
||||
$ # On non-NixOS
|
||||
$ nix-env -i nixpkgs.idris
|
||||
```
|
||||
|
||||
This however only provides the `prelude` and `base` libraries. To install additional libraries:
|
||||
|
||||
```
|
||||
$ nix-env -iE 'pkgs: pkgs.idrisPackages.with-packages (with pkgs.idrisPackages; [ contrib pruviloj ])'
|
||||
```
|
||||
|
||||
To see all available Idris packages:
|
||||
```
|
||||
$ # On NixOS
|
||||
$ nix-env -qaPA nixos.idrisPackages
|
||||
$ # On non-NixOS
|
||||
$ nix-env -qaPA nixpkgs.idrisPackages
|
||||
```
|
||||
|
||||
Similarly, entering a `nix-shell`:
|
||||
```
|
||||
$ nix-shell -p 'idrisPackages.with-packages (with idrisPackages; [ contrib pruviloj ])'
|
||||
```
|
||||
|
||||
## Starting Idris with library support
|
||||
|
||||
To have access to these libraries in idris, call it with an argument `-p <library name>` for each library:
|
||||
|
||||
```
|
||||
$ nix-shell -p 'idrisPackages.with-packages (with idrisPackages; [ contrib pruviloj ])'
|
||||
[nix-shell:~]$ idris -p contrib -p pruviloj
|
||||
```
|
||||
|
||||
A listing of all available packages the Idris binary has access to is available via `--listlibs`:
|
||||
|
||||
```
|
||||
$ idris --listlibs
|
||||
00prelude-idx.ibc
|
||||
pruviloj
|
||||
base
|
||||
contrib
|
||||
prelude
|
||||
00pruviloj-idx.ibc
|
||||
00base-idx.ibc
|
||||
00contrib-idx.ibc
|
||||
```
|
||||
|
||||
## Building an Idris project with Nix
|
||||
|
||||
As an example of how a Nix expression for an Idris package can be created, here is the one for `idrisPackages.yaml`:
|
||||
|
||||
```nix
|
||||
{ build-idris-package
|
||||
, fetchFromGitHub
|
||||
, contrib
|
||||
, lightyear
|
||||
, lib
|
||||
}:
|
||||
build-idris-package {
|
||||
name = "yaml";
|
||||
version = "2018-01-25";
|
||||
|
||||
# This is the .ipkg file that should be built, defaults to the package name
|
||||
# In this case it should build `Yaml.ipkg` instead of `yaml.ipkg`
|
||||
# This is only necessary because the yaml packages ipkg file is
|
||||
# different from its package name here.
|
||||
ipkgName = "Yaml";
|
||||
# Idris dependencies to provide for the build
|
||||
idrisDeps = [ contrib lightyear ];
|
||||
|
||||
src = fetchFromGitHub {
|
||||
owner = "Heather";
|
||||
repo = "Idris.Yaml";
|
||||
rev = "5afa51ffc839844862b8316faba3bafa15656db4";
|
||||
sha256 = "1g4pi0swmg214kndj85hj50ccmckni7piprsxfdzdfhg87s0avw7";
|
||||
};
|
||||
|
||||
meta = {
|
||||
description = "Idris YAML lib";
|
||||
homepage = https://github.com/Heather/Idris.Yaml;
|
||||
license = lib.licenses.mit;
|
||||
maintainers = [ lib.maintainers.brainrape ];
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Assuming this file is saved as `yaml.nix`, it's buildable using
|
||||
|
||||
```
|
||||
$ nix-build -E '(import <nixpkgs> {}).idrisPackages.callPackage ./yaml.nix {}'
|
||||
```
|
||||
|
||||
Or it's possible to use
|
||||
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
|
||||
{
|
||||
yaml = idrisPackages.callPackage ./yaml.nix {};
|
||||
}
|
||||
```
|
||||
|
||||
in another file (say `default.nix`) to be able to build it with
|
||||
|
||||
```
|
||||
$ nix-build -A yaml
|
||||
```
|
||||
@@ -1,35 +0,0 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="chap-language-support">
|
||||
<title>Support for specific programming languages and frameworks</title>
|
||||
<para>
|
||||
The <link linkend="chap-stdenv">standard build environment</link> makes it
|
||||
easy to build typical Autotools-based packages with very little code. Any
|
||||
other kind of package can be accomodated by overriding the appropriate phases
|
||||
of <literal>stdenv</literal>. However, there are specialised functions in
|
||||
Nixpkgs to easily build packages for other programming languages, such as
|
||||
Perl or Haskell. These are described in this chapter.
|
||||
</para>
|
||||
<xi:include href="android.section.xml" />
|
||||
<xi:include href="beam.xml" />
|
||||
<xi:include href="bower.xml" />
|
||||
<xi:include href="coq.xml" />
|
||||
<xi:include href="go.xml" />
|
||||
<xi:include href="haskell.section.xml" />
|
||||
<xi:include href="idris.section.xml" />
|
||||
<xi:include href="ios.section.xml" />
|
||||
<xi:include href="java.xml" />
|
||||
<xi:include href="lua.xml" />
|
||||
<xi:include href="node.section.xml" />
|
||||
<xi:include href="ocaml.xml" />
|
||||
<xi:include href="perl.xml" />
|
||||
<xi:include href="python.section.xml" />
|
||||
<xi:include href="qt.xml" />
|
||||
<xi:include href="r.section.xml" />
|
||||
<xi:include href="ruby.xml" />
|
||||
<xi:include href="rust.section.xml" />
|
||||
<xi:include href="texlive.xml" />
|
||||
<xi:include href="titanium.section.xml" />
|
||||
<xi:include href="vim.section.xml" />
|
||||
<xi:include href="emscripten.section.xml" />
|
||||
</chapter>
|
||||
@@ -1,219 +0,0 @@
|
||||
---
|
||||
title: iOS
|
||||
author: Sander van der Burg
|
||||
date: 2018-11-18
|
||||
---
|
||||
# iOS
|
||||
|
||||
This component is basically a wrapper/workaround that makes it possible to
|
||||
expose an Xcode installation as a Nix package by means of symlinking to the
|
||||
relevant executables on the host system.
|
||||
|
||||
Since Xcode can't be packaged with Nix, nor we can publish it as a Nix package
|
||||
(because of its license) this is basically the only integration strategy
|
||||
making it possible to do iOS application builds that integrate with other
|
||||
components of the Nix ecosystem
|
||||
|
||||
The primary objective of this project is to use the Nix expression language to
|
||||
specify how iOS apps can be built from source code, and to automatically spawn
|
||||
iOS simulator instances for testing.
|
||||
|
||||
This component also makes it possible to use [Hydra](http://nixos.org/hydra),
|
||||
the Nix-based continuous integration server to regularly build iOS apps and to
|
||||
do wireless ad-hoc installations of enterprise IPAs on iOS devices through
|
||||
Hydra.
|
||||
|
||||
The Xcode build environment implements a number of features.
|
||||
|
||||
Deploying a proxy component wrapper exposing Xcode
|
||||
--------------------------------------------------
|
||||
The first use case is deploying a Nix package that provides symlinks to the Xcode
|
||||
installation on the host system. This package can be used as a build input to
|
||||
any build function implemented in the Nix expression language that requires
|
||||
Xcode.
|
||||
|
||||
```nix
|
||||
let
|
||||
pkgs = import <nixpkgs> {};
|
||||
|
||||
xcodeenv = import ./xcodeenv {
|
||||
inherit (pkgs) stdenv;
|
||||
};
|
||||
in
|
||||
xcodeenv.composeXcodeWrapper {
|
||||
version = "9.2";
|
||||
xcodeBaseDir = "/Applications/Xcode.app";
|
||||
}
|
||||
```
|
||||
|
||||
By deploying the above expression with `nix-build` and inspecting its content
|
||||
you will notice that several Xcode-related executables are exposed as a Nix
|
||||
package:
|
||||
|
||||
```bash
|
||||
$ ls result/bin
|
||||
lrwxr-xr-x 1 sander staff 94 1 jan 1970 Simulator -> /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app/Contents/MacOS/Simulator
|
||||
lrwxr-xr-x 1 sander staff 17 1 jan 1970 codesign -> /usr/bin/codesign
|
||||
lrwxr-xr-x 1 sander staff 17 1 jan 1970 security -> /usr/bin/security
|
||||
lrwxr-xr-x 1 sander staff 21 1 jan 1970 xcode-select -> /usr/bin/xcode-select
|
||||
lrwxr-xr-x 1 sander staff 61 1 jan 1970 xcodebuild -> /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild
|
||||
lrwxr-xr-x 1 sander staff 14 1 jan 1970 xcrun -> /usr/bin/xcrun
|
||||
```
|
||||
|
||||
Building an iOS application
|
||||
---------------------------
|
||||
We can build an iOS app executable for the simulator, or an IPA/xcarchive file
|
||||
for release purposes, e.g. ad-hoc, enterprise or store installations, by
|
||||
executing the `xcodeenv.buildApp {}` function:
|
||||
|
||||
```nix
|
||||
let
|
||||
pkgs = import <nixpkgs> {};
|
||||
|
||||
xcodeenv = import ./xcodeenv {
|
||||
inherit (pkgs) stdenv;
|
||||
};
|
||||
in
|
||||
xcodeenv.buildApp {
|
||||
name = "MyApp";
|
||||
src = ./myappsources;
|
||||
sdkVersion = "11.2";
|
||||
|
||||
target = null; # Corresponds to the name of the app by default
|
||||
configuration = null; # Release for release builds, Debug for debug builds
|
||||
scheme = null; # -scheme will correspond to the app name by default
|
||||
sdk = null; # null will set it to 'iphonesimulator` for simulator builds or `iphoneos` to real builds
|
||||
xcodeFlags = "";
|
||||
|
||||
release = true;
|
||||
certificateFile = ./mycertificate.p12;
|
||||
certificatePassword = "secret";
|
||||
provisioningProfile = ./myprovisioning.profile;
|
||||
signMethod = "ad-hoc"; # 'enterprise' or 'store'
|
||||
generateIPA = true;
|
||||
generateXCArchive = false;
|
||||
|
||||
enableWirelessDistribution = true;
|
||||
installURL = "/installipa.php";
|
||||
bundleId = "mycompany.myapp";
|
||||
appVersion = "1.0";
|
||||
|
||||
# Supports all xcodewrapper parameters as well
|
||||
xcodeBaseDir = "/Applications/Xcode.app";
|
||||
}
|
||||
```
|
||||
|
||||
The above function takes a variety of parameters:
|
||||
* The `name` and `src` parameters are mandatory and specify the name of the app
|
||||
and the location where the source code resides
|
||||
* `sdkVersion` specifies which version of the iOS SDK to use.
|
||||
|
||||
It also possile to adjust the `xcodebuild` parameters. This is only needed in
|
||||
rare circumstances. In most cases the default values should suffice:
|
||||
|
||||
* Specifies which `xcodebuild` target to build. By default it takes the target
|
||||
that has the same name as the app.
|
||||
* The `configuration` parameter can be overridden if desired. By default, it
|
||||
will do a debug build for the simulator and a release build for real devices.
|
||||
* The `scheme` parameter specifies which `-scheme` parameter to propagate to
|
||||
`xcodebuild`. By default, it corresponds to the app name.
|
||||
* The `sdk` parameter specifies which SDK to use. By default, it picks
|
||||
`iphonesimulator` for simulator builds and `iphoneos` for release builds.
|
||||
* The `xcodeFlags` parameter specifies arbitrary command line parameters that
|
||||
should be propagated to `xcodebuild`.
|
||||
|
||||
By default, builds are carried out for the iOS simulator. To do release builds
|
||||
(builds for real iOS devices), you must set the `release` parameter to `true`.
|
||||
In addition, you need to set the following parameters:
|
||||
|
||||
* `certificateFile` refers to a P12 certificate file.
|
||||
* `certificatePassword` specifies the password of the P12 certificate.
|
||||
* `provisioningProfile` refers to the provision profile needed to sign the app
|
||||
* `signMethod` should refer to `ad-hoc` for signing the app with an ad-hoc
|
||||
certificate, `enterprise` for enterprise certificates and `app-store` for App
|
||||
store certificates.
|
||||
* `generateIPA` specifies that we want to produce an IPA file (this is probably
|
||||
what you want)
|
||||
* `generateXCArchive` specifies thet we want to produce an xcarchive file.
|
||||
|
||||
When building IPA files on Hydra and when it is desired to allow iOS devices to
|
||||
install IPAs by browsing to the Hydra build products page, you can enable the
|
||||
`enableWirelessDistribution` parameter.
|
||||
|
||||
When enabled, you need to configure the following options:
|
||||
|
||||
* The `installURL` parameter refers to the URL of a PHP script that composes the
|
||||
`itms-services://` URL allowing iOS devices to install the IPA file.
|
||||
* `bundleId` refers to the bundle ID value of the app
|
||||
* `appVersion` refers to the app's version number
|
||||
|
||||
To use wireless adhoc distributions, you must also install the corresponding
|
||||
PHP script on a web server (see section: 'Installing the PHP script for wireless
|
||||
ad hoc installations from Hydra' for more information).
|
||||
|
||||
In addition to the build parameters, you can also specify any parameters that
|
||||
the `xcodeenv.composeXcodeWrapper {}` function takes. For example, the
|
||||
`xcodeBaseDir` parameter can be overridden to refer to a different Xcode
|
||||
version.
|
||||
|
||||
Spawning simulator instances
|
||||
----------------------------
|
||||
In addition to building iOS apps, we can also automatically spawn simulator
|
||||
instances:
|
||||
|
||||
```nix
|
||||
let
|
||||
pkgs = import <nixpkgs> {};
|
||||
|
||||
xcodeenv = import ./xcodeenv {
|
||||
inherit (pkgs) stdenv;
|
||||
};
|
||||
in
|
||||
xcode.simulateApp {
|
||||
name = "simulate";
|
||||
|
||||
# Supports all xcodewrapper parameters as well
|
||||
xcodeBaseDir = "/Applications/Xcode.app";
|
||||
}
|
||||
```
|
||||
|
||||
The above expression produces a script that starts the simulator from the
|
||||
provided Xcode installation. The script can be started as follows:
|
||||
|
||||
```bash
|
||||
./result/bin/run-test-simulator
|
||||
```
|
||||
|
||||
By default, the script will show an overview of UDID for all available simulator
|
||||
instances and asks you to pick one. You can also provide a UDID as a
|
||||
command-line parameter to launch an instance automatically:
|
||||
|
||||
```bash
|
||||
./result/bin/run-test-simulator 5C93129D-CF39-4B1A-955F-15180C3BD4B8
|
||||
```
|
||||
|
||||
You can also extend the simulator script to automatically deploy and launch an
|
||||
app in the requested simulator instance:
|
||||
|
||||
```nix
|
||||
let
|
||||
pkgs = import <nixpkgs> {};
|
||||
|
||||
xcodeenv = import ./xcodeenv {
|
||||
inherit (pkgs) stdenv;
|
||||
};
|
||||
in
|
||||
xcode.simulateApp {
|
||||
name = "simulate";
|
||||
bundleId = "mycompany.myapp";
|
||||
app = xcode.buildApp {
|
||||
# ...
|
||||
};
|
||||
|
||||
# Supports all xcodewrapper parameters as well
|
||||
xcodeBaseDir = "/Applications/Xcode.app";
|
||||
}
|
||||
```
|
||||
|
||||
By providing the result of an `xcode.buildApp {}` function and configuring the
|
||||
app bundle id, the app gets deployed automatically and started.
|
||||
@@ -1,84 +0,0 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="sec-language-java">
|
||||
<title>Java</title>
|
||||
|
||||
<para>
|
||||
Ant-based Java packages are typically built from source as follows:
|
||||
<programlisting>
|
||||
stdenv.mkDerivation {
|
||||
name = "...";
|
||||
src = fetchurl { ... };
|
||||
|
||||
buildInputs = [ jdk ant ];
|
||||
|
||||
buildPhase = "ant";
|
||||
}
|
||||
</programlisting>
|
||||
Note that <varname>jdk</varname> is an alias for the OpenJDK (self-built
|
||||
where available, or pre-built via Zulu). Platforms with OpenJDK not (yet) in
|
||||
Nixpkgs (<literal>Aarch32</literal>, <literal>Aarch64</literal>) point to the
|
||||
(unfree) <literal>oraclejdk</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
JAR files that are intended to be used by other packages should be installed
|
||||
in <filename>$out/share/java</filename>. JDKs have a stdenv setup hook that
|
||||
add any JARs in the <filename>share/java</filename> directories of the build
|
||||
inputs to the <envar>CLASSPATH</envar> environment variable. For instance, if
|
||||
the package <literal>libfoo</literal> installs a JAR named
|
||||
<filename>foo.jar</filename> in its <filename>share/java</filename>
|
||||
directory, and another package declares the attribute
|
||||
<programlisting>
|
||||
buildInputs = [ jdk libfoo ];
|
||||
</programlisting>
|
||||
then <envar>CLASSPATH</envar> will be set to
|
||||
<filename>/nix/store/...-libfoo/share/java/foo.jar</filename>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Private JARs should be installed in a location like
|
||||
<filename>$out/share/<replaceable>package-name</replaceable></filename>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If your Java package provides a program, you need to generate a wrapper
|
||||
script to run it using the OpenJRE. You can use
|
||||
<literal>makeWrapper</literal> for this:
|
||||
<programlisting>
|
||||
buildInputs = [ makeWrapper ];
|
||||
|
||||
installPhase =
|
||||
''
|
||||
mkdir -p $out/bin
|
||||
makeWrapper ${jre}/bin/java $out/bin/foo \
|
||||
--add-flags "-cp $out/share/java/foo.jar org.foo.Main"
|
||||
'';
|
||||
</programlisting>
|
||||
Note the use of <literal>jre</literal>, which is the part of the OpenJDK
|
||||
package that contains the Java Runtime Environment. By using
|
||||
<literal>${jre}/bin/java</literal> instead of
|
||||
<literal>${jdk}/bin/java</literal>, you prevent your package from depending
|
||||
on the JDK at runtime.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Note all JDKs passthru <literal>home</literal>, so if your application
|
||||
requires environment variables like <envar>JAVA_HOME</envar> being set, that
|
||||
can be done in a generic fashion with the <literal>--set</literal> argument
|
||||
of <literal>makeWrapper</literal>:
|
||||
<programlisting>
|
||||
--set JAVA_HOME ${jdk.home}
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It is possible to use a different Java compiler than <command>javac</command>
|
||||
from the OpenJDK. For instance, to use the GNU Java Compiler:
|
||||
<programlisting>
|
||||
buildInputs = [ gcj ant ];
|
||||
</programlisting>
|
||||
Here, Ant will automatically use <command>gij</command> (the GNU Java
|
||||
Runtime) instead of the OpenJRE.
|
||||
</para>
|
||||
</section>
|
||||
@@ -1,48 +0,0 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="sec-language-lua">
|
||||
<title>Lua</title>
|
||||
|
||||
<para>
|
||||
Lua packages are built by the <varname>buildLuaPackage</varname> function.
|
||||
This function is implemented in
|
||||
<link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/lua-modules/generic/default.nix">
|
||||
<filename>pkgs/development/lua-modules/generic/default.nix</filename></link>
|
||||
and works similarly to <varname>buildPerlPackage</varname>. (See
|
||||
<xref linkend="sec-language-perl"/> for details.)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Lua packages are defined in
|
||||
<link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/lua-packages.nix"><filename>pkgs/top-level/lua-packages.nix</filename></link>.
|
||||
Most of them are simple. For example:
|
||||
<programlisting>
|
||||
fileSystem = buildLuaPackage {
|
||||
name = "filesystem-1.6.2";
|
||||
src = fetchurl {
|
||||
url = "https://github.com/keplerproject/luafilesystem/archive/v1_6_2.tar.gz";
|
||||
sha256 = "1n8qdwa20ypbrny99vhkmx8q04zd2jjycdb5196xdhgvqzk10abz";
|
||||
};
|
||||
meta = {
|
||||
homepage = "https://github.com/keplerproject/luafilesystem";
|
||||
hydraPlatforms = stdenv.lib.platforms.linux;
|
||||
maintainers = with maintainers; [ flosse ];
|
||||
};
|
||||
};
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Though, more complicated package should be placed in a seperate file in
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/lua-modules"><filename>pkgs/development/lua-modules</filename></link>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Lua packages accept additional parameter <varname>disabled</varname>, which
|
||||
defines the condition of disabling package from luaPackages. For example, if
|
||||
package has <varname>disabled</varname> assigned to <literal>lua.luaversion
|
||||
!= "5.1"</literal>, it will not be included in any luaPackages except
|
||||
lua51Packages, making it only be built for lua 5.1.
|
||||
</para>
|
||||
</section>
|
||||
@@ -1,51 +0,0 @@
|
||||
Node.js packages
|
||||
================
|
||||
The `pkgs/development/node-packages` folder contains a generated collection of
|
||||
[NPM packages](https://npmjs.com/) that can be installed with the Nix package
|
||||
manager.
|
||||
|
||||
As a rule of thumb, the package set should only provide *end user* software
|
||||
packages, such as command-line utilities. Libraries should only be added to the
|
||||
package set if there is a non-NPM package that requires it.
|
||||
|
||||
When it is desired to use NPM libraries in a development project, use the
|
||||
`node2nix` generator directly on the `package.json` configuration file of the
|
||||
project.
|
||||
|
||||
The package set also provides support for multiple Node.js versions. The policy
|
||||
is that a new package should be added to the collection for the latest stable LTS
|
||||
release (which is currently 10.x), unless there is an explicit reason to support
|
||||
a different release.
|
||||
|
||||
If your package uses native addons, you need to examine what kind of native
|
||||
build system it uses. Here are some examples:
|
||||
|
||||
* `node-gyp`
|
||||
* `node-gyp-builder`
|
||||
* `node-pre-gyp`
|
||||
|
||||
After you have identified the correct system, you need to override your package
|
||||
expression while adding in build system as a build input. For example, `dat`
|
||||
requires `node-gyp-build`, so we override its expression in `default-v10.nix`:
|
||||
|
||||
```nix
|
||||
dat = nodePackages.dat.override (oldAttrs: {
|
||||
buildInputs = oldAttrs.buildInputs ++ [ nodePackages.node-gyp-build ];
|
||||
});
|
||||
```
|
||||
|
||||
To add a package from NPM to nixpkgs:
|
||||
|
||||
1. Modify `pkgs/development/node-packages/node-packages-v10.json` to add, update
|
||||
or remove package entries. (Or `pkgs/development/node-packages/node-packages-v8.json`
|
||||
for packages depending on Node.js 8.x)
|
||||
2. Run the script: `(cd pkgs/development/node-packages && ./generate.sh)`.
|
||||
3. Build your new package to test your changes:
|
||||
`cd /path/to/nixpkgs && nix-build -A nodePackages.<new-or-updated-package>`.
|
||||
To build against a specific Node.js version (e.g. 10.x):
|
||||
`nix-build -A nodePackages_10_x.<new-or-updated-package>`
|
||||
4. Add and commit all modified and generated files.
|
||||
|
||||
For more information about the generation process, consult the
|
||||
[README.md](https://github.com/svanderburg/node2nix) file of the `node2nix`
|
||||
tool.
|
||||
@@ -1,99 +0,0 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="sec-language-ocaml">
|
||||
<title>OCaml</title>
|
||||
|
||||
<para>
|
||||
OCaml libraries should be installed in
|
||||
<literal>$(out)/lib/ocaml/${ocaml.version}/site-lib/</literal>. Such
|
||||
directories are automatically added to the <literal>$OCAMLPATH</literal>
|
||||
environment variable when building another package that depends on them
|
||||
or when opening a <literal>nix-shell</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Given that most of the OCaml ecosystem is now built with dune,
|
||||
nixpkgs includes a convenience build support function called
|
||||
<literal>buildDunePackage</literal> that will build an OCaml package
|
||||
using dune, OCaml and findlib and any additional dependencies provided
|
||||
as <literal>buildInputs</literal> or <literal>propagatedBuildInputs</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Here is a simple package example. It defines an (optional) attribute
|
||||
<literal>minimumOCamlVersion</literal> that will be used to throw a
|
||||
descriptive evaluation error if building with an older OCaml is attempted.
|
||||
It uses the <literal>fetchFromGitHub</literal> fetcher to get its source.
|
||||
It sets the <literal>doCheck</literal> (optional) attribute to
|
||||
<literal>true</literal> which means that tests will be run with
|
||||
<literal>dune runtest -p angstrom</literal> after the build
|
||||
(<literal>dune build -p angstrom</literal>) is complete.
|
||||
It uses <literal>alcotest</literal> as a build input (because it is needed
|
||||
to run the tests) and <literal>bigstringaf</literal> and
|
||||
<literal>result</literal> as propagated build inputs (thus they will also
|
||||
be available to libraries depending on this library).
|
||||
The library will be installed using the <literal>angstrom.install</literal>
|
||||
file that dune generates.
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
{ stdenv, fetchFromGitHub, buildDunePackage, alcotest, result, bigstringaf }:
|
||||
|
||||
buildDunePackage rec {
|
||||
pname = "angstrom";
|
||||
version = "0.10.0";
|
||||
|
||||
minimumOCamlVersion = "4.03";
|
||||
|
||||
src = fetchFromGitHub {
|
||||
owner = "inhabitedtype";
|
||||
repo = pname;
|
||||
rev = version;
|
||||
sha256 = "0lh6024yf9ds0nh9i93r9m6p5psi8nvrqxl5x7jwl13zb0r9xfpw";
|
||||
};
|
||||
|
||||
buildInputs = [ alcotest ];
|
||||
propagatedBuildInputs = [ bigstringaf result ];
|
||||
doCheck = true;
|
||||
|
||||
meta = {
|
||||
homepage = https://github.com/inhabitedtype/angstrom;
|
||||
description = "OCaml parser combinators built for speed and memory efficiency";
|
||||
license = stdenv.lib.licenses.bsd3;
|
||||
maintainers = with stdenv.lib.maintainers; [ sternenseemann ];
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
Here is a second example, this time using a source archive generated with
|
||||
<literal>dune-release</literal>. It is a good idea to use this archive when
|
||||
it is available as it will usually contain substituted variables such as a
|
||||
<literal>%%VERSION%%</literal> field. This library does not depend
|
||||
on any other OCaml library and no tests are run after building it.
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
{ stdenv, fetchurl, buildDunePackage }:
|
||||
|
||||
buildDunePackage rec {
|
||||
pname = "wtf8";
|
||||
version = "1.0.1";
|
||||
|
||||
minimumOCamlVersion = "4.01";
|
||||
|
||||
src = fetchurl {
|
||||
url = "https://github.com/flowtype/ocaml-${pname}/releases/download/v${version}/${pname}-${version}.tbz";
|
||||
sha256 = "1msg3vycd3k8qqj61sc23qks541cxpb97vrnrvrhjnqxsqnh6ygq";
|
||||
};
|
||||
|
||||
meta = with stdenv.lib; {
|
||||
homepage = https://github.com/flowtype/ocaml-wtf8;
|
||||
description = "WTF-8 is a superset of UTF-8 that allows unpaired surrogates.";
|
||||
license = licenses.mit;
|
||||
maintainers = [ maintainers.eqyiel ];
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
</section>
|
||||
@@ -1,192 +0,0 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="sec-language-perl">
|
||||
<title>Perl</title>
|
||||
|
||||
<para>
|
||||
Nixpkgs provides a function <varname>buildPerlPackage</varname>, a generic
|
||||
package builder function for any Perl package that has a standard
|
||||
<varname>Makefile.PL</varname>. It’s implemented in
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/perl-modules/generic"><filename>pkgs/development/perl-modules/generic</filename></link>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Perl packages from CPAN are defined in
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix"><filename>pkgs/top-level/perl-packages.nix</filename></link>,
|
||||
rather than <filename>pkgs/all-packages.nix</filename>. Most Perl packages
|
||||
are so straight-forward to build that they are defined here directly, rather
|
||||
than having a separate function for each package called from
|
||||
<filename>perl-packages.nix</filename>. However, more complicated packages
|
||||
should be put in a separate file, typically in
|
||||
<filename>pkgs/development/perl-modules</filename>. Here is an example of the
|
||||
former:
|
||||
<programlisting>
|
||||
ClassC3 = buildPerlPackage rec {
|
||||
name = "Class-C3-0.21";
|
||||
src = fetchurl {
|
||||
url = "mirror://cpan/authors/id/F/FL/FLORA/${name}.tar.gz";
|
||||
sha256 = "1bl8z095y4js66pwxnm7s853pi9czala4sqc743fdlnk27kq94gz";
|
||||
};
|
||||
};
|
||||
</programlisting>
|
||||
Note the use of <literal>mirror://cpan/</literal>, and the
|
||||
<literal>${name}</literal> in the URL definition to ensure that the name
|
||||
attribute is consistent with the source that we’re actually downloading.
|
||||
Perl packages are made available in <filename>all-packages.nix</filename>
|
||||
through the variable <varname>perlPackages</varname>. For instance, if you
|
||||
have a package that needs <varname>ClassC3</varname>, you would typically
|
||||
write
|
||||
<programlisting>
|
||||
foo = import ../path/to/foo.nix {
|
||||
inherit stdenv fetchurl ...;
|
||||
inherit (perlPackages) ClassC3;
|
||||
};
|
||||
</programlisting>
|
||||
in <filename>all-packages.nix</filename>. You can test building a Perl
|
||||
package as follows:
|
||||
<screen>
|
||||
$ nix-build -A perlPackages.ClassC3
|
||||
</screen>
|
||||
<varname>buildPerlPackage</varname> adds <literal>perl-</literal> to the
|
||||
start of the name attribute, so the package above is actually called
|
||||
<literal>perl-Class-C3-0.21</literal>. So to install it, you can say:
|
||||
<screen>
|
||||
$ nix-env -i perl-Class-C3
|
||||
</screen>
|
||||
(Of course you can also install using the attribute name: <literal>nix-env -i
|
||||
-A perlPackages.ClassC3</literal>.)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
So what does <varname>buildPerlPackage</varname> do? It does the following:
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
In the configure phase, it calls <literal>perl Makefile.PL</literal> to
|
||||
generate a Makefile. You can set the variable
|
||||
<varname>makeMakerFlags</varname> to pass flags to
|
||||
<filename>Makefile.PL</filename>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
It adds the contents of the <envar>PERL5LIB</envar> environment variable
|
||||
to <literal>#! .../bin/perl</literal> line of Perl scripts as
|
||||
<literal>-I<replaceable>dir</replaceable></literal> flags. This ensures
|
||||
that a script can find its dependencies.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
In the fixup phase, it writes the propagated build inputs
|
||||
(<varname>propagatedBuildInputs</varname>) to the file
|
||||
<filename>$out/nix-support/propagated-user-env-packages</filename>.
|
||||
<command>nix-env</command> recursively installs all packages listed in
|
||||
this file when you install a package that has it. This ensures that a Perl
|
||||
package can find its dependencies.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<varname>buildPerlPackage</varname> is built on top of
|
||||
<varname>stdenv</varname>, so everything can be customised in the usual way.
|
||||
For instance, the <literal>BerkeleyDB</literal> module has a
|
||||
<varname>preConfigure</varname> hook to generate a configuration file used by
|
||||
<filename>Makefile.PL</filename>:
|
||||
<programlisting>
|
||||
{ buildPerlPackage, fetchurl, db }:
|
||||
|
||||
buildPerlPackage rec {
|
||||
name = "BerkeleyDB-0.36";
|
||||
|
||||
src = fetchurl {
|
||||
url = "mirror://cpan/authors/id/P/PM/PMQS/${name}.tar.gz";
|
||||
sha256 = "07xf50riarb60l1h6m2dqmql8q5dij619712fsgw7ach04d8g3z1";
|
||||
};
|
||||
|
||||
preConfigure = ''
|
||||
echo "LIB = ${db.out}/lib" > config.in
|
||||
echo "INCLUDE = ${db.dev}/include" >> config.in
|
||||
'';
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Dependencies on other Perl packages can be specified in the
|
||||
<varname>buildInputs</varname> and <varname>propagatedBuildInputs</varname>
|
||||
attributes. If something is exclusively a build-time dependency, use
|
||||
<varname>buildInputs</varname>; if it’s (also) a runtime dependency, use
|
||||
<varname>propagatedBuildInputs</varname>. For instance, this builds a Perl
|
||||
module that has runtime dependencies on a bunch of other modules:
|
||||
<programlisting>
|
||||
ClassC3Componentised = buildPerlPackage rec {
|
||||
name = "Class-C3-Componentised-1.0004";
|
||||
src = fetchurl {
|
||||
url = "mirror://cpan/authors/id/A/AS/ASH/${name}.tar.gz";
|
||||
sha256 = "0xql73jkcdbq4q9m0b0rnca6nrlvf5hyzy8is0crdk65bynvs8q1";
|
||||
};
|
||||
propagatedBuildInputs = [
|
||||
ClassC3 ClassInspector TestException MROCompat
|
||||
];
|
||||
};
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<section xml:id="ssec-generation-from-CPAN">
|
||||
<title>Generation from CPAN</title>
|
||||
|
||||
<para>
|
||||
Nix expressions for Perl packages can be generated (almost) automatically
|
||||
from CPAN. This is done by the program
|
||||
<command>nix-generate-from-cpan</command>, which can be installed as
|
||||
follows:
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
$ nix-env -i nix-generate-from-cpan
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
This program takes a Perl module name, looks it up on CPAN, fetches and
|
||||
unpacks the corresponding package, and prints a Nix expression on standard
|
||||
output. For example:
|
||||
<screen>
|
||||
$ nix-generate-from-cpan XML::Simple
|
||||
XMLSimple = buildPerlPackage rec {
|
||||
name = "XML-Simple-2.22";
|
||||
src = fetchurl {
|
||||
url = "mirror://cpan/authors/id/G/GR/GRANTM/${name}.tar.gz";
|
||||
sha256 = "b9450ef22ea9644ae5d6ada086dc4300fa105be050a2030ebd4efd28c198eb49";
|
||||
};
|
||||
propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ];
|
||||
meta = {
|
||||
description = "An API for simple XML files";
|
||||
license = with stdenv.lib.licenses; [ artistic1 gpl1Plus ];
|
||||
};
|
||||
};
|
||||
</screen>
|
||||
The output can be pasted into
|
||||
<filename>pkgs/top-level/perl-packages.nix</filename> or wherever else you
|
||||
need it.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="ssec-perl-cross-compilation">
|
||||
<title>Cross-compiling modules</title>
|
||||
|
||||
<para>
|
||||
Nixpkgs has experimental support for cross-compiling Perl modules. In many
|
||||
cases, it will just work out of the box, even for modules with native
|
||||
extensions. Sometimes, however, the Makefile.PL for a module may
|
||||
(indirectly) import a native module. In that case, you will need to make a
|
||||
stub for that module that will satisfy the Makefile.PL and install it into
|
||||
<filename>lib/perl5/site_perl/cross_perl/${perl.version}</filename>. See the
|
||||
<varname>postInstall</varname> for <varname>DBI</varname> for an example.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,74 +0,0 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="sec-language-qt">
|
||||
<title>Qt</title>
|
||||
|
||||
<para>
|
||||
Qt is a comprehensive desktop and mobile application development toolkit for
|
||||
C++. Legacy support is available for Qt 3 and Qt 4, but all current
|
||||
development uses Qt 5. The Qt 5 packages in Nixpkgs are updated frequently to
|
||||
take advantage of new features, but older versions are typically retained
|
||||
until their support window ends. The most important consideration in
|
||||
packaging Qt-based software is ensuring that each package and all its
|
||||
dependencies use the same version of Qt 5; this consideration motivates most
|
||||
of the tools described below.
|
||||
</para>
|
||||
|
||||
<section xml:id="ssec-qt-libraries">
|
||||
<title>Packaging Libraries for Nixpkgs</title>
|
||||
|
||||
<para>
|
||||
Whenever possible, libraries that use Qt 5 should be built with each
|
||||
available version. Packages providing libraries should be added to the
|
||||
top-level function <varname>mkLibsForQt5</varname>, which is used to build a
|
||||
set of libraries for every Qt 5 version. A special
|
||||
<varname>callPackage</varname> function is used in this scope to ensure that
|
||||
the entire dependency tree uses the same Qt 5 version. Import dependencies
|
||||
unqualified, i.e., <literal>qtbase</literal> not
|
||||
<literal>qt5.qtbase</literal>. <emphasis>Do not</emphasis> import a package
|
||||
set such as <literal>qt5</literal> or <literal>libsForQt5</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If a library does not support a particular version of Qt 5, it is best to
|
||||
mark it as broken by setting its <literal>meta.broken</literal> attribute. A
|
||||
package may be marked broken for certain versions by testing the
|
||||
<literal>qtbase.version</literal> attribute, which will always give the
|
||||
current Qt 5 version.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="ssec-qt-applications">
|
||||
<title>Packaging Applications for Nixpkgs</title>
|
||||
|
||||
<para>
|
||||
Call your application expression using
|
||||
<literal>libsForQt5.callPackage</literal> instead of
|
||||
<literal>callPackage</literal>. Import dependencies unqualified, i.e.,
|
||||
<literal>qtbase</literal> not <literal>qt5.qtbase</literal>. <emphasis>Do
|
||||
not</emphasis> import a package set such as <literal>qt5</literal> or
|
||||
<literal>libsForQt5</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Qt 5 maintains strict backward compatibility, so it is generally best to
|
||||
build an application package against the latest version using the
|
||||
<varname>libsForQt5</varname> library set. In case a package does not build
|
||||
with the latest Qt version, it is possible to pick a set pinned to a
|
||||
particular version, e.g. <varname>libsForQt55</varname> for Qt 5.5, if that
|
||||
is the latest version the package supports. If a package must be pinned to
|
||||
an older Qt version, be sure to file a bug upstream; because Qt is strictly
|
||||
backwards-compatible, any incompatibility is by definition a bug in the
|
||||
application.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When testing applications in Nixpkgs, it is a common practice to build the
|
||||
package with <literal>nix-build</literal> and run it using the created
|
||||
symbolic link. This will not work with Qt applications, however, because
|
||||
they have many hard runtime requirements that can only be guaranteed if the
|
||||
package is actually installed. To test a Qt application, install it with
|
||||
<literal>nix-env</literal> or run it inside <literal>nix-shell</literal>.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
@@ -1,120 +0,0 @@
|
||||
R packages
|
||||
==========
|
||||
|
||||
## Installation
|
||||
|
||||
Define an environment for R that contains all the libraries that you'd like to
|
||||
use by adding the following snippet to your $HOME/.config/nixpkgs/config.nix file:
|
||||
|
||||
```nix
|
||||
{
|
||||
packageOverrides = super: let self = super.pkgs; in
|
||||
{
|
||||
|
||||
rEnv = super.rWrapper.override {
|
||||
packages = with self.rPackages; [
|
||||
devtools
|
||||
ggplot2
|
||||
reshape2
|
||||
yaml
|
||||
optparse
|
||||
];
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Then you can use `nix-env -f "<nixpkgs>" -iA rEnv` to install it into your user
|
||||
profile. The set of available libraries can be discovered by running the
|
||||
command `nix-env -f "<nixpkgs>" -qaP -A rPackages`. The first column from that
|
||||
output is the name that has to be passed to rWrapper in the code snipped above.
|
||||
|
||||
However, if you'd like to add a file to your project source to make the
|
||||
environment available for other contributors, you can create a `default.nix`
|
||||
file like so:
|
||||
```nix
|
||||
let
|
||||
pkgs = import <nixpkgs> {};
|
||||
stdenv = pkgs.stdenv;
|
||||
in with pkgs; {
|
||||
myProject = stdenv.mkDerivation {
|
||||
name = "myProject";
|
||||
version = "1";
|
||||
src = if pkgs.lib.inNixShell then null else nix;
|
||||
|
||||
buildInputs = with rPackages; [
|
||||
R
|
||||
ggplot2
|
||||
knitr
|
||||
];
|
||||
};
|
||||
}
|
||||
```
|
||||
and then run `nix-shell .` to be dropped into a shell with those packages
|
||||
available.
|
||||
|
||||
## RStudio
|
||||
|
||||
RStudio uses a standard set of packages and ignores any custom R
|
||||
environments or installed packages you may have. To create a custom
|
||||
environment, see `rstudioWrapper`, which functions similarly to
|
||||
`rWrapper`:
|
||||
|
||||
```nix
|
||||
{
|
||||
packageOverrides = super: let self = super.pkgs; in
|
||||
{
|
||||
|
||||
rstudioEnv = super.rstudioWrapper.override {
|
||||
packages = with self.rPackages; [
|
||||
dplyr
|
||||
ggplot2
|
||||
reshape2
|
||||
];
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Then like above, `nix-env -f "<nixpkgs>" -iA rstudioEnv` will install
|
||||
this into your user profile.
|
||||
|
||||
Alternatively, you can create a self-contained `shell.nix` without the need to
|
||||
modify any configuration files:
|
||||
|
||||
```nix
|
||||
{ pkgs ? import <nixpkgs> {}
|
||||
}:
|
||||
|
||||
pkgs.rstudioWrapper.override {
|
||||
packages = with pkgs.rPackages; [ dplyr ggplot2 reshape2 ];
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
Executing `nix-shell` will then drop you into an environment equivalent to the
|
||||
one above. If you need additional packages just add them to the list and
|
||||
re-enter the shell.
|
||||
|
||||
## Updating the package set
|
||||
|
||||
```bash
|
||||
nix-shell generate-shell.nix
|
||||
|
||||
Rscript generate-r-packages.R cran > cran-packages.nix.new
|
||||
mv cran-packages.nix.new cran-packages.nix
|
||||
|
||||
Rscript generate-r-packages.R bioc > bioc-packages.nix.new
|
||||
mv bioc-packages.nix.new bioc-packages.nix
|
||||
```
|
||||
|
||||
`generate-r-packages.R <repo>` reads `<repo>-packages.nix`, therefor the renaming.
|
||||
|
||||
|
||||
## Testing if the Nix-expression could be evaluated
|
||||
|
||||
```bash
|
||||
nix-build test-evaluation.nix --dry-run
|
||||
```
|
||||
|
||||
If this exits fine, the expression is ok. If not, you have to edit `default.nix`
|
||||
@@ -1,135 +0,0 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="sec-language-ruby">
|
||||
<title>Ruby</title>
|
||||
|
||||
<para>
|
||||
There currently is support to bundle applications that are packaged as Ruby
|
||||
gems. The utility "bundix" allows you to write a
|
||||
<filename>Gemfile</filename>, let bundler create a
|
||||
<filename>Gemfile.lock</filename>, and then convert this into a nix
|
||||
expression that contains all Gem dependencies automatically.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For example, to package sensu, we did:
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
<![CDATA[$ cd pkgs/servers/monitoring
|
||||
$ mkdir sensu
|
||||
$ cd sensu
|
||||
$ cat > Gemfile
|
||||
source 'https://rubygems.org'
|
||||
gem 'sensu'
|
||||
$ $(nix-build '<nixpkgs>' -A bundix --no-out-link)/bin/bundix --magic
|
||||
$ cat > default.nix
|
||||
{ lib, bundlerEnv, ruby }:
|
||||
|
||||
bundlerEnv rec {
|
||||
name = "sensu-${version}";
|
||||
|
||||
version = (import gemset).sensu.version;
|
||||
inherit ruby;
|
||||
# expects Gemfile, Gemfile.lock and gemset.nix in the same directory
|
||||
gemdir = ./.;
|
||||
|
||||
meta = with lib; {
|
||||
description = "A monitoring framework that aims to be simple, malleable, and scalable";
|
||||
homepage = http://sensuapp.org/;
|
||||
license = with licenses; mit;
|
||||
maintainers = with maintainers; [ theuni ];
|
||||
platforms = platforms.unix;
|
||||
};
|
||||
}]]>
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
Please check in the <filename>Gemfile</filename>,
|
||||
<filename>Gemfile.lock</filename> and the <filename>gemset.nix</filename> so
|
||||
future updates can be run easily.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Updating Ruby packages can then be done like this:
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
<![CDATA[$ cd pkgs/servers/monitoring/sensu
|
||||
$ nix-shell -p bundler --run 'bundle lock --update'
|
||||
$ nix-shell -p bundix --run 'bundix'
|
||||
]]>
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
For tools written in Ruby - i.e. where the desire is to install a package and
|
||||
then execute e.g. <command>rake</command> at the command line, there is an
|
||||
alternative builder called <literal>bundlerApp</literal>. Set up the
|
||||
<filename>gemset.nix</filename> the same way, and then, for example:
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
<![CDATA[{ lib, bundlerApp }:
|
||||
|
||||
bundlerApp {
|
||||
pname = "corundum";
|
||||
gemdir = ./.;
|
||||
exes = [ "corundum-skel" ];
|
||||
|
||||
meta = with lib; {
|
||||
description = "Tool and libraries for maintaining Ruby gems.";
|
||||
homepage = https://github.com/nyarly/corundum;
|
||||
license = licenses.mit;
|
||||
maintainers = [ maintainers.nyarly ];
|
||||
platforms = platforms.unix;
|
||||
};
|
||||
}]]>
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
The chief advantage of <literal>bundlerApp</literal> over
|
||||
<literal>bundlerEnv</literal> is the executables introduced in the
|
||||
environment are precisely those selected in the <literal>exes</literal> list,
|
||||
as opposed to <literal>bundlerEnv</literal> which adds all the executables
|
||||
made available by gems in the gemset, which can mean e.g.
|
||||
<command>rspec</command> or <command>rake</command> in unpredictable versions
|
||||
available from various packages.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Resulting derivations for both builders also have two helpful attributes,
|
||||
<literal>env</literal> and <literal>wrappedRuby</literal>. The first one
|
||||
allows one to quickly drop into <command>nix-shell</command> with the
|
||||
specified environment present. E.g. <command>nix-shell -A sensu.env</command>
|
||||
would give you an environment with Ruby preset so it has all the libraries
|
||||
necessary for <literal>sensu</literal> in its paths. The second one can be
|
||||
used to make derivations from custom Ruby scripts which have
|
||||
<filename>Gemfile</filename>s with their dependencies specified. It is a
|
||||
derivation with <command>ruby</command> wrapped so it can find all the needed
|
||||
dependencies. For example, to make a derivation <literal>my-script</literal>
|
||||
for a <filename>my-script.rb</filename> (which should be placed in
|
||||
<filename>bin</filename>) you should run <command>bundix</command> as
|
||||
specified above and then use <literal>bundlerEnv</literal> like this:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
<![CDATA[let env = bundlerEnv {
|
||||
name = "my-script-env";
|
||||
|
||||
inherit ruby;
|
||||
gemfile = ./Gemfile;
|
||||
lockfile = ./Gemfile.lock;
|
||||
gemset = ./gemset.nix;
|
||||
};
|
||||
|
||||
in stdenv.mkDerivation {
|
||||
name = "my-script";
|
||||
buildInputs = [ env.wrappedRuby ];
|
||||
script = ./my-script.rb;
|
||||
buildCommand = ''
|
||||
install -D -m755 $script $out/bin/my-script
|
||||
patchShebangs $out/bin/my-script
|
||||
'';
|
||||
}]]>
|
||||
</programlisting>
|
||||
</section>
|
||||
@@ -1,399 +0,0 @@
|
||||
---
|
||||
title: Rust
|
||||
author: Matthias Beyer
|
||||
date: 2017-03-05
|
||||
---
|
||||
|
||||
# User's Guide to the Rust Infrastructure
|
||||
|
||||
To install the rust compiler and cargo put
|
||||
|
||||
```
|
||||
rustc
|
||||
cargo
|
||||
```
|
||||
|
||||
into the `environment.systemPackages` or bring them into
|
||||
scope with `nix-shell -p rustc cargo`.
|
||||
|
||||
> If you are using NixOS and you want to use rust without a nix expression you
|
||||
> probably want to add the following in your `configuration.nix` to build
|
||||
> crates with C dependencies.
|
||||
>
|
||||
> environment.systemPackages = [binutils gcc gnumake openssl pkgconfig]
|
||||
|
||||
For daily builds (beta and nightly) use either rustup from
|
||||
nixpkgs or use the [Rust nightlies
|
||||
overlay](#using-the-rust-nightlies-overlay).
|
||||
|
||||
## Compiling Rust applications with Cargo
|
||||
|
||||
Rust applications are packaged by using the `buildRustPackage` helper from `rustPlatform`:
|
||||
|
||||
```
|
||||
rustPlatform.buildRustPackage rec {
|
||||
name = "ripgrep-${version}";
|
||||
version = "0.4.0";
|
||||
|
||||
src = fetchFromGitHub {
|
||||
owner = "BurntSushi";
|
||||
repo = "ripgrep";
|
||||
rev = "${version}";
|
||||
sha256 = "0y5d1n6hkw85jb3rblcxqas2fp82h3nghssa4xqrhqnz25l799pj";
|
||||
};
|
||||
|
||||
cargoSha256 = "0q68qyl2h6i0qsz82z840myxlnjay8p1w5z7hfyr8fqp7wgwa9cx";
|
||||
|
||||
meta = with stdenv.lib; {
|
||||
description = "A fast line-oriented regex search tool, similar to ag and ack";
|
||||
homepage = https://github.com/BurntSushi/ripgrep;
|
||||
license = licenses.unlicense;
|
||||
maintainers = [ maintainers.tailhook ];
|
||||
platforms = platforms.all;
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
`buildRustPackage` requires a `cargoSha256` attribute which is computed over
|
||||
all crate sources of this package. Currently it is obtained by inserting a
|
||||
fake checksum into the expression and building the package once. The correct
|
||||
checksum can be then take from the failed build.
|
||||
|
||||
When the `Cargo.lock`, provided by upstream, is not in sync with the
|
||||
`Cargo.toml`, it is possible to use `cargoPatches` to update it. All patches
|
||||
added in `cargoPatches` will also be prepended to the patches in `patches` at
|
||||
build-time.
|
||||
|
||||
## Compiling Rust crates using Nix instead of Cargo
|
||||
|
||||
### Simple operation
|
||||
|
||||
When run, `cargo build` produces a file called `Cargo.lock`,
|
||||
containing pinned versions of all dependencies. Nixpkgs contains a
|
||||
tool called `carnix` (`nix-env -iA nixos.carnix`), which can be used
|
||||
to turn a `Cargo.lock` into a Nix expression.
|
||||
|
||||
That Nix expression calls `rustc` directly (hence bypassing Cargo),
|
||||
and can be used to compile a crate and all its dependencies. Here is
|
||||
an example for a minimal `hello` crate:
|
||||
|
||||
|
||||
$ cargo new hello
|
||||
$ cd hello
|
||||
$ cargo build
|
||||
Compiling hello v0.1.0 (file:///tmp/hello)
|
||||
Finished dev [unoptimized + debuginfo] target(s) in 0.20 secs
|
||||
$ carnix -o hello.nix --src ./. Cargo.lock --standalone
|
||||
$ nix-build hello.nix -A hello_0_1_0
|
||||
|
||||
Now, the file produced by the call to `carnix`, called `hello.nix`, looks like:
|
||||
|
||||
```
|
||||
# Generated by carnix 0.6.5: carnix -o hello.nix --src ./. Cargo.lock --standalone
|
||||
{ lib, stdenv, buildRustCrate, fetchgit }:
|
||||
let kernel = stdenv.buildPlatform.parsed.kernel.name;
|
||||
# ... (content skipped)
|
||||
in
|
||||
rec {
|
||||
hello = f: hello_0_1_0 { features = hello_0_1_0_features { hello_0_1_0 = f; }; };
|
||||
hello_0_1_0_ = { dependencies?[], buildDependencies?[], features?[] }: buildRustCrate {
|
||||
crateName = "hello";
|
||||
version = "0.1.0";
|
||||
authors = [ "pe@pijul.org <pe@pijul.org>" ];
|
||||
src = ./.;
|
||||
inherit dependencies buildDependencies features;
|
||||
};
|
||||
hello_0_1_0 = { features?(hello_0_1_0_features {}) }: hello_0_1_0_ {};
|
||||
hello_0_1_0_features = f: updateFeatures f (rec {
|
||||
hello_0_1_0.default = (f.hello_0_1_0.default or true);
|
||||
}) [ ];
|
||||
}
|
||||
```
|
||||
|
||||
In particular, note that the argument given as `--src` is copied
|
||||
verbatim to the source. If we look at a more complicated
|
||||
dependencies, for instance by adding a single line `libc="*"` to our
|
||||
`Cargo.toml`, we first need to run `cargo build` to update the
|
||||
`Cargo.lock`. Then, `carnix` needs to be run again, and produces the
|
||||
following nix file:
|
||||
|
||||
```
|
||||
# Generated by carnix 0.6.5: carnix -o hello.nix --src ./. Cargo.lock --standalone
|
||||
{ lib, stdenv, buildRustCrate, fetchgit }:
|
||||
let kernel = stdenv.buildPlatform.parsed.kernel.name;
|
||||
# ... (content skipped)
|
||||
in
|
||||
rec {
|
||||
hello = f: hello_0_1_0 { features = hello_0_1_0_features { hello_0_1_0 = f; }; };
|
||||
hello_0_1_0_ = { dependencies?[], buildDependencies?[], features?[] }: buildRustCrate {
|
||||
crateName = "hello";
|
||||
version = "0.1.0";
|
||||
authors = [ "pe@pijul.org <pe@pijul.org>" ];
|
||||
src = ./.;
|
||||
inherit dependencies buildDependencies features;
|
||||
};
|
||||
libc_0_2_36_ = { dependencies?[], buildDependencies?[], features?[] }: buildRustCrate {
|
||||
crateName = "libc";
|
||||
version = "0.2.36";
|
||||
authors = [ "The Rust Project Developers" ];
|
||||
sha256 = "01633h4yfqm0s302fm0dlba469bx8y6cs4nqc8bqrmjqxfxn515l";
|
||||
inherit dependencies buildDependencies features;
|
||||
};
|
||||
hello_0_1_0 = { features?(hello_0_1_0_features {}) }: hello_0_1_0_ {
|
||||
dependencies = mapFeatures features ([ libc_0_2_36 ]);
|
||||
};
|
||||
hello_0_1_0_features = f: updateFeatures f (rec {
|
||||
hello_0_1_0.default = (f.hello_0_1_0.default or true);
|
||||
libc_0_2_36.default = true;
|
||||
}) [ libc_0_2_36_features ];
|
||||
libc_0_2_36 = { features?(libc_0_2_36_features {}) }: libc_0_2_36_ {
|
||||
features = mkFeatures (features.libc_0_2_36 or {});
|
||||
};
|
||||
libc_0_2_36_features = f: updateFeatures f (rec {
|
||||
libc_0_2_36.default = (f.libc_0_2_36.default or true);
|
||||
libc_0_2_36.use_std =
|
||||
(f.libc_0_2_36.use_std or false) ||
|
||||
(f.libc_0_2_36.default or false) ||
|
||||
(libc_0_2_36.default or false);
|
||||
}) [];
|
||||
}
|
||||
```
|
||||
|
||||
Here, the `libc` crate has no `src` attribute, so `buildRustCrate`
|
||||
will fetch it from [crates.io](https://crates.io). A `sha256`
|
||||
attribute is still needed for Nix purity.
|
||||
|
||||
### Handling external dependencies
|
||||
|
||||
Some crates require external libraries. For crates from
|
||||
[crates.io](https://crates.io), such libraries can be specified in
|
||||
`defaultCrateOverrides` package in nixpkgs itself.
|
||||
|
||||
Starting from that file, one can add more overrides, to add features
|
||||
or build inputs by overriding the hello crate in a seperate file.
|
||||
|
||||
```
|
||||
with import <nixpkgs> {};
|
||||
((import ./hello.nix).hello {}).override {
|
||||
crateOverrides = defaultCrateOverrides // {
|
||||
hello = attrs: { buildInputs = [ openssl ]; };
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Here, `crateOverrides` is expected to be a attribute set, where the
|
||||
key is the crate name without version number and the value a function.
|
||||
The function gets all attributes passed to `buildRustCrate` as first
|
||||
argument and returns a set that contains all attribute that should be
|
||||
overwritten.
|
||||
|
||||
For more complicated cases, such as when parts of the crate's
|
||||
derivation depend on the the crate's version, the `attrs` argument of
|
||||
the override above can be read, as in the following example, which
|
||||
patches the derivation:
|
||||
|
||||
```
|
||||
with import <nixpkgs> {};
|
||||
((import ./hello.nix).hello {}).override {
|
||||
crateOverrides = defaultCrateOverrides // {
|
||||
hello = attrs: lib.optionalAttrs (lib.versionAtLeast attrs.version "1.0") {
|
||||
postPatch = ''
|
||||
substituteInPlace lib/zoneinfo.rs \
|
||||
--replace "/usr/share/zoneinfo" "${tzdata}/share/zoneinfo"
|
||||
'';
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Another situation is when we want to override a nested
|
||||
dependency. This actually works in the exact same way, since the
|
||||
`crateOverrides` parameter is forwarded to the crate's
|
||||
dependencies. For instance, to override the build inputs for crate
|
||||
`libc` in the example above, where `libc` is a dependency of the main
|
||||
crate, we could do:
|
||||
|
||||
```
|
||||
with import <nixpkgs> {};
|
||||
((import hello.nix).hello {}).override {
|
||||
crateOverrides = defaultCrateOverrides // {
|
||||
libc = attrs: { buildInputs = []; };
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
### Options and phases configuration
|
||||
|
||||
Actually, the overrides introduced in the previous section are more
|
||||
general. A number of other parameters can be overridden:
|
||||
|
||||
- The version of rustc used to compile the crate:
|
||||
|
||||
```
|
||||
(hello {}).override { rust = pkgs.rust; };
|
||||
```
|
||||
|
||||
- Whether to build in release mode or debug mode (release mode by
|
||||
default):
|
||||
|
||||
```
|
||||
(hello {}).override { release = false; };
|
||||
```
|
||||
|
||||
- Whether to print the commands sent to rustc when building
|
||||
(equivalent to `--verbose` in cargo:
|
||||
|
||||
```
|
||||
(hello {}).override { verbose = false; };
|
||||
```
|
||||
|
||||
- Extra arguments to be passed to `rustc`:
|
||||
|
||||
```
|
||||
(hello {}).override { extraRustcOpts = "-Z debuginfo=2"; };
|
||||
```
|
||||
|
||||
- Phases, just like in any other derivation, can be specified using
|
||||
the following attributes: `preUnpack`, `postUnpack`, `prePatch`,
|
||||
`patches`, `postPatch`, `preConfigure` (in the case of a Rust crate,
|
||||
this is run before calling the "build" script), `postConfigure`
|
||||
(after the "build" script),`preBuild`, `postBuild`, `preInstall` and
|
||||
`postInstall`. As an example, here is how to create a new module
|
||||
before running the build script:
|
||||
|
||||
```
|
||||
(hello {}).override {
|
||||
preConfigure = ''
|
||||
echo "pub const PATH=\"${hi.out}\";" >> src/path.rs"
|
||||
'';
|
||||
};
|
||||
```
|
||||
|
||||
### Features
|
||||
|
||||
One can also supply features switches. For example, if we want to
|
||||
compile `diesel_cli` only with the `postgres` feature, and no default
|
||||
features, we would write:
|
||||
|
||||
```
|
||||
(callPackage ./diesel.nix {}).diesel {
|
||||
default = false;
|
||||
postgres = true;
|
||||
}
|
||||
```
|
||||
|
||||
Where `diesel.nix` is the file generated by Carnix, as explained above.
|
||||
|
||||
|
||||
## Setting Up `nix-shell`
|
||||
Oftentimes you want to develop code from within `nix-shell`. Unfortunately
|
||||
`buildRustCrate` does not support common `nix-shell` operations directly
|
||||
(see [this issue](https://github.com/NixOS/nixpkgs/issues/37945))
|
||||
so we will use `stdenv.mkDerivation` instead.
|
||||
|
||||
Using the example `hello` project above, we want to do the following:
|
||||
- Have access to `cargo` and `rustc`
|
||||
- Have the `openssl` library available to a crate through it's _normal_
|
||||
compilation mechanism (`pkg-config`).
|
||||
|
||||
A typical `shell.nix` might look like:
|
||||
|
||||
```
|
||||
with import <nixpkgs> {};
|
||||
|
||||
stdenv.mkDerivation {
|
||||
name = "rust-env";
|
||||
nativeBuildInputs = [
|
||||
rustc cargo
|
||||
|
||||
# Example Build-time Additional Dependencies
|
||||
pkgconfig
|
||||
];
|
||||
buildInputs = [
|
||||
# Example Run-time Additional Dependencies
|
||||
openssl
|
||||
];
|
||||
|
||||
# Set Environment Variables
|
||||
RUST_BACKTRACE = 1;
|
||||
}
|
||||
```
|
||||
|
||||
You should now be able to run the following:
|
||||
```
|
||||
$ nix-shell --pure
|
||||
$ cargo build
|
||||
$ cargo test
|
||||
```
|
||||
|
||||
### Controlling Rust Version Inside `nix-shell`
|
||||
To control your rust version (i.e. use nightly) from within `shell.nix` (or
|
||||
other nix expressions) you can use the following `shell.nix`
|
||||
|
||||
```
|
||||
# Latest Nightly
|
||||
with import <nixpkgs> {};
|
||||
let src = fetchFromGitHub {
|
||||
owner = "mozilla";
|
||||
repo = "nixpkgs-mozilla";
|
||||
# commit from: 2018-03-27
|
||||
rev = "2945b0b6b2fd19e7d23bac695afd65e320efcebe";
|
||||
sha256 = "034m1dryrzh2lmjvk3c0krgip652dql46w5yfwpvh7gavd3iypyw";
|
||||
};
|
||||
in
|
||||
with import "${src.out}/rust-overlay.nix" pkgs pkgs;
|
||||
stdenv.mkDerivation {
|
||||
name = "rust-env";
|
||||
buildInputs = [
|
||||
# Note: to use use stable, just replace `nightly` with `stable`
|
||||
latest.rustChannels.nightly.rust
|
||||
|
||||
# Add some extra dependencies from `pkgs`
|
||||
pkgconfig openssl
|
||||
];
|
||||
|
||||
# Set Environment Variables
|
||||
RUST_BACKTRACE = 1;
|
||||
}
|
||||
```
|
||||
|
||||
Now run:
|
||||
```
|
||||
$ rustc --version
|
||||
rustc 1.26.0-nightly (188e693b3 2018-03-26)
|
||||
```
|
||||
|
||||
To see that you are using nightly.
|
||||
|
||||
|
||||
## Using the Rust nightlies overlay
|
||||
|
||||
Mozilla provides an overlay for nixpkgs to bring a nightly version of Rust into scope.
|
||||
This overlay can _also_ be used to install recent unstable or stable versions
|
||||
of Rust, if desired.
|
||||
|
||||
To use this overlay, clone
|
||||
[nixpkgs-mozilla](https://github.com/mozilla/nixpkgs-mozilla),
|
||||
and create a symbolic link to the file
|
||||
[rust-overlay.nix](https://github.com/mozilla/nixpkgs-mozilla/blob/master/rust-overlay.nix)
|
||||
in the `~/.config/nixpkgs/overlays` directory.
|
||||
|
||||
$ git clone https://github.com/mozilla/nixpkgs-mozilla.git
|
||||
$ mkdir -p ~/.config/nixpkgs/overlays
|
||||
$ ln -s $(pwd)/nixpkgs-mozilla/rust-overlay.nix ~/.config/nixpkgs/overlays/rust-overlay.nix
|
||||
|
||||
The latest version can be installed with the following command:
|
||||
|
||||
$ nix-env -Ai nixos.latest.rustChannels.stable.rust
|
||||
|
||||
Or using the attribute with nix-shell:
|
||||
|
||||
$ nix-shell -p nixos.latest.rustChannels.stable.rust
|
||||
|
||||
To install the beta or nightly channel, "stable" should be substituted by
|
||||
"nightly" or "beta", or
|
||||
use the function provided by this overlay to pull a version based on a
|
||||
build date.
|
||||
|
||||
The overlay automatically updates itself as it uses the same source as
|
||||
[rustup](https://www.rustup.rs/).
|
||||
@@ -1,99 +0,0 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="sec-language-texlive">
|
||||
<title>TeX Live</title>
|
||||
|
||||
<para>
|
||||
Since release 15.09 there is a new TeX Live packaging that lives entirely
|
||||
under attribute <varname>texlive</varname>.
|
||||
</para>
|
||||
|
||||
<section xml:id="sec-language-texlive-users-guide">
|
||||
<title>User's guide</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
For basic usage just pull <varname>texlive.combined.scheme-basic</varname>
|
||||
for an environment with basic LaTeX support.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
It typically won't work to use separately installed packages together.
|
||||
Instead, you can build a custom set of packages like this:
|
||||
<programlisting>
|
||||
texlive.combine {
|
||||
inherit (texlive) scheme-small collection-langkorean algorithms cm-super;
|
||||
}
|
||||
</programlisting>
|
||||
There are all the schemes, collections and a few thousand packages, as
|
||||
defined upstream (perhaps with tiny differences).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
By default you only get executables and files needed during runtime, and a
|
||||
little documentation for the core packages. To change that, you need to
|
||||
add <varname>pkgFilter</varname> function to <varname>combine</varname>.
|
||||
<programlisting>
|
||||
texlive.combine {
|
||||
# inherit (texlive) whatever-you-want;
|
||||
pkgFilter = pkg:
|
||||
pkg.tlType == "run" || pkg.tlType == "bin" || pkg.pname == "cm-super";
|
||||
# elem tlType [ "run" "bin" "doc" "source" ]
|
||||
# there are also other attributes: version, name
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
You can list packages e.g. by <command>nix repl</command>.
|
||||
<programlisting><![CDATA[
|
||||
$ nix repl
|
||||
nix-repl> :l <nixpkgs>
|
||||
nix-repl> texlive.collection-<TAB>
|
||||
]]></programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Note that the wrapper assumes that the result has a chance to be useful.
|
||||
For example, the core executables should be present, as well as some core
|
||||
data files. The supported way of ensuring this is by including some
|
||||
scheme, for example <varname>scheme-basic</varname>, into the combination.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-language-texlive-known-problems">
|
||||
<title>Known problems</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Some tools are still missing, e.g. luajittex;
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
some apps aren't packaged/tested yet (asymptote, biber, etc.);
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
feature/bug: when a package is rejected by <varname>pkgFilter</varname>,
|
||||
its dependencies are still propagated;
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
in case of any bugs or feature requests, file a github issue or better a
|
||||
pull request and /cc @vcunat.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</section>
|
||||
@@ -1,115 +0,0 @@
|
||||
---
|
||||
title: Titanium
|
||||
author: Sander van der Burg
|
||||
date: 2018-11-18
|
||||
---
|
||||
# Titanium
|
||||
|
||||
The Nixpkgs repository contains facilities to deploy a variety of versions of
|
||||
the [Titanium SDK](https://www.appcelerator.com) versions, a cross-platform
|
||||
mobile app development framework using JavaScript as an implementation language,
|
||||
and includes a function abstraction making it possible to build Titanium
|
||||
applications for Android and iOS devices from source code.
|
||||
|
||||
Not all Titanium features supported -- currently, it can only be used to build
|
||||
Android and iOS apps.
|
||||
|
||||
Building a Titanium app
|
||||
-----------------------
|
||||
We can build a Titanium app from source for Android or iOS and for debugging or
|
||||
release purposes by invoking the `titaniumenv.buildApp {}` function:
|
||||
|
||||
```nix
|
||||
titaniumenv.buildApp {
|
||||
name = "myapp";
|
||||
src = ./myappsource;
|
||||
|
||||
preBuild = "";
|
||||
target = "android"; # or 'iphone'
|
||||
tiVersion = "7.1.0.GA";
|
||||
release = true;
|
||||
|
||||
androidsdkArgs = {
|
||||
platformVersions = [ "25" "26" ];
|
||||
};
|
||||
androidKeyStore = ./keystore;
|
||||
androidKeyAlias = "myfirstapp";
|
||||
androidKeyStorePassword = "secret";
|
||||
|
||||
xcodeBaseDir = "/Applications/Xcode.app";
|
||||
xcodewrapperArgs = {
|
||||
version = "9.3";
|
||||
};
|
||||
iosMobileProvisioningProfile = ./myprovisioning.profile;
|
||||
iosCertificateName = "My Company";
|
||||
iosCertificate = ./mycertificate.p12;
|
||||
iosCertificatePassword = "secret";
|
||||
iosVersion = "11.3";
|
||||
iosBuildStore = false;
|
||||
|
||||
enableWirelessDistribution = true;
|
||||
installURL = "/installipa.php";
|
||||
}
|
||||
```
|
||||
|
||||
The `titaniumenv.buildApp {}` function takes the following parameters:
|
||||
|
||||
* The `name` parameter refers to the name in the Nix store.
|
||||
* The `src` parameter refers to the source code location of the app that needs
|
||||
to be built.
|
||||
* `preRebuild` contains optional build instructions that are carried out before
|
||||
the build starts.
|
||||
* `target` indicates for which device the app must be built. Currently only
|
||||
'android' and 'iphone' (for iOS) are supported.
|
||||
* `tiVersion` can be used to optionally override the requested Titanium version
|
||||
in `tiapp.xml`. If not specified, it will use the version in `tiapp.xml`.
|
||||
* `release` should be set to true when building an app for submission to the
|
||||
Google Playstore or Apple Appstore. Otherwise, it should be false.
|
||||
|
||||
When the `target` has been set to `android`, we can configure the following
|
||||
parameters:
|
||||
|
||||
* The `androidSdkArgs` parameter refers to an attribute set that propagates all
|
||||
parameters to the `androidenv.composeAndroidPackages {}` function. This can
|
||||
be used to install all relevant Android plugins that may be needed to perform
|
||||
the Android build. If no parameters are given, it will deploy the platform
|
||||
SDKs for API-levels 25 and 26 by default.
|
||||
|
||||
When the `release` parameter has been set to true, you need to provide
|
||||
parameters to sign the app:
|
||||
|
||||
* `androidKeyStore` is the path to the keystore file
|
||||
* `androidKeyAlias` is the key alias
|
||||
* `androidKeyStorePassword` refers to the password to open the keystore file.
|
||||
|
||||
When the `target` has been set to `iphone`, we can configure the following
|
||||
parameters:
|
||||
|
||||
* The `xcodeBaseDir` parameter refers to the location where Xcode has been
|
||||
installed. When none value is given, the above value is the default.
|
||||
* The `xcodewrapperArgs` parameter passes arbitrary parameters to the
|
||||
`xcodeenv.composeXcodeWrapper {}` function. This can, for example, be used
|
||||
to adjust the default version of Xcode.
|
||||
|
||||
When `release` has been set to true, you also need to provide the following
|
||||
parameters:
|
||||
|
||||
* `iosMobileProvisioningProfile` refers to a mobile provisioning profile needed
|
||||
for signing.
|
||||
* `iosCertificateName` refers to the company name in the P12 certificate.
|
||||
* `iosCertificate` refers to the path to the P12 file.
|
||||
* `iosCertificatePassword` contains the password to open the P12 file.
|
||||
* `iosVersion` refers to the iOS SDK version to use. It defaults to the latest
|
||||
version.
|
||||
* `iosBuildStore` should be set to `true` when building for the Apple Appstore
|
||||
submission. For enterprise or ad-hoc builds it should be set to `false`.
|
||||
|
||||
When `enableWirelessDistribution` has been enabled, you must also provide the
|
||||
path of the PHP script (`installURL`) (that is included with the iOS build
|
||||
environment) to enable wireless ad-hoc installations.
|
||||
|
||||
Emulating or simulating the app
|
||||
-------------------------------
|
||||
It is also possible to simulate the correspond iOS simulator build by using
|
||||
`xcodeenv.simulateApp {}` and emulate an Android APK by using
|
||||
`androidenv.emulateApp {}`.
|
||||
@@ -1,255 +0,0 @@
|
||||
---
|
||||
title: User's Guide for Vim in Nixpkgs
|
||||
author: Marc Weber
|
||||
date: 2016-06-25
|
||||
---
|
||||
# User's Guide to Vim Plugins/Addons/Bundles/Scripts in Nixpkgs
|
||||
|
||||
Both Neovim and Vim can be configured to include your favorite plugins
|
||||
and additional libraries.
|
||||
|
||||
Loading can be deferred; see examples.
|
||||
|
||||
At the moment we support three different methods for managing plugins:
|
||||
|
||||
- Vim packages (*recommend*)
|
||||
- VAM (=vim-addon-manager)
|
||||
- Pathogen
|
||||
- vim-plug
|
||||
|
||||
## Custom configuration
|
||||
|
||||
Adding custom .vimrc lines can be done using the following code:
|
||||
|
||||
```
|
||||
vim_configurable.customize {
|
||||
# `name` specifies the name of the executable and package
|
||||
name = "vim-with-plugins";
|
||||
|
||||
vimrcConfig.customRC = ''
|
||||
set hidden
|
||||
'';
|
||||
}
|
||||
```
|
||||
|
||||
This configuration is used when vim is invoked with the command specified as name, in this case `vim-with-plugins`.
|
||||
|
||||
For Neovim the `configure` argument can be overridden to achieve the same:
|
||||
|
||||
```
|
||||
neovim.override {
|
||||
configure = {
|
||||
customRC = ''
|
||||
# here your custom configuration goes!
|
||||
'';
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
If you want to use `neovim-qt` as a graphical editor, you can configure it by overriding neovim in an overlay
|
||||
or passing it an overridden neovimn:
|
||||
|
||||
```
|
||||
neovim-qt.override {
|
||||
neovim = neovim.override {
|
||||
configure = {
|
||||
customRC = ''
|
||||
# your custom configuration
|
||||
'';
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
## Managing plugins with Vim packages
|
||||
|
||||
To store you plugins in Vim packages (the native vim plugin manager, see `:help packages`) the following example can be used:
|
||||
|
||||
```
|
||||
vim_configurable.customize {
|
||||
vimrcConfig.packages.myVimPackage = with pkgs.vimPlugins; {
|
||||
# loaded on launch
|
||||
start = [ youcompleteme fugitive ];
|
||||
# manually loadable by calling `:packadd $plugin-name`
|
||||
# however, if a vim plugin has a dependency that is not explicitly listed in
|
||||
# opt that dependency will always be added to start to avoid confusion.
|
||||
opt = [ phpCompletion elm-vim ];
|
||||
# To automatically load a plugin when opening a filetype, add vimrc lines like:
|
||||
# autocmd FileType php :packadd phpCompletion
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
`myVimPackage` is an arbitrary name for the generated package. You can choose any name you like.
|
||||
For Neovim the syntax is:
|
||||
|
||||
```
|
||||
neovim.override {
|
||||
configure = {
|
||||
customRC = ''
|
||||
# here your custom configuration goes!
|
||||
'';
|
||||
packages.myVimPackage = with pkgs.vimPlugins; {
|
||||
# see examples below how to use custom packages
|
||||
start = [ ];
|
||||
# If a vim plugin has a dependency that is not explicitly listed in
|
||||
# opt that dependency will always be added to start to avoid confusion.
|
||||
opt = [ ];
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
The resulting package can be added to `packageOverrides` in `~/.nixpkgs/config.nix` to make it installable:
|
||||
|
||||
```
|
||||
{
|
||||
packageOverrides = pkgs: with pkgs; {
|
||||
myVim = vim_configurable.customize {
|
||||
# `name` specifies the name of the executable and package
|
||||
name = "vim-with-plugins";
|
||||
# add here code from the example section
|
||||
};
|
||||
myNeovim = neovim.override {
|
||||
configure = {
|
||||
# add here code from the example section
|
||||
};
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
After that you can install your special grafted `myVim` or `myNeovim` packages.
|
||||
|
||||
## Managing plugins with vim-plug
|
||||
|
||||
To use [vim-plug](https://github.com/junegunn/vim-plug) to manage your Vim
|
||||
plugins the following example can be used:
|
||||
|
||||
```
|
||||
vim_configurable.customize {
|
||||
vimrcConfig.packages.myVimPackage = with pkgs.vimPlugins; {
|
||||
# loaded on launch
|
||||
plug.plugins = [ youcompleteme fugitive phpCompletion elm-vim ];
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
For Neovim the syntax is:
|
||||
|
||||
```
|
||||
neovim.override {
|
||||
configure = {
|
||||
customRC = ''
|
||||
# here your custom configuration goes!
|
||||
'';
|
||||
plug.plugins = with pkgs.vimPlugins; [
|
||||
vim-go
|
||||
];
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
## Managing plugins with VAM
|
||||
|
||||
### Handling dependencies of Vim plugins
|
||||
|
||||
VAM introduced .json files supporting dependencies without versioning
|
||||
assuming that "using latest version" is ok most of the time.
|
||||
|
||||
### Example
|
||||
|
||||
First create a vim-scripts file having one plugin name per line. Example:
|
||||
|
||||
"tlib"
|
||||
{'name': 'vim-addon-sql'}
|
||||
{'filetype_regex': '\%(vim)$', 'names': ['reload', 'vim-dev-plugin']}
|
||||
|
||||
Such vim-scripts file can be read by VAM as well like this:
|
||||
|
||||
call vam#Scripts(expand('~/.vim-scripts'), {})
|
||||
|
||||
Create a default.nix file:
|
||||
|
||||
{ nixpkgs ? import <nixpkgs> {}, compiler ? "ghc7102" }:
|
||||
nixpkgs.vim_configurable.customize { name = "vim"; vimrcConfig.vam.pluginDictionaries = [ "vim-addon-vim2nix" ]; }
|
||||
|
||||
Create a generate.vim file:
|
||||
|
||||
ActivateAddons vim-addon-vim2nix
|
||||
let vim_scripts = "vim-scripts"
|
||||
call nix#ExportPluginsForNix({
|
||||
\ 'path_to_nixpkgs': eval('{"'.substitute(substitute(substitute($NIX_PATH, ':', ',', 'g'), '=',':', 'g'), '\([:,]\)', '"\1"',"g").'"}')["nixpkgs"],
|
||||
\ 'cache_file': '/tmp/vim2nix-cache',
|
||||
\ 'try_catch': 0,
|
||||
\ 'plugin_dictionaries': ["vim-addon-manager"]+map(readfile(vim_scripts), 'eval(v:val)')
|
||||
\ })
|
||||
|
||||
Then run
|
||||
|
||||
nix-shell -p vimUtils.vim_with_vim2nix --command "vim -c 'source generate.vim'"
|
||||
|
||||
You should get a Vim buffer with the nix derivations (output1) and vam.pluginDictionaries (output2).
|
||||
You can add your vim to your system's configuration file like this and start it by "vim-my":
|
||||
|
||||
my-vim =
|
||||
let plugins = let inherit (vimUtils) buildVimPluginFrom2Nix; in {
|
||||
copy paste output1 here
|
||||
}; in vim_configurable.customize {
|
||||
name = "vim-my";
|
||||
|
||||
vimrcConfig.vam.knownPlugins = plugins; # optional
|
||||
vimrcConfig.vam.pluginDictionaries = [
|
||||
copy paste output2 here
|
||||
];
|
||||
|
||||
# Pathogen would be
|
||||
# vimrcConfig.pathogen.knownPlugins = plugins; # plugins
|
||||
# vimrcConfig.pathogen.pluginNames = ["tlib"];
|
||||
};
|
||||
|
||||
|
||||
Sample output1:
|
||||
|
||||
"reload" = buildVimPluginFrom2Nix { # created by nix#NixDerivation
|
||||
name = "reload";
|
||||
src = fetchgit {
|
||||
url = "git://github.com/xolox/vim-reload";
|
||||
rev = "0a601a668727f5b675cb1ddc19f6861f3f7ab9e1";
|
||||
sha256 = "0vb832l9yxj919f5hfg6qj6bn9ni57gnjd3bj7zpq7d4iv2s4wdh";
|
||||
};
|
||||
dependencies = ["nim-misc"];
|
||||
|
||||
};
|
||||
[...]
|
||||
|
||||
Sample output2:
|
||||
|
||||
[
|
||||
''vim-addon-manager''
|
||||
''tlib''
|
||||
{ "name" = ''vim-addon-sql''; }
|
||||
{ "filetype_regex" = ''\%(vim)$$''; "names" = [ ''reload'' ''vim-dev-plugin'' ]; }
|
||||
]
|
||||
|
||||
|
||||
## Adding new plugins to nixpkgs
|
||||
|
||||
In `pkgs/misc/vim-plugins/vim-plugin-names` we store the plugin names
|
||||
for all vim plugins we automatically generate plugins for.
|
||||
The format of this file `github username/github repository`:
|
||||
For example https://github.com/scrooloose/nerdtree becomes `scrooloose/nerdtree`.
|
||||
After adding your plugin to this file run the `./update.py` in the same folder.
|
||||
This will updated a file called `generated.nix` and make your plugin accessible in the
|
||||
`vimPlugins` attribute set (`vimPlugins.nerdtree` in our example).
|
||||
If additional steps to the build process of the plugin are required, add an
|
||||
override to the `pkgs/misc/vim-plugins/default.nix` in the same directory.
|
||||
|
||||
## Important repositories
|
||||
|
||||
- [vim-pi](https://bitbucket.org/vimcommunity/vim-pi) is a plugin repository
|
||||
from VAM plugin manager meant to be used by others as well used by
|
||||
|
||||
- [vim2nix](http://github.com/MarcWeber/vim-addon-vim2nix) which generates the
|
||||
.nix code
|
||||
|
||||
@@ -1,26 +0,0 @@
|
||||
# Generates the documentation for library functons via nixdoc. To add
|
||||
# another library function file to this list, the include list in the
|
||||
# file `doc/functions/library.xml` must also be updated.
|
||||
|
||||
{ pkgs ? import ./.. {}, locationsXml }:
|
||||
|
||||
with pkgs; stdenv.mkDerivation {
|
||||
name = "nixpkgs-lib-docs";
|
||||
src = ./../lib;
|
||||
|
||||
buildInputs = [ nixdoc ];
|
||||
installPhase = ''
|
||||
function docgen {
|
||||
nixdoc -c "$1" -d "$2" -f "../lib/$1.nix" > "$out/$1.xml"
|
||||
}
|
||||
|
||||
mkdir -p $out
|
||||
ln -s ${locationsXml} $out/locations.xml
|
||||
|
||||
docgen strings 'String manipulation functions'
|
||||
docgen trivial 'Miscellaneous functions'
|
||||
docgen lists 'List manipulation functions'
|
||||
docgen debug 'Debugging functions'
|
||||
docgen options 'NixOS / nixpkgs option handling'
|
||||
'';
|
||||
}
|
||||
@@ -1,85 +0,0 @@
|
||||
{ pkgs ? (import ./.. { }), nixpkgs ? { }}:
|
||||
let
|
||||
revision = pkgs.lib.trivial.revisionWithDefault (nixpkgs.revision or "master");
|
||||
|
||||
libDefPos = set:
|
||||
builtins.map
|
||||
(name: {
|
||||
name = name;
|
||||
location = builtins.unsafeGetAttrPos name set;
|
||||
})
|
||||
(builtins.attrNames set);
|
||||
|
||||
libset = toplib:
|
||||
builtins.map
|
||||
(subsetname: {
|
||||
subsetname = subsetname;
|
||||
functions = libDefPos toplib."${subsetname}";
|
||||
})
|
||||
(builtins.filter
|
||||
(name: builtins.isAttrs toplib."${name}")
|
||||
(builtins.attrNames toplib));
|
||||
|
||||
nixpkgsLib = pkgs.lib;
|
||||
|
||||
flattenedLibSubset = { subsetname, functions }:
|
||||
builtins.map
|
||||
(fn: {
|
||||
name = "lib.${subsetname}.${fn.name}";
|
||||
value = fn.location;
|
||||
})
|
||||
functions;
|
||||
|
||||
locatedlibsets = libs: builtins.map flattenedLibSubset (libset libs);
|
||||
removeFilenamePrefix = prefix: filename:
|
||||
let
|
||||
prefixLen = (builtins.stringLength prefix) + 1; # +1 to remove the leading /
|
||||
filenameLen = builtins.stringLength filename;
|
||||
substr = builtins.substring prefixLen filenameLen filename;
|
||||
in substr;
|
||||
|
||||
removeNixpkgs = removeFilenamePrefix (builtins.toString pkgs.path);
|
||||
|
||||
liblocations =
|
||||
builtins.filter
|
||||
(elem: elem.value != null)
|
||||
(nixpkgsLib.lists.flatten
|
||||
(locatedlibsets nixpkgsLib));
|
||||
|
||||
fnLocationRelative = { name, value }:
|
||||
{
|
||||
inherit name;
|
||||
value = value // { file = removeNixpkgs value.file; };
|
||||
};
|
||||
|
||||
relativeLocs = (builtins.map fnLocationRelative liblocations);
|
||||
sanitizeId = builtins.replaceStrings
|
||||
[ "'" ]
|
||||
[ "-prime" ];
|
||||
|
||||
urlPrefix = "https://github.com/NixOS/nixpkgs/blob/${revision}";
|
||||
xmlstrings = (nixpkgsLib.strings.concatMapStrings
|
||||
({ name, value }:
|
||||
''
|
||||
<section><title>${name}</title>
|
||||
<para xml:id="${sanitizeId name}">
|
||||
Located at
|
||||
<link
|
||||
xlink:href="${urlPrefix}/${value.file}#L${builtins.toString value.line}">${value.file}:${builtins.toString value.line}</link>
|
||||
in <literal><nixpkgs></literal>.
|
||||
</para>
|
||||
</section>
|
||||
'')
|
||||
relativeLocs);
|
||||
|
||||
in pkgs.writeText
|
||||
"locations.xml"
|
||||
''
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
version="5">
|
||||
<title>All the locations for every lib function</title>
|
||||
<para>This file is only for inclusion by other files.</para>
|
||||
${xmlstrings}
|
||||
</section>
|
||||
''
|
||||
@@ -1,24 +0,0 @@
|
||||
<book xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude">
|
||||
<info>
|
||||
<title>Nixpkgs Contributors Guide</title>
|
||||
<subtitle>Version <xi:include href=".version" parse="text" />
|
||||
</subtitle>
|
||||
</info>
|
||||
<xi:include href="introduction.chapter.xml" />
|
||||
<xi:include href="quick-start.xml" />
|
||||
<xi:include href="stdenv.xml" />
|
||||
<xi:include href="multiple-output.xml" />
|
||||
<xi:include href="cross-compilation.xml" />
|
||||
<xi:include href="configuration.xml" />
|
||||
<xi:include href="functions.xml" />
|
||||
<xi:include href="meta.xml" />
|
||||
<xi:include href="languages-frameworks/index.xml" />
|
||||
<xi:include href="platform-notes.xml" />
|
||||
<xi:include href="package-notes.xml" />
|
||||
<xi:include href="overlays.xml" />
|
||||
<xi:include href="coding-conventions.xml" />
|
||||
<xi:include href="submitting-changes.xml" />
|
||||
<xi:include href="reviewing-contributions.xml" />
|
||||
<xi:include href="contributing.xml" />
|
||||
</book>
|
||||
431
doc/meta.xml
431
doc/meta.xml
@@ -1,431 +0,0 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="chap-meta">
|
||||
<title>Meta-attributes</title>
|
||||
<para>
|
||||
Nix packages can declare <emphasis>meta-attributes</emphasis> that contain
|
||||
information about a package such as a description, its homepage, its license,
|
||||
and so on. For instance, the GNU Hello package has a <varname>meta</varname>
|
||||
declaration like this:
|
||||
<programlisting>
|
||||
meta = with stdenv.lib; {
|
||||
description = "A program that produces a familiar, friendly greeting";
|
||||
longDescription = ''
|
||||
GNU Hello is a program that prints "Hello, world!" when you run it.
|
||||
It is fully customizable.
|
||||
'';
|
||||
homepage = https://www.gnu.org/software/hello/manual/;
|
||||
license = licenses.gpl3Plus;
|
||||
maintainers = [ maintainers.eelco ];
|
||||
platforms = platforms.all;
|
||||
};
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
Meta-attributes are not passed to the builder of the package. Thus, a change
|
||||
to a meta-attribute doesn’t trigger a recompilation of the package. The
|
||||
value of a meta-attribute must be a string.
|
||||
</para>
|
||||
<para>
|
||||
The meta-attributes of a package can be queried from the command-line using
|
||||
<command>nix-env</command>:
|
||||
<screen>
|
||||
$ nix-env -qa hello --json
|
||||
{
|
||||
"hello": {
|
||||
"meta": {
|
||||
"description": "A program that produces a familiar, friendly greeting",
|
||||
"homepage": "https://www.gnu.org/software/hello/manual/",
|
||||
"license": {
|
||||
"fullName": "GNU General Public License version 3 or later",
|
||||
"shortName": "GPLv3+",
|
||||
"url": "http://www.fsf.org/licensing/licenses/gpl.html"
|
||||
},
|
||||
"longDescription": "GNU Hello is a program that prints \"Hello, world!\" when you run it.\nIt is fully customizable.\n",
|
||||
"maintainers": [
|
||||
"Ludovic Court\u00e8s <ludo@gnu.org>"
|
||||
],
|
||||
"platforms": [
|
||||
"i686-linux",
|
||||
"x86_64-linux",
|
||||
"armv5tel-linux",
|
||||
"armv7l-linux",
|
||||
"mips32-linux",
|
||||
"x86_64-darwin",
|
||||
"i686-cygwin",
|
||||
"i686-freebsd",
|
||||
"x86_64-freebsd",
|
||||
"i686-openbsd",
|
||||
"x86_64-openbsd"
|
||||
],
|
||||
"position": "/home/user/dev/nixpkgs/pkgs/applications/misc/hello/default.nix:14"
|
||||
},
|
||||
"name": "hello-2.9",
|
||||
"system": "x86_64-linux"
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
</screen>
|
||||
<command>nix-env</command> knows about the <varname>description</varname>
|
||||
field specifically:
|
||||
<screen>
|
||||
$ nix-env -qa hello --description
|
||||
hello-2.3 A program that produces a familiar, friendly greeting
|
||||
</screen>
|
||||
</para>
|
||||
<section xml:id="sec-standard-meta-attributes">
|
||||
<title>Standard meta-attributes</title>
|
||||
|
||||
<para>
|
||||
It is expected that each meta-attribute is one of the following:
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>description</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
A short (one-line) description of the package. This is shown by
|
||||
<command>nix-env -q --description</command> and also on the Nixpkgs
|
||||
release pages.
|
||||
</para>
|
||||
<para>
|
||||
Don’t include a period at the end. Don’t include newline characters.
|
||||
Capitalise the first character. For brevity, don’t repeat the name of
|
||||
package — just describe what it does.
|
||||
</para>
|
||||
<para>
|
||||
Wrong: <literal>"libpng is a library that allows you to decode PNG
|
||||
images."</literal>
|
||||
</para>
|
||||
<para>
|
||||
Right: <literal>"A library for decoding PNG images"</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>longDescription</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
An arbitrarily long description of the package.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>branch</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Release branch. Used to specify that a package is not going to receive
|
||||
updates that are not in this branch; for example, Linux kernel 3.0 is
|
||||
supposed to be updated to 3.0.X, not 3.1.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>homepage</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The package’s homepage. Example:
|
||||
<literal>https://www.gnu.org/software/hello/manual/</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>downloadPage</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The page where a link to the current version can be found. Example:
|
||||
<literal>https://ftp.gnu.org/gnu/hello/</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>license</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The license, or licenses, for the package. One from the attribute set
|
||||
defined in
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/lib/licenses.nix">
|
||||
<filename>nixpkgs/lib/licenses.nix</filename></link>. At this moment
|
||||
using both a list of licenses and a single license is valid. If the
|
||||
license field is in the form of a list representation, then it means that
|
||||
parts of the package are licensed differently. Each license should
|
||||
preferably be referenced by their attribute. The non-list attribute value
|
||||
can also be a space delimited string representation of the contained
|
||||
attribute shortNames or spdxIds. The following are all valid examples:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Single license referenced by attribute (preferred)
|
||||
<literal>stdenv.lib.licenses.gpl3</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Single license referenced by its attribute shortName (frowned upon)
|
||||
<literal>"gpl3"</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Single license referenced by its attribute spdxId (frowned upon)
|
||||
<literal>"GPL-3.0"</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Multiple licenses referenced by attribute (preferred) <literal>with
|
||||
stdenv.lib.licenses; [ asl20 free ofl ]</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Multiple licenses referenced as a space delimited string of attribute
|
||||
shortNames (frowned upon) <literal>"asl20 free ofl"</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
For details, see <xref linkend='sec-meta-license'/>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>maintainers</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
A list of names and e-mail addresses of the maintainers of this Nix
|
||||
expression. If you would like to be a maintainer of a package, you may
|
||||
want to add yourself to
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix"><filename>nixpkgs/maintainers/maintainer-list.nix</filename></link>
|
||||
and write something like <literal>[ stdenv.lib.maintainers.alice
|
||||
stdenv.lib.maintainers.bob ]</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>priority</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The <emphasis>priority</emphasis> of the package, used by
|
||||
<command>nix-env</command> to resolve file name conflicts between
|
||||
packages. See the Nix manual page for <command>nix-env</command> for
|
||||
details. Example: <literal>"10"</literal> (a low-priority package).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>platforms</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The list of Nix platform types on which the package is supported. Hydra
|
||||
builds packages according to the platform specified. If no platform is
|
||||
specified, the package does not have prebuilt binaries. An example is:
|
||||
<programlisting>
|
||||
meta.platforms = stdenv.lib.platforms.linux;
|
||||
</programlisting>
|
||||
Attribute Set <varname>stdenv.lib.platforms</varname> defines
|
||||
<link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/lib/systems/doubles.nix">
|
||||
various common lists</link> of platforms types.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>tests</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<warning>
|
||||
<para>
|
||||
This attribute is special in that it is not actually under the
|
||||
<literal>meta</literal> attribute set but rather under the
|
||||
<literal>passthru</literal> attribute set. This is due to a current
|
||||
limitation of Nix, and will change as soon as Nixpkgs will be able to
|
||||
depend on a new enough version of Nix. See
|
||||
<link xlink:href="https://github.com/NixOS/nix/issues/2532">the relevant
|
||||
issue</link> for more details.
|
||||
</para>
|
||||
</warning>
|
||||
<para>
|
||||
An attribute set with as values tests. A test is a derivation, which
|
||||
builds successfully when the test passes, and fails to build otherwise. A
|
||||
derivation that is a test needs to have <literal>meta.timeout</literal>
|
||||
defined.
|
||||
</para>
|
||||
<para>
|
||||
The NixOS tests are available as <literal>nixosTests</literal> in
|
||||
parameters of derivations. For instance, the OpenSMTPD derivation
|
||||
includes lines similar to:
|
||||
<programlisting>
|
||||
{ /* ... */, nixosTests }:
|
||||
{
|
||||
# ...
|
||||
passthru.tests = {
|
||||
basic-functionality-and-dovecot-integration = nixosTests.opensmtpd;
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>timeout</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
A timeout (in seconds) for building the derivation. If the derivation
|
||||
takes longer than this time to build, it can fail due to breaking the
|
||||
timeout. However, all computers do not have the same computing power,
|
||||
hence some builders may decide to apply a multiplicative factor to this
|
||||
value. When filling this value in, try to keep it approximately
|
||||
consistent with other values already present in
|
||||
<literal>nixpkgs</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>hydraPlatforms</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The list of Nix platform types for which the Hydra instance at
|
||||
<literal>hydra.nixos.org</literal> will build the package. (Hydra is the
|
||||
Nix-based continuous build system.) It defaults to the value of
|
||||
<varname>meta.platforms</varname>. Thus, the only reason to set
|
||||
<varname>meta.hydraPlatforms</varname> is if you want
|
||||
<literal>hydra.nixos.org</literal> to build the package on a subset of
|
||||
<varname>meta.platforms</varname>, or not at all, e.g.
|
||||
<programlisting>
|
||||
meta.platforms = stdenv.lib.platforms.linux;
|
||||
meta.hydraPlatforms = [];
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>broken</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
If set to <literal>true</literal>, the package is marked as “broken”,
|
||||
meaning that it won’t show up in <literal>nix-env -qa</literal>, and
|
||||
cannot be built or installed. Such packages should be removed from
|
||||
Nixpkgs eventually unless they are fixed.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>updateWalker</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
If set to <literal>true</literal>, the package is tested to be updated
|
||||
correctly by the <literal>update-walker.sh</literal> script without
|
||||
additional settings. Such packages have <varname>meta.version</varname>
|
||||
set and their homepage (or the page specified by
|
||||
<varname>meta.downloadPage</varname>) contains a direct link to the
|
||||
package tarball.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</section>
|
||||
<section xml:id="sec-meta-license">
|
||||
<title>Licenses</title>
|
||||
|
||||
<para>
|
||||
The <varname>meta.license</varname> attribute should preferrably contain a
|
||||
value from <varname>stdenv.lib.licenses</varname> defined in
|
||||
<link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/lib/licenses.nix">
|
||||
<filename>nixpkgs/lib/licenses.nix</filename></link>, or in-place license
|
||||
description of the same format if the license is unlikely to be useful in
|
||||
another expression.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Although it's typically better to indicate the specific license, a few
|
||||
generic options are available:
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>stdenv.lib.licenses.free</varname>, <varname>"free"</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Catch-all for free software licenses not listed above.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>stdenv.lib.licenses.unfreeRedistributable</varname>, <varname>"unfree-redistributable"</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Unfree package that can be redistributed in binary form. That is, it’s
|
||||
legal to redistribute the <emphasis>output</emphasis> of the derivation.
|
||||
This means that the package can be included in the Nixpkgs channel.
|
||||
</para>
|
||||
<para>
|
||||
Sometimes proprietary software can only be redistributed unmodified.
|
||||
Make sure the builder doesn’t actually modify the original binaries;
|
||||
otherwise we’re breaking the license. For instance, the NVIDIA X11
|
||||
drivers can be redistributed unmodified, but our builder applies
|
||||
<command>patchelf</command> to make them work. Thus, its license is
|
||||
<varname>"unfree"</varname> and it cannot be included in the Nixpkgs
|
||||
channel.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>stdenv.lib.licenses.unfree</varname>, <varname>"unfree"</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Unfree package that cannot be redistributed. You can build it yourself,
|
||||
but you cannot redistribute the output of the derivation. Thus it cannot
|
||||
be included in the Nixpkgs channel.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>stdenv.lib.licenses.unfreeRedistributableFirmware</varname>, <varname>"unfree-redistributable-firmware"</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This package supplies unfree, redistributable firmware. This is a
|
||||
separate value from <varname>unfree-redistributable</varname> because
|
||||
not everybody cares whether firmware is free.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</para>
|
||||
</section>
|
||||
</chapter>
|
||||
@@ -1,323 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE chapter [
|
||||
<!ENTITY ndash "–"> <!-- @vcunat likes to use this one ;-) -->
|
||||
]>
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="chap-multiple-output">
|
||||
<title>Multiple-output packages</title>
|
||||
<section xml:id="sec-multiple-outputs-introduction">
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>
|
||||
The Nix language allows a derivation to produce multiple outputs, which is
|
||||
similar to what is utilized by other Linux distribution packaging systems.
|
||||
The outputs reside in separate Nix store paths, so they can be mostly
|
||||
handled independently of each other, including passing to build inputs,
|
||||
garbage collection or binary substitution. The exception is that building
|
||||
from source always produces all the outputs.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The main motivation is to save disk space by reducing runtime closure sizes;
|
||||
consequently also sizes of substituted binaries get reduced. Splitting can
|
||||
be used to have more granular runtime dependencies, for example the typical
|
||||
reduction is to split away development-only files, as those are typically
|
||||
not needed during runtime. As a result, closure sizes of many packages can
|
||||
get reduced to a half or even much less.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
The reduction effects could be instead achieved by building the parts in
|
||||
completely separate derivations. That would often additionally reduce
|
||||
build-time closures, but it tends to be much harder to write such
|
||||
derivations, as build systems typically assume all parts are being built at
|
||||
once. This compromise approach of single source package producing multiple
|
||||
binary packages is also utilized often by rpm and deb.
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
<section xml:id="sec-multiple-outputs-installing">
|
||||
<title>Installing a split package</title>
|
||||
|
||||
<para>
|
||||
When installing a package via <varname>systemPackages</varname> or
|
||||
<command>nix-env</command> you have several options:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
You can install particular outputs explicitly, as each is available in the
|
||||
Nix language as an attribute of the package. The
|
||||
<varname>outputs</varname> attribute contains a list of output names.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
You can let it use the default outputs. These are handled by
|
||||
<varname>meta.outputsToInstall</varname> attribute that contains a list of
|
||||
output names.
|
||||
</para>
|
||||
<para>
|
||||
TODO: more about tweaking the attribute, etc.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
NixOS provides configuration option
|
||||
<varname>environment.extraOutputsToInstall</varname> that allows adding
|
||||
extra outputs of <varname>environment.systemPackages</varname> atop the
|
||||
default ones. It's mainly meant for documentation and debug symbols, and
|
||||
it's also modified by specific options.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
At this moment there is no similar configurability for packages installed
|
||||
by <command>nix-env</command>. You can still use approach from
|
||||
<xref linkend="sec-modify-via-packageOverrides" /> to override
|
||||
<varname>meta.outputsToInstall</varname> attributes, but that's a rather
|
||||
inconvenient way.
|
||||
</para>
|
||||
</note>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section xml:id="sec-multiple-outputs-using-split-packages">
|
||||
<title>Using a split package</title>
|
||||
|
||||
<para>
|
||||
In the Nix language the individual outputs can be reached explicitly as
|
||||
attributes, e.g. <varname>coreutils.info</varname>, but the typical case is
|
||||
just using packages as build inputs.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When a multiple-output derivation gets into a build input of another
|
||||
derivation, the <varname>dev</varname> output is added if it exists,
|
||||
otherwise the first output is added. In addition to that,
|
||||
<varname>propagatedBuildOutputs</varname> of that package which by default
|
||||
contain <varname>$outputBin</varname> and <varname>$outputLib</varname> are
|
||||
also added. (See <xref linkend="multiple-output-file-type-groups" />.)
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="sec-multiple-outputs-">
|
||||
<title>Writing a split derivation</title>
|
||||
|
||||
<para>
|
||||
Here you find how to write a derivation that produces multiple outputs.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In nixpkgs there is a framework supporting multiple-output derivations. It
|
||||
tries to cover most cases by default behavior. You can find the source
|
||||
separated in
|
||||
<<filename>nixpkgs/pkgs/build-support/setup-hooks/multiple-outputs.sh</filename>>;
|
||||
it's relatively well-readable. The whole machinery is triggered by defining
|
||||
the <varname>outputs</varname> attribute to contain the list of desired
|
||||
output names (strings).
|
||||
</para>
|
||||
|
||||
<programlisting>outputs = [ "bin" "dev" "out" "doc" ];</programlisting>
|
||||
|
||||
<para>
|
||||
Often such a single line is enough. For each output an equally named
|
||||
environment variable is passed to the builder and contains the path in nix
|
||||
store for that output. Typically you also want to have the main
|
||||
<varname>out</varname> output, as it catches any files that didn't get
|
||||
elsewhere.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
There is a special handling of the <varname>debug</varname> output,
|
||||
described at <xref linkend="stdenv-separateDebugInfo" />.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<section xml:id="multiple-output-file-binaries-first-convention">
|
||||
<title><quote>Binaries first</quote></title>
|
||||
|
||||
<para>
|
||||
A commonly adopted convention in <literal>nixpkgs</literal> is that
|
||||
executables provided by the package are contained within its first output.
|
||||
This convention allows the dependent packages to reference the executables
|
||||
provided by packages in a uniform manner. For instance, provided with the
|
||||
knowledge that the <literal>perl</literal> package contains a
|
||||
<literal>perl</literal> executable it can be referenced as
|
||||
<literal>${pkgs.perl}/bin/perl</literal> within a Nix derivation that needs
|
||||
to execute a Perl script.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <literal>glibc</literal> package is a deliberate single exception to
|
||||
the <quote>binaries first</quote> convention. The <literal>glibc</literal>
|
||||
has <literal>libs</literal> as its first output allowing the libraries
|
||||
provided by <literal>glibc</literal> to be referenced directly (e.g.
|
||||
<literal>${stdenv.glibc}/lib/ld-linux-x86-64.so.2</literal>). The
|
||||
executables provided by <literal>glibc</literal> can be accessed via its
|
||||
<literal>bin</literal> attribute (e.g.
|
||||
<literal>${stdenv.glibc.bin}/bin/ldd</literal>).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The reason for why <literal>glibc</literal> deviates from the convention is
|
||||
because referencing a library provided by <literal>glibc</literal> is a
|
||||
very common operation among Nix packages. For instance, third-party
|
||||
executables packaged by Nix are typically patched and relinked with the
|
||||
relevant version of <literal>glibc</literal> libraries from Nix packages
|
||||
(please see the documentation on
|
||||
<link xlink:href="https://nixos.org/patchelf.html">patchelf</link> for more
|
||||
details).
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="multiple-output-file-type-groups">
|
||||
<title>File type groups</title>
|
||||
|
||||
<para>
|
||||
The support code currently recognizes some particular kinds of outputs and
|
||||
either instructs the build system of the package to put files into their
|
||||
desired outputs or it moves the files during the fixup phase. Each group of
|
||||
file types has an <varname>outputFoo</varname> variable specifying the
|
||||
output name where they should go. If that variable isn't defined by the
|
||||
derivation writer, it is guessed – a default output name is defined,
|
||||
falling back to other possibilities if the output isn't defined.
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname> $outputDev</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
is for development-only files. These include C(++) headers, pkg-config,
|
||||
cmake and aclocal files. They go to <varname>dev</varname> or
|
||||
<varname>out</varname> by default.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname> $outputBin</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
is meant for user-facing binaries, typically residing in bin/. They go
|
||||
to <varname>bin</varname> or <varname>out</varname> by default.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname> $outputLib</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
is meant for libraries, typically residing in <filename>lib/</filename>
|
||||
and <filename>libexec/</filename>. They go to <varname>lib</varname> or
|
||||
<varname>out</varname> by default.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname> $outputDoc</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
is for user documentation, typically residing in
|
||||
<filename>share/doc/</filename>. It goes to <varname>doc</varname> or
|
||||
<varname>out</varname> by default.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname> $outputDevdoc</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
is for <emphasis>developer</emphasis> documentation. Currently we count
|
||||
gtk-doc and devhelp books in there. It goes to <varname>devdoc</varname>
|
||||
or is removed (!) by default. This is because e.g. gtk-doc tends to be
|
||||
rather large and completely unused by nixpkgs users.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname> $outputMan</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
is for man pages (except for section 3). They go to
|
||||
<varname>man</varname> or <varname>$outputBin</varname> by default.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname> $outputDevman</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
is for section 3 man pages. They go to <varname>devman</varname> or
|
||||
<varname>$outputMan</varname> by default.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname> $outputInfo</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
is for info pages. They go to <varname>info</varname> or
|
||||
<varname>$outputBin</varname> by default.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-multiple-outputs-caveats">
|
||||
<title>Common caveats</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Some configure scripts don't like some of the parameters passed by
|
||||
default by the framework, e.g. <literal>--docdir=/foo/bar</literal>. You
|
||||
can disable this by setting <literal>setOutputFlags = false;</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The outputs of a single derivation can retain references to each other,
|
||||
but note that circular references are not allowed. (And each
|
||||
strongly-connected component would act as a single output anyway.)
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Most of split packages contain their core functionality in libraries.
|
||||
These libraries tend to refer to various kind of data that typically gets
|
||||
into <varname>out</varname>, e.g. locale strings, so there is often no
|
||||
advantage in separating the libraries into <varname>lib</varname>, as
|
||||
keeping them in <varname>out</varname> is easier.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Some packages have hidden assumptions on install paths, which complicates
|
||||
splitting.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</section>
|
||||
<!--Writing a split derivation-->
|
||||
</chapter>
|
||||
@@ -1,329 +0,0 @@
|
||||
Setting up a cross compiler with Nix
|
||||
|
||||
"Cross compilation" means compiling a program on one machine for another
|
||||
type of machine. A typical use of cross compilation is to compile programs
|
||||
for embedded devices. These devices often don't have the computing power
|
||||
and memory to compile programs natively.
|
||||
|
||||
For a fully working cross compiler the following are needed:
|
||||
|
||||
* cross binutils: assembler, archiver, linker, etcetera that understand
|
||||
the format of the target system
|
||||
|
||||
* cross compiler: a compiler that can generate binary code and object files
|
||||
for the target platform
|
||||
|
||||
* cross C library: a library to link object files with to create fully
|
||||
functional programs
|
||||
|
||||
Cross compilers are difficult to set up. A lot of people report that they
|
||||
cannot succeed in building a cross toolchain successfully. The answers
|
||||
usually consist of "download this pre-built toolchain", which is equally
|
||||
unhelpful.
|
||||
|
||||
A toolchain is set up in five steps:
|
||||
|
||||
1. build binutils to that can run on the host platform, but generate code
|
||||
for the target platform
|
||||
|
||||
2. build Linux kernel headers for the target platform
|
||||
|
||||
3. build a minimal C only version of GCC, that can run on the host platform
|
||||
and generate code for the target platform
|
||||
|
||||
4. build a C library for the target platform. This includes the dynamic
|
||||
linker, C library, etc.
|
||||
|
||||
5. build a full GCC
|
||||
|
||||
****
|
||||
NB:
|
||||
|
||||
Keep in mind that many programs are not very well suited for cross
|
||||
compilation. Either they are not intended to run on other platforms,
|
||||
because the code is highly platform specific, or the configuration process
|
||||
is not written with cross compilation in mind.
|
||||
|
||||
Nix will not solve these problems for you!
|
||||
***
|
||||
|
||||
This document describes to set up a cross compiler to generate code for
|
||||
arm-linux with uClibc and runs on i686-linux. The "stdenv" used is the
|
||||
default from the standard Nix packages collection.
|
||||
|
||||
Step 1: build binutils for arm-linux in the stdenv for i686-linux
|
||||
|
||||
---
|
||||
{stdenv, fetchurl, noSysDirs}:
|
||||
|
||||
stdenv.mkDerivation {
|
||||
name = "binutils-2.16.1-arm";
|
||||
builder = ./builder.sh;
|
||||
src = fetchurl {
|
||||
url = http://ftp.nluug.nl/gnu/binutils/binutils-2.16.1.tar.bz2;
|
||||
sha256 = "1ian3kwh2vg6hr3ymrv48s04gijs539vzrq62xr76bxbhbwnz2np";
|
||||
};
|
||||
inherit noSysDirs;
|
||||
configureFlags = [ "--target=arm-linux" ];
|
||||
}
|
||||
---
|
||||
|
||||
This will compile binutils that will run on i686-linux, but knows the
|
||||
format used by arm-linux.
|
||||
|
||||
Step 2: build kernel headers for the target architecture
|
||||
|
||||
default.nix for kernel-headers-arm:
|
||||
|
||||
---
|
||||
{stdenv, fetchurl}:
|
||||
|
||||
assert stdenv.buildPlatform.system == "i686-linux";
|
||||
|
||||
stdenv.mkDerivation {
|
||||
name = "linux-headers-2.6.13.1-arm";
|
||||
builder = ./builder.sh;
|
||||
src = fetchurl {
|
||||
url = http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.13.1.tar.bz2;
|
||||
sha256 = "12qxmc827fjhaz53kjy7vyrzsaqcg78amiqsb3qm20z26w705lma";
|
||||
};
|
||||
}
|
||||
---
|
||||
|
||||
builder.sh for kernel-headers-arm:
|
||||
|
||||
---
|
||||
source $stdenv/setup
|
||||
|
||||
|
||||
buildPhase() {
|
||||
make include/linux/version.h
|
||||
}
|
||||
|
||||
buildPhase=buildPhase
|
||||
|
||||
|
||||
installPhase() {
|
||||
mkdir $out
|
||||
mkdir $out/include
|
||||
#cd $out/include
|
||||
#ln -s asm-arm asm
|
||||
make include/asm ARCH=arm
|
||||
cp -prvd include/linux include/asm include/asm-arm include/asm-generic $out/include
|
||||
echo -n > $out/include/linux/autoconf.h
|
||||
}
|
||||
|
||||
installPhase=installPhase
|
||||
|
||||
|
||||
genericBuild
|
||||
---
|
||||
|
||||
Step 3: build a minimal GCC
|
||||
|
||||
Extra/different parameters include the target platform and the kernel
|
||||
headers argument (this needs a major cleanup, as well as the name, it
|
||||
needs to be different!). Profiled compilers are disabled. The tarball
|
||||
used here is just gcc-core. For some reason it doesn't install nicely
|
||||
if the whole tarball is used (or is this some braino on my side? -- AH).
|
||||
|
||||
Only C is used, because for other languages (such as C++) extra libraries
|
||||
need to be compiled, for which libraries compiled for the target system
|
||||
are needed.
|
||||
|
||||
There is a bit of evilness going on. The cross compiled utilities need
|
||||
to be either copied to or be linked from the output tree of the compiler.
|
||||
(Is this really true? Back this up with arguments! -- AH)
|
||||
|
||||
Symbolic links are not something we want inside the Nix store.
|
||||
|
||||
---
|
||||
{ stdenv, fetchurl, noSysDirs
|
||||
, langC ? true, langCC ? true, langF77 ? false
|
||||
, profiledCompiler ? false
|
||||
, binutilsArm
|
||||
, kernelHeadersArm
|
||||
}:
|
||||
|
||||
assert langC;
|
||||
|
||||
stdenv.mkDerivation {
|
||||
name = "gcc-4.0.2-arm";
|
||||
builder = ./builder.sh;
|
||||
src = fetchurl {
|
||||
url = ftp://ftp.nluug.nl/pub/gnu/gcc/gcc-4.0.2/gcc-core-4.0.2.tar.bz2;
|
||||
sha256 = "02fxh0asflm8825w23l2jq1wvs7hbnam0jayrivg7zdv2ifnc0rc";
|
||||
};
|
||||
# !!! apply only if noSysDirs is set
|
||||
patches = [./no-sys-dirs.patch ./gcc-inhibit.patch];
|
||||
inherit noSysDirs langC langCC langF77 profiledCompiler;
|
||||
buildInputs = [binutilsArm];
|
||||
inherit kernelHeadersArm binutilsArm;
|
||||
platform = "arm-linux";
|
||||
}
|
||||
---
|
||||
|
||||
The builder.sh for a cross-compiler. Note that the binutils are prefixed
|
||||
with the architecture name, so arm-linux-ld instead of ld, etc. This is
|
||||
necessary because when we cross-compile a lot of programs look for these
|
||||
tools with these specific names. The standard gcc-wrapper does not take this
|
||||
into account yet.
|
||||
|
||||
---
|
||||
source $stdenv/setup
|
||||
|
||||
|
||||
export NIX_FIXINC_DUMMY=$NIX_BUILD_TOP/dummy
|
||||
mkdir $NIX_FIXINC_DUMMY
|
||||
|
||||
|
||||
if test "$noSysDirs" = "1"; then
|
||||
|
||||
if test "$noSysDirs" = "1"; then
|
||||
# Figure out what extra flags to pass to the gcc compilers
|
||||
# being generated to make sure that they use our glibc.
|
||||
if test -e $NIX_CC/nix-support/orig-glibc; then
|
||||
glibc=$(cat $NIX_CC/nix-support/orig-glibc)
|
||||
# Ugh. Copied from gcc-wrapper/builder.sh. We can't just
|
||||
# source in $NIX_CC/nix-support/add-flags, since that
|
||||
# would cause *this* GCC to be linked against the
|
||||
# *previous* GCC. Need some more modularity there.
|
||||
extraCFlags="-B$glibc/lib -isystem $glibc/include"
|
||||
extraLDFlags="-B$glibc/lib -L$glibc/lib -Wl,-s \
|
||||
-Wl,-dynamic-linker,$glibc/lib/ld-linux.so.2"
|
||||
|
||||
# Oh, what a hack. I should be shot for this.
|
||||
# In stage 1, we should link against the previous GCC, but
|
||||
# not afterwards. Otherwise we retain a dependency.
|
||||
# However, ld-wrapper, which adds the linker flags for the
|
||||
# previous GCC, is also used in stage 2/3. We can prevent
|
||||
# it from adding them by NIX_GLIBC_FLAGS_SET, but then
|
||||
# gcc-wrapper will also not add them, thereby causing
|
||||
# stage 1 to fail. So we use a trick to only set the
|
||||
# flags in gcc-wrapper.
|
||||
hook=$(pwd)/ld-wrapper-hook
|
||||
echo "NIX_GLIBC_FLAGS_SET=1" > $hook
|
||||
export NIX_LD_WRAPPER_START_HOOK=$hook
|
||||
fi
|
||||
|
||||
export NIX_EXTRA_CFLAGS=$extraCFlags
|
||||
export NIX_EXTRA_LDFLAGS=$extraLDFlags
|
||||
export CFLAGS=$extraCFlags
|
||||
export CXXFLAGS=$extraCFlags
|
||||
export LDFLAGS=$extraLDFlags
|
||||
fi
|
||||
|
||||
else
|
||||
patches=""
|
||||
fi
|
||||
|
||||
|
||||
preConfigure=preConfigure
|
||||
preConfigure() {
|
||||
|
||||
# Determine the frontends to build.
|
||||
langs="c"
|
||||
if test -n "$langCC"; then
|
||||
langs="$langs,c++"
|
||||
fi
|
||||
if test -n "$langF77"; then
|
||||
langs="$langs,f77"
|
||||
fi
|
||||
|
||||
# Cross compiler evilness
|
||||
mkdir -p $out
|
||||
mkdir -p $out/arm-linux
|
||||
mkdir -p $out/arm-linux/bin
|
||||
ln -s $binutilsArm/arm-linux/bin/as $out/arm-linux/bin/as
|
||||
ln -s $binutilsArm/arm-linux/bin/ld $out/arm-linux/bin/ld
|
||||
ln -s $binutilsArm/arm-linux/bin/ar $out/arm-linux/bin/ar
|
||||
ln -s $binutilsArm/arm-linux/bin/ranlib $out/arm-linux/bin/ranlib
|
||||
|
||||
# Perform the build in a different directory.
|
||||
mkdir ../build
|
||||
cd ../build
|
||||
|
||||
configureScript=../$sourceRoot/configure
|
||||
configureFlags="--enable-languages=$langs --target=$platform --disable-threads --disable-libmudflap --disable-shared --with-headers=$kernelHeadersArm/include --disable-multilib"
|
||||
}
|
||||
|
||||
|
||||
postInstall=postInstall
|
||||
postInstall() {
|
||||
# Remove precompiled headers for now. They are very big and
|
||||
# probably not very useful yet.
|
||||
find $out/include -name "*.gch" -exec rm -rf {} \; -prune
|
||||
|
||||
# Remove `fixincl' to prevent a retained dependency on the
|
||||
# previous gcc.
|
||||
rm -rf $out/libexec/gcc/*/*/install-tools
|
||||
}
|
||||
|
||||
|
||||
#if test -z "$profiledCompiler"; then
|
||||
#makeFlags="bootstrap"
|
||||
#else
|
||||
#makeFlags="profiledbootstrap"
|
||||
#fi
|
||||
|
||||
genericBuild
|
||||
---
|
||||
|
||||
Step 4: build a C library for the target platform.
|
||||
|
||||
The previous steps are enough to compile a C library. In our case we take
|
||||
uClibc. It's intended to be a small sized replacement for glibc. It is widely
|
||||
used in embedded environments.
|
||||
|
||||
...
|
||||
|
||||
Step 5: Build a compiler to link with the newly built C library.
|
||||
|
||||
...
|
||||
|
||||
If we restrict the compiler to just C programs it is relatively easy,
|
||||
since we only need to wrap the GCC we built in the previous step with all
|
||||
the right tools and the right C library. Successfully compiled programs with
|
||||
this compiler and verified to be working on a HP Jornada 820 running Linux
|
||||
are "patch", "make" and "wget".
|
||||
|
||||
If we want to build C++ programs it gets a lot more difficult. GCC has a
|
||||
three step compilation process. In the first step a simple compiler, called
|
||||
xgcc, that can compile only C programs is built. With that compiler it
|
||||
compiles itself two more times: one time to build a full compiler, and another
|
||||
time to build a full compiler once again with the freshly built compiler from
|
||||
step 2. In the second and third step support for C++ is compiled, if this
|
||||
is configured.
|
||||
|
||||
One of the libraries that has to be built for C++ support step is libstdc++.
|
||||
This library uses xgcc, even when cross compiling, since libstdc++ has to be
|
||||
compiled for arm-linux.
|
||||
|
||||
One of the compiler flags that GCC uses for this compiler is called X_CFLAGS.
|
||||
This is used by the Nix build process to set the dynamic linker, glibc
|
||||
in the case of i686-linux using the default Nix packages collection.
|
||||
|
||||
Obiously, since we need to compile libstc++ for arm-linux with uClibc linking
|
||||
will not be done correctly: you can't link object files built for arm-linux
|
||||
with a glibc built for i686-linux.
|
||||
|
||||
Setting X_CFLAGS to use the uClibc libraries and dynamic linker will fail
|
||||
too. Earlier on in the build process these flags are used to compile important
|
||||
files like libgcc.a by the host system gcc, which does need to be linked
|
||||
to glibc. To make this work correctly you will need to carefully juggle
|
||||
with compilation flags. This is still work in progress for Nix.
|
||||
|
||||
|
||||
---
|
||||
|
||||
After successfully completing the whole toolchain you can start building
|
||||
packages with the newly built tools. To make everything build correctly
|
||||
you will need a stdenv for your target platform. Setting up this platform
|
||||
will take some effort. Right now there is a very experimental setup for
|
||||
arm-linux, which needs to be cleaned up before it is production ready.
|
||||
|
||||
Please note that many packages are not well suited for cross-compilation.
|
||||
Even though the package itself might be very well portable often the
|
||||
buildscripts are not. One thing that we have seen that causes frequent
|
||||
build failures is the use of the LD variable. This is often set to 'ld'
|
||||
and not $(CROSS)-ld.
|
||||
195
doc/overlays.xml
195
doc/overlays.xml
@@ -1,195 +0,0 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="chap-overlays">
|
||||
<title>Overlays</title>
|
||||
<para>
|
||||
This chapter describes how to extend and change Nixpkgs using overlays.
|
||||
Overlays are used to add layers in the fixed-point used by Nixpkgs to compose
|
||||
the set of all packages.
|
||||
</para>
|
||||
<para>
|
||||
Nixpkgs can be configured with a list of overlays, which are applied in
|
||||
order. This means that the order of the overlays can be significant if
|
||||
multiple layers override the same package.
|
||||
</para>
|
||||
<!--============================================================-->
|
||||
<section xml:id="sec-overlays-install">
|
||||
<title>Installing overlays</title>
|
||||
|
||||
<para>
|
||||
The list of overlays can be set either explicitly in a Nix expression, or
|
||||
through <literal><nixpkgs-overlays></literal> or user configuration
|
||||
files.
|
||||
</para>
|
||||
|
||||
<section xml:id="sec-overlays-argument">
|
||||
<title>Set overlays in NixOS or Nix expressions</title>
|
||||
|
||||
<para>
|
||||
On a NixOS system the value of the <literal>nixpkgs.overlays</literal>
|
||||
option, if present, is passed to the system Nixpkgs directly as an
|
||||
argument. Note that this does not affect the overlays for non-NixOS
|
||||
operations (e.g. <literal>nix-env</literal>), which are
|
||||
<link xlink:href="#sec-overlays-lookup">looked</link> up independently.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The list of overlays can be passed explicitly when importing nixpkgs, for
|
||||
example <literal>import <nixpkgs> { overlays = [ overlay1 overlay2 ];
|
||||
}</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Further overlays can be added by calling the <literal>pkgs.extend</literal>
|
||||
or <literal>pkgs.appendOverlays</literal>, although it is often preferable
|
||||
to avoid these functions, because they recompute the Nixpkgs fixpoint,
|
||||
which is somewhat expensive to do.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-overlays-lookup">
|
||||
<title>Install overlays via configuration lookup</title>
|
||||
|
||||
<para>
|
||||
The list of overlays is determined as follows.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
First, if an
|
||||
<link xlink:href="#sec-overlays-argument"><varname>overlays</varname>
|
||||
argument</link> to the Nixpkgs function itself is given, then that is
|
||||
used and no path lookup will be performed.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Otherwise, if the Nix path entry
|
||||
<literal><nixpkgs-overlays></literal> exists, we look for overlays at
|
||||
that path, as described below.
|
||||
</para>
|
||||
<para>
|
||||
See the section on <literal>NIX_PATH</literal> in the Nix manual for
|
||||
more details on how to set a value for
|
||||
<literal><nixpkgs-overlays>.</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If one of <filename>~/.config/nixpkgs/overlays.nix</filename> and
|
||||
<filename>~/.config/nixpkgs/overlays/</filename> exists, then we look
|
||||
for overlays at that path, as described below. It is an error if both
|
||||
exist.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If we are looking for overlays at a path, then there are two cases:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
If the path is a file, then the file is imported as a Nix expression and
|
||||
used as the list of overlays.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If the path is a directory, then we take the content of the directory,
|
||||
order it lexicographically, and attempt to interpret each as an overlay
|
||||
by:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Importing the file, if it is a <literal>.nix</literal> file.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Importing a top-level <filename>default.nix</filename> file, if it is
|
||||
a directory.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Because overlays that are set in NixOS configuration do not affect
|
||||
non-NixOS operations such as <literal>nix-env</literal>, the
|
||||
<filename>overlays.nix</filename> option provides a convenient way to use
|
||||
the same overlays for a NixOS system configuration and user configuration:
|
||||
the same file can be used as <filename>overlays.nix</filename> and imported
|
||||
as the value of <literal>nixpkgs.overlays</literal>.
|
||||
</para>
|
||||
|
||||
<!-- TODO: Example of sharing overlays between NixOS configuration
|
||||
and configuration lookup. Also reference the example
|
||||
from the sec-overlays-argument paragraph about NixOS.
|
||||
-->
|
||||
</section>
|
||||
</section>
|
||||
<!--============================================================-->
|
||||
<section xml:id="sec-overlays-definition">
|
||||
<title>Defining overlays</title>
|
||||
|
||||
<para>
|
||||
Overlays are Nix functions which accept two arguments, conventionally called
|
||||
<varname>self</varname> and <varname>super</varname>, and return a set of
|
||||
packages. For example, the following is a valid overlay.
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
self: super:
|
||||
|
||||
{
|
||||
boost = super.boost.override {
|
||||
python = self.python3;
|
||||
};
|
||||
rr = super.callPackage ./pkgs/rr {
|
||||
stdenv = self.stdenv_32bit;
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
The first argument (<varname>self</varname>) corresponds to the final
|
||||
package set. You should use this set for the dependencies of all packages
|
||||
specified in your overlay. For example, all the dependencies of
|
||||
<varname>rr</varname> in the example above come from
|
||||
<varname>self</varname>, as well as the overridden dependencies used in the
|
||||
<varname>boost</varname> override.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The second argument (<varname>super</varname>) corresponds to the result of
|
||||
the evaluation of the previous stages of Nixpkgs. It does not contain any of
|
||||
the packages added by the current overlay, nor any of the following
|
||||
overlays. This set should be used either to refer to packages you wish to
|
||||
override, or to access functions defined in Nixpkgs. For example, the
|
||||
original recipe of <varname>boost</varname> in the above example, comes from
|
||||
<varname>super</varname>, as well as the <varname>callPackage</varname>
|
||||
function.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The value returned by this function should be a set similar to
|
||||
<filename>pkgs/top-level/all-packages.nix</filename>, containing overridden
|
||||
and/or new packages.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Overlays are similar to other methods for customizing Nixpkgs, in particular
|
||||
the <literal>packageOverrides</literal> attribute described in
|
||||
<xref linkend="sec-modify-via-packageOverrides"/>. Indeed,
|
||||
<literal>packageOverrides</literal> acts as an overlay with only the
|
||||
<varname>super</varname> argument. It is therefore appropriate for basic
|
||||
use, but overlays are more powerful and easier to distribute.
|
||||
</para>
|
||||
</section>
|
||||
</chapter>
|
||||
@@ -1,9 +0,0 @@
|
||||
.docbook .xref img[src^=images\/callouts\/],
|
||||
.screen img,
|
||||
.programlisting img {
|
||||
width: 1em;
|
||||
}
|
||||
|
||||
.calloutlist img {
|
||||
width: 1.5em;
|
||||
}
|
||||
@@ -1,916 +0,0 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="chap-package-notes">
|
||||
<title>Package Notes</title>
|
||||
<para>
|
||||
This chapter contains information about how to use and maintain the Nix
|
||||
expressions for a number of specific packages, such as the Linux kernel or
|
||||
X.org.
|
||||
</para>
|
||||
<!--============================================================-->
|
||||
<section xml:id="sec-linux-kernel">
|
||||
<title>Linux kernel</title>
|
||||
|
||||
<para>
|
||||
The Nix expressions to build the Linux kernel are in
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel"><filename>pkgs/os-specific/linux/kernel</filename></link>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The function that builds the kernel has an argument
|
||||
<varname>kernelPatches</varname> which should be a list of <literal>{name,
|
||||
patch, extraConfig}</literal> attribute sets, where <varname>name</varname>
|
||||
is the name of the patch (which is included in the kernel’s
|
||||
<varname>meta.description</varname> attribute), <varname>patch</varname> is
|
||||
the patch itself (possibly compressed), and <varname>extraConfig</varname>
|
||||
(optional) is a string specifying extra options to be concatenated to the
|
||||
kernel configuration file (<filename>.config</filename>).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The kernel derivation exports an attribute <varname>features</varname>
|
||||
specifying whether optional functionality is or isn’t enabled. This is
|
||||
used in NixOS to implement kernel-specific behaviour. For instance, if the
|
||||
kernel has the <varname>iwlwifi</varname> feature (i.e. has built-in support
|
||||
for Intel wireless chipsets), then NixOS doesn’t have to build the
|
||||
external <varname>iwlwifi</varname> package:
|
||||
<programlisting>
|
||||
modulesTree = [kernel]
|
||||
++ pkgs.lib.optional (!kernel.features ? iwlwifi) kernelPackages.iwlwifi
|
||||
++ ...;
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
How to add a new (major) version of the Linux kernel to Nixpkgs:
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Copy the old Nix expression (e.g. <filename>linux-2.6.21.nix</filename>)
|
||||
to the new one (e.g. <filename>linux-2.6.22.nix</filename>) and update
|
||||
it.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Add the new kernel to <filename>all-packages.nix</filename> (e.g., create
|
||||
an attribute <varname>kernel_2_6_22</varname>).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Now we’re going to update the kernel configuration. First unpack the
|
||||
kernel. Then for each supported platform (<literal>i686</literal>,
|
||||
<literal>x86_64</literal>, <literal>uml</literal>) do the following:
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Make an copy from the old config (e.g.
|
||||
<filename>config-2.6.21-i686-smp</filename>) to the new one (e.g.
|
||||
<filename>config-2.6.22-i686-smp</filename>).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Copy the config file for this platform (e.g.
|
||||
<filename>config-2.6.22-i686-smp</filename>) to
|
||||
<filename>.config</filename> in the kernel source tree.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Run <literal>make oldconfig
|
||||
ARCH=<replaceable>{i386,x86_64,um}</replaceable></literal> and answer
|
||||
all questions. (For the uml configuration, also add
|
||||
<literal>SHELL=bash</literal>.) Make sure to keep the configuration
|
||||
consistent between platforms (i.e. don’t enable some feature on
|
||||
<literal>i686</literal> and disable it on <literal>x86_64</literal>).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If needed you can also run <literal>make menuconfig</literal>:
|
||||
<screen>
|
||||
$ nix-env -i ncurses
|
||||
$ export NIX_CFLAGS_LINK=-lncurses
|
||||
$ make menuconfig ARCH=<replaceable>arch</replaceable></screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Copy <filename>.config</filename> over the new config file (e.g.
|
||||
<filename>config-2.6.22-i686-smp</filename>).
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Test building the kernel: <literal>nix-build -A kernel_2_6_22</literal>.
|
||||
If it compiles, ship it! For extra credit, try booting NixOS with it.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
It may be that the new kernel requires updating the external kernel
|
||||
modules and kernel-dependent packages listed in the
|
||||
<varname>linuxPackagesFor</varname> function in
|
||||
<filename>all-packages.nix</filename> (such as the NVIDIA drivers, AUFS,
|
||||
etc.). If the updated packages aren’t backwards compatible with older
|
||||
kernels, you may need to keep the older versions around.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
<!--============================================================-->
|
||||
<section xml:id="sec-xorg">
|
||||
<title>X.org</title>
|
||||
|
||||
<para>
|
||||
The Nix expressions for the X.org packages reside in
|
||||
<filename>pkgs/servers/x11/xorg/default.nix</filename>. This file is
|
||||
automatically generated from lists of tarballs in an X.org release. As such
|
||||
it should not be modified directly; rather, you should modify the lists, the
|
||||
generator script or the file
|
||||
<filename>pkgs/servers/x11/xorg/overrides.nix</filename>, in which you can
|
||||
override or add to the derivations produced by the generator.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The generator is invoked as follows:
|
||||
<screen>
|
||||
$ cd pkgs/servers/x11/xorg
|
||||
$ cat tarballs-7.5.list extra.list old.list \
|
||||
| perl ./generate-expr-from-tarballs.pl
|
||||
</screen>
|
||||
For each of the tarballs in the <filename>.list</filename> files, the script
|
||||
downloads it, unpacks it, and searches its <filename>configure.ac</filename>
|
||||
and <filename>*.pc.in</filename> files for dependencies. This information is
|
||||
used to generate <filename>default.nix</filename>. The generator caches
|
||||
downloaded tarballs between runs. Pay close attention to the <literal>NOT
|
||||
FOUND: <replaceable>name</replaceable></literal> messages at the end of the
|
||||
run, since they may indicate missing dependencies. (Some might be optional
|
||||
dependencies, however.)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A file like <filename>tarballs-7.5.list</filename> contains all tarballs in
|
||||
a X.org release. It can be generated like this:
|
||||
<screen>
|
||||
$ export i="mirror://xorg/X11R7.4/src/everything/"
|
||||
$ cat $(PRINT_PATH=1 nix-prefetch-url $i | tail -n 1) \
|
||||
| perl -e 'while (<>) { if (/(href|HREF)="([^"]*.bz2)"/) { print "$ENV{'i'}$2\n"; }; }' \
|
||||
| sort > tarballs-7.4.list
|
||||
</screen>
|
||||
<filename>extra.list</filename> contains libraries that aren’t part of
|
||||
X.org proper, but are closely related to it, such as
|
||||
<literal>libxcb</literal>. <filename>old.list</filename> contains some
|
||||
packages that were removed from X.org, but are still needed by some people
|
||||
or by other packages (such as <varname>imake</varname>).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If the expression for a package requires derivation attributes that the
|
||||
generator cannot figure out automatically (say, <varname>patches</varname>
|
||||
or a <varname>postInstall</varname> hook), you should modify
|
||||
<filename>pkgs/servers/x11/xorg/overrides.nix</filename>.
|
||||
</para>
|
||||
</section>
|
||||
<!--============================================================-->
|
||||
<!--
|
||||
<section xml:id="sec-package-notes-gnome">
|
||||
<title>Gnome</title>
|
||||
<para>* Expression is auto-generated</para>
|
||||
<para>* How to update</para>
|
||||
</section>
|
||||
-->
|
||||
<!--============================================================-->
|
||||
<!--
|
||||
<section xml:id="sec-package-notes-gcc">
|
||||
<title>GCC</title>
|
||||
<para>…</para>
|
||||
</section>
|
||||
-->
|
||||
<!--============================================================-->
|
||||
<section xml:id="sec-eclipse">
|
||||
<title>Eclipse</title>
|
||||
|
||||
<para>
|
||||
The Nix expressions related to the Eclipse platform and IDE are in
|
||||
<link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/eclipse"><filename>pkgs/applications/editors/eclipse</filename></link>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Nixpkgs provides a number of packages that will install Eclipse in its
|
||||
various forms. These range from the bare-bones Eclipse Platform to the more
|
||||
fully featured Eclipse SDK or Scala-IDE packages and multiple version are
|
||||
often available. It is possible to list available Eclipse packages by
|
||||
issuing the command:
|
||||
<screen>
|
||||
$ nix-env -f '<nixpkgs>' -qaP -A eclipses --description
|
||||
</screen>
|
||||
Once an Eclipse variant is installed it can be run using the
|
||||
<command>eclipse</command> command, as expected. From within Eclipse it is
|
||||
then possible to install plugins in the usual manner by either manually
|
||||
specifying an Eclipse update site or by installing the Marketplace Client
|
||||
plugin and using it to discover and install other plugins. This installation
|
||||
method provides an Eclipse installation that closely resemble a manually
|
||||
installed Eclipse.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you prefer to install plugins in a more declarative manner then Nixpkgs
|
||||
also offer a number of Eclipse plugins that can be installed in an
|
||||
<emphasis>Eclipse environment</emphasis>. This type of environment is
|
||||
created using the function <varname>eclipseWithPlugins</varname> found
|
||||
inside the <varname>nixpkgs.eclipses</varname> attribute set. This function
|
||||
takes as argument <literal>{ eclipse, plugins ? [], jvmArgs ? [] }</literal>
|
||||
where <varname>eclipse</varname> is a one of the Eclipse packages described
|
||||
above, <varname>plugins</varname> is a list of plugin derivations, and
|
||||
<varname>jvmArgs</varname> is a list of arguments given to the JVM running
|
||||
the Eclipse. For example, say you wish to install the latest Eclipse
|
||||
Platform with the popular Eclipse Color Theme plugin and also allow Eclipse
|
||||
to use more RAM. You could then add
|
||||
<screen>
|
||||
packageOverrides = pkgs: {
|
||||
myEclipse = with pkgs.eclipses; eclipseWithPlugins {
|
||||
eclipse = eclipse-platform;
|
||||
jvmArgs = [ "-Xmx2048m" ];
|
||||
plugins = [ plugins.color-theme ];
|
||||
};
|
||||
}
|
||||
</screen>
|
||||
to your Nixpkgs configuration
|
||||
(<filename>~/.config/nixpkgs/config.nix</filename>) and install it by
|
||||
running <command>nix-env -f '<nixpkgs>' -iA myEclipse</command> and
|
||||
afterward run Eclipse as usual. It is possible to find out which plugins are
|
||||
available for installation using <varname>eclipseWithPlugins</varname> by
|
||||
running
|
||||
<screen>
|
||||
$ nix-env -f '<nixpkgs>' -qaP -A eclipses.plugins --description
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If there is a need to install plugins that are not available in Nixpkgs then
|
||||
it may be possible to define these plugins outside Nixpkgs using the
|
||||
<varname>buildEclipseUpdateSite</varname> and
|
||||
<varname>buildEclipsePlugin</varname> functions found in the
|
||||
<varname>nixpkgs.eclipses.plugins</varname> attribute set. Use the
|
||||
<varname>buildEclipseUpdateSite</varname> function to install a plugin
|
||||
distributed as an Eclipse update site. This function takes <literal>{ name,
|
||||
src }</literal> as argument where <literal>src</literal> indicates the
|
||||
Eclipse update site archive. All Eclipse features and plugins within the
|
||||
downloaded update site will be installed. When an update site archive is not
|
||||
available then the <varname>buildEclipsePlugin</varname> function can be
|
||||
used to install a plugin that consists of a pair of feature and plugin JARs.
|
||||
This function takes an argument <literal>{ name, srcFeature, srcPlugin
|
||||
}</literal> where <literal>srcFeature</literal> and
|
||||
<literal>srcPlugin</literal> are the feature and plugin JARs, respectively.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Expanding the previous example with two plugins using the above functions we
|
||||
have
|
||||
<screen>
|
||||
packageOverrides = pkgs: {
|
||||
myEclipse = with pkgs.eclipses; eclipseWithPlugins {
|
||||
eclipse = eclipse-platform;
|
||||
jvmArgs = [ "-Xmx2048m" ];
|
||||
plugins = [
|
||||
plugins.color-theme
|
||||
(plugins.buildEclipsePlugin {
|
||||
name = "myplugin1-1.0";
|
||||
srcFeature = fetchurl {
|
||||
url = "http://…/features/myplugin1.jar";
|
||||
sha256 = "123…";
|
||||
};
|
||||
srcPlugin = fetchurl {
|
||||
url = "http://…/plugins/myplugin1.jar";
|
||||
sha256 = "123…";
|
||||
};
|
||||
});
|
||||
(plugins.buildEclipseUpdateSite {
|
||||
name = "myplugin2-1.0";
|
||||
src = fetchurl {
|
||||
stripRoot = false;
|
||||
url = "http://…/myplugin2.zip";
|
||||
sha256 = "123…";
|
||||
};
|
||||
});
|
||||
];
|
||||
};
|
||||
}
|
||||
</screen>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-elm">
|
||||
<title>Elm</title>
|
||||
|
||||
<para>
|
||||
To update Elm compiler, see <filename>nixpkgs/pkgs/development/compilers/elm/README.md</filename>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To package Elm applications, <link xlink:href="https://github.com/hercules-ci/elm2nix#elm2nix">read about elm2nix</link>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-shell-helpers">
|
||||
<title>Interactive shell helpers</title>
|
||||
|
||||
<para>
|
||||
Some packages provide the shell integration to be more useful. But unlike
|
||||
other systems, nix doesn't have a standard share directory location. This is
|
||||
why a bunch <command>PACKAGE-share</command> scripts are shipped that print
|
||||
the location of the corresponding shared folder. Current list of such
|
||||
packages is as following:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>autojump</literal>: <command>autojump-share</command>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>fzf</literal>: <command>fzf-share</command>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
E.g. <literal>autojump</literal> can then used in the .bashrc like this:
|
||||
<screen>
|
||||
source "$(autojump-share)/autojump.bash"
|
||||
</screen>
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="sec-steam">
|
||||
<title>Steam</title>
|
||||
|
||||
<section xml:id="sec-steam-nix">
|
||||
<title>Steam in Nix</title>
|
||||
|
||||
<para>
|
||||
Steam is distributed as a <filename>.deb</filename> file, for now only as
|
||||
an i686 package (the amd64 package only has documentation). When unpacked,
|
||||
it has a script called <filename>steam</filename> that in ubuntu (their
|
||||
target distro) would go to <filename>/usr/bin </filename>. When run for the
|
||||
first time, this script copies some files to the user's home, which include
|
||||
another script that is the ultimate responsible for launching the steam
|
||||
binary, which is also in $HOME.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Nix problems and constraints:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
We don't have <filename>/bin/bash</filename> and many scripts point
|
||||
there. Similarly for <filename>/usr/bin/python</filename> .
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
We don't have the dynamic loader in <filename>/lib </filename>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The <filename>steam.sh</filename> script in $HOME can not be patched, as
|
||||
it is checked and rewritten by steam.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The steam binary cannot be patched, it's also checked.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The current approach to deploy Steam in NixOS is composing a FHS-compatible
|
||||
chroot environment, as documented
|
||||
<link xlink:href="http://sandervanderburg.blogspot.nl/2013/09/composing-fhs-compatible-chroot.html">here</link>.
|
||||
This allows us to have binaries in the expected paths without disrupting
|
||||
the system, and to avoid patching them to work in a non FHS environment.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-steam-play">
|
||||
<title>How to play</title>
|
||||
|
||||
<para>
|
||||
For 64-bit systems it's important to have
|
||||
<programlisting>hardware.opengl.driSupport32Bit = true;</programlisting>
|
||||
in your <filename>/etc/nixos/configuration.nix</filename>. You'll also need
|
||||
<programlisting>hardware.pulseaudio.support32Bit = true;</programlisting>
|
||||
if you are using PulseAudio - this will enable 32bit ALSA apps integration.
|
||||
To use the Steam controller or other Steam supported controllers such as
|
||||
the DualShock 4 or Nintendo Switch Pro, you need to add
|
||||
<programlisting>hardware.steam-hardware.enable = true;</programlisting>
|
||||
to your configuration.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-steam-troub">
|
||||
<title>Troubleshooting</title>
|
||||
|
||||
<para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
Steam fails to start. What do I do?
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Try to run
|
||||
<programlisting>strace steam</programlisting>
|
||||
to see what is causing steam to fail.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
Using the FOSS Radeon or nouveau (nvidia) drivers
|
||||
</term>
|
||||
<listitem>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
The <literal>newStdcpp</literal> parameter was removed since NixOS
|
||||
17.09 and should not be needed anymore.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Steam ships statically linked with a version of libcrypto that
|
||||
conflics with the one dynamically loaded by radeonsi_dri.so. If you
|
||||
get the error
|
||||
<programlisting>steam.sh: line 713: 7842 Segmentation fault (core dumped)</programlisting>
|
||||
have a look at
|
||||
<link xlink:href="https://github.com/NixOS/nixpkgs/pull/20269">this
|
||||
pull request</link>.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
Java
|
||||
</term>
|
||||
<listitem>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
There is no java in steam chrootenv by default. If you get a message
|
||||
like
|
||||
<programlisting>/home/foo/.local/share/Steam/SteamApps/common/towns/towns.sh: line 1: java: command not found</programlisting>
|
||||
You need to add
|
||||
<programlisting> steam.override { withJava = true; };</programlisting>
|
||||
to your configuration.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-steam-run">
|
||||
<title>steam-run</title>
|
||||
|
||||
<para>
|
||||
The FHS-compatible chroot used for steam can also be used to run other
|
||||
linux games that expect a FHS environment. To do it, add
|
||||
<programlisting>pkgs.(steam.override {
|
||||
nativeOnly = true;
|
||||
newStdcpp = true;
|
||||
}).run</programlisting>
|
||||
to your configuration, rebuild, and run the game with
|
||||
<programlisting>steam-run ./foo</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="sec-emacs">
|
||||
<title>Emacs</title>
|
||||
|
||||
<section xml:id="sec-emacs-config">
|
||||
<title>Configuring Emacs</title>
|
||||
|
||||
<para>
|
||||
The Emacs package comes with some extra helpers to make it easier to
|
||||
configure. <varname>emacsWithPackages</varname> allows you to manage
|
||||
packages from ELPA. This means that you will not have to install that
|
||||
packages from within Emacs. For instance, if you wanted to use
|
||||
<literal>company</literal>, <literal>counsel</literal>,
|
||||
<literal>flycheck</literal>, <literal>ivy</literal>,
|
||||
<literal>magit</literal>, <literal>projectile</literal>, and
|
||||
<literal>use-package</literal> you could use this as a
|
||||
<filename>~/.config/nixpkgs/config.nix</filename> override:
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
{
|
||||
packageOverrides = pkgs: with pkgs; {
|
||||
myEmacs = emacsWithPackages (epkgs: (with epkgs.melpaStablePackages; [
|
||||
company
|
||||
counsel
|
||||
flycheck
|
||||
ivy
|
||||
magit
|
||||
projectile
|
||||
use-package
|
||||
]));
|
||||
}
|
||||
}
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
You can install it like any other packages via <command>nix-env -iA
|
||||
myEmacs</command>. However, this will only install those packages. It will
|
||||
not <literal>configure</literal> them for us. To do this, we need to
|
||||
provide a configuration file. Luckily, it is possible to do this from
|
||||
within Nix! By modifying the above example, we can make Emacs load a custom
|
||||
config file. The key is to create a package that provide a
|
||||
<filename>default.el</filename> file in
|
||||
<filename>/share/emacs/site-start/</filename>. Emacs knows to load this
|
||||
file automatically when it starts.
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
{
|
||||
packageOverrides = pkgs: with pkgs; rec {
|
||||
myEmacsConfig = writeText "default.el" ''
|
||||
;; initialize package
|
||||
|
||||
(require 'package)
|
||||
(package-initialize 'noactivate)
|
||||
(eval-when-compile
|
||||
(require 'use-package))
|
||||
|
||||
;; load some packages
|
||||
|
||||
(use-package company
|
||||
:bind ("<C-tab>" . company-complete)
|
||||
:diminish company-mode
|
||||
:commands (company-mode global-company-mode)
|
||||
:defer 1
|
||||
:config
|
||||
(global-company-mode))
|
||||
|
||||
(use-package counsel
|
||||
:commands (counsel-descbinds)
|
||||
:bind (([remap execute-extended-command] . counsel-M-x)
|
||||
("C-x C-f" . counsel-find-file)
|
||||
("C-c g" . counsel-git)
|
||||
("C-c j" . counsel-git-grep)
|
||||
("C-c k" . counsel-ag)
|
||||
("C-x l" . counsel-locate)
|
||||
("M-y" . counsel-yank-pop)))
|
||||
|
||||
(use-package flycheck
|
||||
:defer 2
|
||||
:config (global-flycheck-mode))
|
||||
|
||||
(use-package ivy
|
||||
:defer 1
|
||||
:bind (("C-c C-r" . ivy-resume)
|
||||
("C-x C-b" . ivy-switch-buffer)
|
||||
:map ivy-minibuffer-map
|
||||
("C-j" . ivy-call))
|
||||
:diminish ivy-mode
|
||||
:commands ivy-mode
|
||||
:config
|
||||
(ivy-mode 1))
|
||||
|
||||
(use-package magit
|
||||
:defer
|
||||
:if (executable-find "git")
|
||||
:bind (("C-x g" . magit-status)
|
||||
("C-x G" . magit-dispatch-popup))
|
||||
:init
|
||||
(setq magit-completing-read-function 'ivy-completing-read))
|
||||
|
||||
(use-package projectile
|
||||
:commands projectile-mode
|
||||
:bind-keymap ("C-c p" . projectile-command-map)
|
||||
:defer 5
|
||||
:config
|
||||
(projectile-global-mode))
|
||||
'';
|
||||
myEmacs = emacsWithPackages (epkgs: (with epkgs.melpaStablePackages; [
|
||||
(runCommand "default.el" {} ''
|
||||
mkdir -p $out/share/emacs/site-lisp
|
||||
cp ${myEmacsConfig} $out/share/emacs/site-lisp/default.el
|
||||
'')
|
||||
company
|
||||
counsel
|
||||
flycheck
|
||||
ivy
|
||||
magit
|
||||
projectile
|
||||
use-package
|
||||
]));
|
||||
};
|
||||
}
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
This provides a fairly full Emacs start file. It will load in addition to
|
||||
the user's presonal config. You can always disable it by passing
|
||||
<command>-q</command> to the Emacs command.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Sometimes <varname>emacsWithPackages</varname> is not enough, as this
|
||||
package set has some priorities imposed on packages (with the lowest
|
||||
priority assigned to Melpa Unstable, and the highest for packages manually
|
||||
defined in <filename>pkgs/top-level/emacs-packages.nix</filename>). But you
|
||||
can't control this priorities when some package is installed as a
|
||||
dependency. You can override it on per-package-basis, providing all the
|
||||
required dependencies manually - but it's tedious and there is always a
|
||||
possibility that an unwanted dependency will sneak in through some other
|
||||
package. To completely override such a package you can use
|
||||
<varname>overrideScope'</varname>.
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
overrides = self: super: rec {
|
||||
haskell-mode = self.melpaPackages.haskell-mode;
|
||||
...
|
||||
};
|
||||
((emacsPackagesNgGen emacs).overrideScope' overrides).emacsWithPackages (p: with p; [
|
||||
# here both these package will use haskell-mode of our own choice
|
||||
ghc-mod
|
||||
dante
|
||||
])
|
||||
</screen>
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="sec-weechat">
|
||||
<title>Weechat</title>
|
||||
|
||||
<para>
|
||||
Weechat can be configured to include your choice of plugins, reducing its
|
||||
closure size from the default configuration which includes all available
|
||||
plugins. To make use of this functionality, install an expression that
|
||||
overrides its configuration such as
|
||||
<programlisting>weechat.override {configure = {availablePlugins, ...}: {
|
||||
plugins = with availablePlugins; [ python perl ];
|
||||
}
|
||||
}</programlisting>
|
||||
If the <literal>configure</literal> function returns an attrset without the
|
||||
<literal>plugins</literal> attribute, <literal>availablePlugins</literal>
|
||||
will be used automatically.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The plugins currently available are <literal>python</literal>,
|
||||
<literal>perl</literal>, <literal>ruby</literal>, <literal>guile</literal>,
|
||||
<literal>tcl</literal> and <literal>lua</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The python and perl plugins allows the addition of extra libraries. For
|
||||
instance, the <literal>inotify.py</literal> script in weechat-scripts
|
||||
requires D-Bus or libnotify, and the <literal>fish.py</literal> script
|
||||
requires pycrypto. To use these scripts, use the plugin's
|
||||
<literal>withPackages</literal> attribute:
|
||||
<programlisting>weechat.override { configure = {availablePlugins, ...}: {
|
||||
plugins = with availablePlugins; [
|
||||
(python.withPackages (ps: with ps; [ pycrypto python-dbus ]))
|
||||
];
|
||||
};
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In order to also keep all default plugins installed, it is possible to use
|
||||
the following method:
|
||||
<programlisting>weechat.override { configure = { availablePlugins, ... }: {
|
||||
plugins = builtins.attrValues (availablePlugins // {
|
||||
python = availablePlugins.python.withPackages (ps: with ps; [ pycrypto python-dbus ]);
|
||||
});
|
||||
}; }
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
WeeChat allows to set defaults on startup using the
|
||||
<literal>--run-command</literal>. The <literal>configure</literal> method
|
||||
can be used to pass commands to the program:
|
||||
<programlisting>weechat.override {
|
||||
configure = { availablePlugins, ... }: {
|
||||
init = ''
|
||||
/set foo bar
|
||||
/server add freenode chat.freenode.org
|
||||
'';
|
||||
};
|
||||
}</programlisting>
|
||||
Further values can be added to the list of commands when running
|
||||
<literal>weechat --run-command "your-commands"</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Additionally it's possible to specify scripts to be loaded when starting
|
||||
<literal>weechat</literal>. These will be loaded before the commands from
|
||||
<literal>init</literal>:
|
||||
<programlisting>weechat.override {
|
||||
configure = { availablePlugins, ... }: {
|
||||
scripts = with pkgs.weechatScripts; [
|
||||
weechat-xmpp weechat-matrix-bridge wee-slack
|
||||
];
|
||||
init = ''
|
||||
/set plugins.var.python.jabber.key "val"
|
||||
'':
|
||||
};
|
||||
}</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In <literal>nixpkgs</literal> there's a subpackage which contains
|
||||
derivations for WeeChat scripts. Such derivations expect a
|
||||
<literal>passthru.scripts</literal> attribute which contains a list of all
|
||||
scripts inside the store path. Furthermore all scripts have to live in
|
||||
<literal>$out/share</literal>. An exemplary derivation looks like this:
|
||||
<programlisting>{ stdenv, fetchurl }:
|
||||
|
||||
stdenv.mkDerivation {
|
||||
name = "exemplary-weechat-script";
|
||||
src = fetchurl {
|
||||
url = "https://scripts.tld/your-scripts.tar.gz";
|
||||
sha256 = "...";
|
||||
};
|
||||
passthru.scripts = [ "foo.py" "bar.lua" ];
|
||||
installPhase = ''
|
||||
mkdir $out/share
|
||||
cp foo.py $out/share
|
||||
cp bar.lua $out/share
|
||||
'';
|
||||
}</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="sec-citrix">
|
||||
<title>Citrix Receiver</title>
|
||||
|
||||
<para>
|
||||
The <link xlink:href="https://www.citrix.com/products/receiver/">Citrix
|
||||
Receiver</link> is a remote desktop viewer which provides access to
|
||||
<link xlink:href="https://www.citrix.com/products/xenapp-xendesktop/">XenDesktop</link>
|
||||
installations.
|
||||
</para>
|
||||
|
||||
<section xml:id="sec-citrix-base">
|
||||
<title>Basic usage</title>
|
||||
|
||||
<para>
|
||||
The tarball archive needs to be downloaded manually as the licenses
|
||||
agreements of the vendor need to be accepted first. This is available at
|
||||
the
|
||||
<link xlink:href="https://www.citrix.com/downloads/citrix-receiver/">download
|
||||
page at citrix.com</link>. Then run <literal>nix-prefetch-url
|
||||
file://$PWD/linuxx64-$version.tar.gz</literal>. With the archive available
|
||||
in the store the package can be built and installed with Nix.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<emphasis>Note: it's recommended to install <literal>Citrix
|
||||
Receiver</literal> using <literal>nix-env -i</literal> or globally to
|
||||
ensure that the <literal>.desktop</literal> files are installed properly
|
||||
into <literal>$XDG_CONFIG_DIRS</literal>. Otherwise it won't be possible to
|
||||
open <literal>.ica</literal> files automatically from the browser to start
|
||||
a Citrix connection.</emphasis>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-citrix-custom-certs">
|
||||
<title>Custom certificates</title>
|
||||
|
||||
<para>
|
||||
The <literal>Citrix Receiver</literal> in <literal>nixpkgs</literal> trusts
|
||||
several certificates
|
||||
<link xlink:href="https://curl.haxx.se/docs/caextract.html">from the
|
||||
Mozilla database</link> by default. However several companies using Citrix
|
||||
might require their own corporate certificate. On distros with imperative
|
||||
packaging these certs can be stored easily in
|
||||
<link xlink:href="https://developer-docs.citrix.com/projects/receiver-for-linux-command-reference/en/13.7/"><literal>$ICAROOT</literal></link>,
|
||||
however this directory is a store path in <literal>nixpkgs</literal>. In
|
||||
order to work around this issue the package provides a simple mechanism to
|
||||
add custom certificates without rebuilding the entire package using
|
||||
<literal>symlinkJoin</literal>:
|
||||
<programlisting>
|
||||
<![CDATA[with import <nixpkgs> { config.allowUnfree = true; };
|
||||
let extraCerts = [ ./custom-cert-1.pem ./custom-cert-2.pem /* ... */ ]; in
|
||||
citrix_receiver.override {
|
||||
inherit extraCerts;
|
||||
}]]>
|
||||
</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="sec-ibus-typing-booster">
|
||||
<title>ibus-engines.typing-booster</title>
|
||||
|
||||
<para>
|
||||
This package is an ibus-based completion method to speed up typing.
|
||||
</para>
|
||||
|
||||
<section xml:id="sec-ibus-typing-booster-activate">
|
||||
<title>Activating the engine</title>
|
||||
|
||||
<para>
|
||||
IBus needs to be configured accordingly to activate
|
||||
<literal>typing-booster</literal>. The configuration depends on the desktop
|
||||
manager in use. For detailed instructions, please refer to the
|
||||
<link xlink:href="https://mike-fabian.github.io/ibus-typing-booster/documentation.html">upstream
|
||||
docs</link>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
On NixOS you need to explicitly enable <literal>ibus</literal> with given
|
||||
engines before customizing your desktop to use
|
||||
<literal>typing-booster</literal>. This can be achieved using the
|
||||
<literal>ibus</literal> module:
|
||||
<programlisting>{ pkgs, ... }: {
|
||||
i18n.inputMethod = {
|
||||
enabled = "ibus";
|
||||
ibus.engines = with pkgs.ibus-engines; [ typing-booster ];
|
||||
};
|
||||
}</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-ibus-typing-booster-customize-hunspell">
|
||||
<title>Using custom hunspell dictionaries</title>
|
||||
|
||||
<para>
|
||||
The IBus engine is based on <literal>hunspell</literal> to support
|
||||
completion in many languages. By default the dictionaries
|
||||
<literal>de-de</literal>, <literal>en-us</literal>,
|
||||
<literal>es-es</literal>, <literal>it-it</literal>,
|
||||
<literal>sv-se</literal> and <literal>sv-fi</literal> are in use. To add
|
||||
another dictionary, the package can be overridden like this:
|
||||
<programlisting>ibus-engines.typing-booster.override {
|
||||
langs = [ "de-at" "en-gb" ];
|
||||
}</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<emphasis>Note: each language passed to <literal>langs</literal> must be an
|
||||
attribute name in <literal>pkgs.hunspellDicts</literal>.</emphasis>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="sec-ibus-typing-booster-emoji-picker">
|
||||
<title>Built-in emoji picker</title>
|
||||
|
||||
<para>
|
||||
The <literal>ibus-engines.typing-booster</literal> package contains a
|
||||
program named <literal>emoji-picker</literal>. To display all emojis
|
||||
correctly, a special font such as <literal>noto-fonts-emoji</literal> is
|
||||
needed:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
On NixOS it can be installed using the following expression:
|
||||
<programlisting>{ pkgs, ... }: {
|
||||
fonts.fonts = with pkgs; [ noto-fonts-emoji ];
|
||||
}</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="dlib">
|
||||
<title>DLib</title>
|
||||
|
||||
<para>
|
||||
<link xlink:href="http://dlib.net/">DLib</link> is a modern, C++-based toolkit which
|
||||
provides several machine learning algorithms.
|
||||
</para>
|
||||
|
||||
<section xml:id="compiling-without-avx-support">
|
||||
<title>Compiling without AVX support</title>
|
||||
|
||||
<para>
|
||||
Especially older CPUs don't support
|
||||
<link xlink:href="https://en.wikipedia.org/wiki/Advanced_Vector_Extensions">AVX</link>
|
||||
(<abbrev>Advanced Vector Extensions</abbrev>) instructions that are used by DLib to
|
||||
optimize their algorithms.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
On the affected hardware errors like <literal>Illegal instruction</literal> will occur.
|
||||
In those cases AVX support needs to be disabled:
|
||||
<programlisting>self: super: {
|
||||
dlib = super.dlib.override { avxSupport = false; };
|
||||
}</programlisting>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
</chapter>
|
||||
@@ -1,105 +0,0 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="chap-platform-nodes">
|
||||
<title>Platform Notes</title>
|
||||
<section xml:id="sec-darwin">
|
||||
<title>Darwin (macOS)</title>
|
||||
|
||||
<para>
|
||||
Some common issues when packaging software for Darwin:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
The Darwin <literal>stdenv</literal> uses clang instead of gcc. When
|
||||
referring to the compiler <varname>$CC</varname> or <command>cc</command>
|
||||
will work in both cases. Some builds hardcode gcc/g++ in their build
|
||||
scripts, that can usually be fixed with using something like
|
||||
<literal>makeFlags = [ "CC=cc" ];</literal> or by patching the build
|
||||
scripts.
|
||||
</para>
|
||||
<programlisting>
|
||||
stdenv.mkDerivation {
|
||||
name = "libfoo-1.2.3";
|
||||
# ...
|
||||
buildPhase = ''
|
||||
$CC -o hello hello.c
|
||||
'';
|
||||
}
|
||||
</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
On Darwin, libraries are linked using absolute paths, libraries are
|
||||
resolved by their <literal>install_name</literal> at link time. Sometimes
|
||||
packages won't set this correctly causing the library lookups to fail at
|
||||
runtime. This can be fixed by adding extra linker flags or by running
|
||||
<command>install_name_tool -id</command> during the
|
||||
<function>fixupPhase</function>.
|
||||
</para>
|
||||
<programlisting>
|
||||
stdenv.mkDerivation {
|
||||
name = "libfoo-1.2.3";
|
||||
# ...
|
||||
makeFlags = stdenv.lib.optional stdenv.isDarwin "LDFLAGS=-Wl,-install_name,$(out)/lib/libfoo.dylib";
|
||||
}
|
||||
</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Even if the libraries are linked using absolute paths and resolved via
|
||||
their <literal>install_name</literal> correctly, tests can sometimes fail
|
||||
to run binaries. This happens because the <varname>checkPhase</varname>
|
||||
runs before the libraries are installed.
|
||||
</para>
|
||||
<para>
|
||||
This can usually be solved by running the tests after the
|
||||
<varname>installPhase</varname> or alternatively by using
|
||||
<varname>DYLD_LIBRARY_PATH</varname>. More information about this variable
|
||||
can be found in the <citerefentry>
|
||||
<refentrytitle>dyld</refentrytitle>
|
||||
<manvolnum>1</manvolnum></citerefentry> manpage.
|
||||
</para>
|
||||
<programlisting>
|
||||
dyld: Library not loaded: /nix/store/7hnmbscpayxzxrixrgxvvlifzlxdsdir-jq-1.5-lib/lib/libjq.1.dylib
|
||||
Referenced from: /private/tmp/nix-build-jq-1.5.drv-0/jq-1.5/tests/../jq
|
||||
Reason: image not found
|
||||
./tests/jqtest: line 5: 75779 Abort trap: 6
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
stdenv.mkDerivation {
|
||||
name = "libfoo-1.2.3";
|
||||
# ...
|
||||
doInstallCheck = true;
|
||||
installCheckTarget = "check";
|
||||
}
|
||||
</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Some packages assume xcode is available and use <command>xcrun</command>
|
||||
to resolve build tools like <command>clang</command>, etc. This causes
|
||||
errors like <code>xcode-select: error: no developer tools were found at
|
||||
'/Applications/Xcode.app'</code> while the build doesn't actually depend
|
||||
on xcode.
|
||||
</para>
|
||||
<programlisting>
|
||||
stdenv.mkDerivation {
|
||||
name = "libfoo-1.2.3";
|
||||
# ...
|
||||
prePatch = ''
|
||||
substituteInPlace Makefile \
|
||||
--replace '/usr/bin/xcrun clang' clang
|
||||
'';
|
||||
}
|
||||
</programlisting>
|
||||
<para>
|
||||
The package <literal>xcbuild</literal> can be used to build projects that
|
||||
really depend on Xcode. However, this replacement is not 100%
|
||||
compatible with Xcode and can occasionally cause issues.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</chapter>
|
||||
@@ -1,219 +0,0 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="chap-quick-start">
|
||||
<title>Quick Start to Adding a Package</title>
|
||||
<para>
|
||||
To add a package to Nixpkgs:
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Checkout the Nixpkgs source tree:
|
||||
<screen>
|
||||
$ git clone https://github.com/NixOS/nixpkgs
|
||||
$ cd nixpkgs</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Find a good place in the Nixpkgs tree to add the Nix expression for your
|
||||
package. For instance, a library package typically goes into
|
||||
<filename>pkgs/development/libraries/<replaceable>pkgname</replaceable></filename>,
|
||||
while a web browser goes into
|
||||
<filename>pkgs/applications/networking/browsers/<replaceable>pkgname</replaceable></filename>.
|
||||
See <xref linkend="sec-organisation" /> for some hints on the tree
|
||||
organisation. Create a directory for your package, e.g.
|
||||
<screen>
|
||||
$ mkdir pkgs/development/libraries/libfoo</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
In the package directory, create a Nix expression — a piece of code that
|
||||
describes how to build the package. In this case, it should be a
|
||||
<emphasis>function</emphasis> that is called with the package dependencies
|
||||
as arguments, and returns a build of the package in the Nix store. The
|
||||
expression should usually be called <filename>default.nix</filename>.
|
||||
<screen>
|
||||
$ emacs pkgs/development/libraries/libfoo/default.nix
|
||||
$ git add pkgs/development/libraries/libfoo/default.nix</screen>
|
||||
</para>
|
||||
<para>
|
||||
You can have a look at the existing Nix expressions under
|
||||
<filename>pkgs/</filename> to see how it’s done. Here are some good
|
||||
ones:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
GNU Hello:
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/hello/default.nix"><filename>pkgs/applications/misc/hello/default.nix</filename></link>.
|
||||
Trivial package, which specifies some <varname>meta</varname>
|
||||
attributes which is good practice.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
GNU cpio:
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/archivers/cpio/default.nix"><filename>pkgs/tools/archivers/cpio/default.nix</filename></link>.
|
||||
Also a simple package. The generic builder in <varname>stdenv</varname>
|
||||
does everything for you. It has no dependencies beyond
|
||||
<varname>stdenv</varname>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
GNU Multiple Precision arithmetic library (GMP):
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/gmp/5.1.x.nix"><filename>pkgs/development/libraries/gmp/5.1.x.nix</filename></link>.
|
||||
Also done by the generic builder, but has a dependency on
|
||||
<varname>m4</varname>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Pan, a GTK-based newsreader:
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/newsreaders/pan/default.nix"><filename>pkgs/applications/networking/newsreaders/pan/default.nix</filename></link>.
|
||||
Has an optional dependency on <varname>gtkspell</varname>, which is
|
||||
only built if <varname>spellCheck</varname> is <literal>true</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Apache HTTPD:
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/http/apache-httpd/2.4.nix"><filename>pkgs/servers/http/apache-httpd/2.4.nix</filename></link>.
|
||||
A bunch of optional features, variable substitutions in the configure
|
||||
flags, a post-install hook, and miscellaneous hackery.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Thunderbird:
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/mailreaders/thunderbird/default.nix"><filename>pkgs/applications/networking/mailreaders/thunderbird/default.nix</filename></link>.
|
||||
Lots of dependencies.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
JDiskReport, a Java utility:
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/misc/jdiskreport/default.nix"><filename>pkgs/tools/misc/jdiskreport/default.nix</filename></link>
|
||||
(and the
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/misc/jdiskreport/builder.sh">builder</link>).
|
||||
Nixpkgs doesn’t have a decent <varname>stdenv</varname> for Java yet
|
||||
so this is pretty ad-hoc.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
XML::Simple, a Perl module:
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix"><filename>pkgs/top-level/perl-packages.nix</filename></link>
|
||||
(search for the <varname>XMLSimple</varname> attribute). Most Perl
|
||||
modules are so simple to build that they are defined directly in
|
||||
<filename>perl-packages.nix</filename>; no need to make a separate file
|
||||
for them.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Adobe Reader:
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/adobe-reader/default.nix"><filename>pkgs/applications/misc/adobe-reader/default.nix</filename></link>.
|
||||
Shows how binary-only packages can be supported. In particular the
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/adobe-reader/builder.sh">builder</link>
|
||||
uses <command>patchelf</command> to set the RUNPATH and ELF interpreter
|
||||
of the executables so that the right libraries are found at runtime.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>
|
||||
Some notes:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
All <varname linkend="chap-meta">meta</varname> attributes are
|
||||
optional, but it’s still a good idea to provide at least the
|
||||
<varname>description</varname>, <varname>homepage</varname> and
|
||||
<varname
|
||||
linkend="sec-meta-license">license</varname>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
You can use <command>nix-prefetch-url</command>
|
||||
<replaceable>url</replaceable> to get the
|
||||
SHA-256 hash of source distributions. There are similar commands as
|
||||
<command>nix-prefetch-git</command> and
|
||||
<command>nix-prefetch-hg</command> available in
|
||||
<literal>nix-prefetch-scripts</literal> package.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
A list of schemes for <literal>mirror://</literal> URLs can be found in
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/fetchurl/mirrors.nix"><filename>pkgs/build-support/fetchurl/mirrors.nix</filename></link>.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>
|
||||
The exact syntax and semantics of the Nix expression language, including
|
||||
the built-in function, are described in the Nix manual in the
|
||||
<link
|
||||
xlink:href="http://hydra.nixos.org/job/nix/trunk/tarball/latest/download-by-type/doc/manual/#chap-writing-nix-expressions">chapter
|
||||
on writing Nix expressions</link>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Add a call to the function defined in the previous step to
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix"><filename>pkgs/top-level/all-packages.nix</filename></link>
|
||||
with some descriptive name for the variable, e.g.
|
||||
<varname>libfoo</varname>.
|
||||
<screen>
|
||||
$ emacs pkgs/top-level/all-packages.nix</screen>
|
||||
</para>
|
||||
<para>
|
||||
The attributes in that file are sorted by category (like “Development /
|
||||
Libraries”) that more-or-less correspond to the directory structure of
|
||||
Nixpkgs, and then by attribute name.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
To test whether the package builds, run the following command from the
|
||||
root of the nixpkgs source tree:
|
||||
<screen>
|
||||
$ nix-build -A libfoo</screen>
|
||||
where <varname>libfoo</varname> should be the variable name defined in the
|
||||
previous step. You may want to add the flag <option>-K</option> to keep
|
||||
the temporary build directory in case something fails. If the build
|
||||
succeeds, a symlink <filename>./result</filename> to the package in the
|
||||
Nix store is created.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If you want to install the package into your profile (optional), do
|
||||
<screen>
|
||||
$ nix-env -f . -iA libfoo</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Optionally commit the new package and open a pull request, or send a patch
|
||||
to <literal>https://groups.google.com/forum/#!forum/nix-devel</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</chapter>
|
||||
@@ -1,800 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<article xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
<title>Nixpkgs Release Notes</title>
|
||||
<section xml:id="release-notes-0.14">
|
||||
<title>Release 0.14 (June 4, 2012)</title>
|
||||
|
||||
<para>
|
||||
In preparation for the switch from Subversion to Git, this release is mainly
|
||||
the prevent the Nixpkgs version number from going backwards. (This would
|
||||
happen because prerelease version numbers produced for the Git repository
|
||||
are lower than those for the Subversion repository.)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Since the last release, there have been thousands of changes and new
|
||||
packages by numerous contributors. For details, see the commit logs.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="release-notes-0.13">
|
||||
<title>Release 0.13 (February 5, 2010)</title>
|
||||
|
||||
<para>
|
||||
As always, there are many changes. Some of the most important updates are:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Glibc 2.9.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
GCC 4.3.3.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Linux 2.6.32.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
X.org 7.5.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
KDE 4.3.4.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="release-notes-0.12">
|
||||
<title>Release 0.12 (April 24, 2009)</title>
|
||||
|
||||
<para>
|
||||
There are way too many additions to Nixpkgs since the last release to list
|
||||
here: for example, the number of packages on Linux has increased from 1002
|
||||
to 2159. However, some specific improvements are worth listing:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Nixpkgs now has a manual. In particular, it describes the standard build
|
||||
environment in detail.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Major new packages:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
KDE 4.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
TeXLive.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
VirtualBox.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
… and many others.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Important updates:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Glibc 2.7.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
GCC 4.2.4.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Linux 2.6.25 — 2.6.28.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Firefox 3.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
X.org 7.3.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Support for building derivations in a virtual machine, including RPM and
|
||||
Debian builds in automatically generated VM images. See
|
||||
<filename>pkgs/build-support/vm/default.nix</filename> for details.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Improved support for building Haskell packages.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following people contributed to this release: Andres Löh, Arie
|
||||
Middelkoop, Armijn Hemel, Eelco Dolstra, Lluís Batlle, Ludovic Courtès,
|
||||
Marc Weber, Mart Kolthof, Martin Bravenboer, Michael Raskin, Nicolas
|
||||
Pierron, Peter Simons, Pjotr Prins, Rob Vermaas, Sander van der Burg, Tobias
|
||||
Hammerschmidt, Valentin David, Wouter den Breejen and Yury G. Kudryashov. In
|
||||
addition, several people contributed patches on the
|
||||
<literal>nix-dev</literal> mailing list.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="release-notes-0.11">
|
||||
<title>Release 0.11 (September 11, 2007)</title>
|
||||
|
||||
<para>
|
||||
This release has the following improvements:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
The standard build environment (<literal>stdenv</literal>) is now pure on
|
||||
the <literal>x86_64-linux</literal> and <literal>powerpc-linux</literal>
|
||||
platforms, just as on <literal>i686-linux</literal>. (Purity means that
|
||||
building and using the standard environment has no dependencies outside
|
||||
of the Nix store. For instance, it doesn’t require an external C
|
||||
compiler such as <filename>/usr/bin/gcc</filename>.) Also, the statically
|
||||
linked binaries used in the bootstrap process are now automatically
|
||||
reproducible, making it easy to update the bootstrap tools and to add
|
||||
support for other Linux platforms. See
|
||||
<filename>pkgs/stdenv/linux/make-bootstrap-tools.nix</filename> for
|
||||
details.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Hook variables in the generic builder are now executed using the
|
||||
<function>eval</function> shell command. This has a major advantage: you
|
||||
can write hooks directly in Nix expressions. For instance, rather than
|
||||
writing a builder like this:
|
||||
<programlisting>
|
||||
source $stdenv/setup
|
||||
|
||||
postInstall=postInstall
|
||||
postInstall() {
|
||||
ln -sf gzip $out/bin/gunzip
|
||||
ln -sf gzip $out/bin/zcat
|
||||
}
|
||||
|
||||
genericBuild</programlisting>
|
||||
(the <literal>gzip</literal> builder), you can just add this attribute to
|
||||
the derivation:
|
||||
<programlisting>
|
||||
postInstall = "ln -sf gzip $out/bin/gunzip; ln -sf gzip $out/bin/zcat";</programlisting>
|
||||
and so a separate build script becomes unnecessary. This should allow us
|
||||
to get rid of most builders in Nixpkgs.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
It is now possible to have the generic builder pass arguments to
|
||||
<command>configure</command> and <command>make</command> that contain
|
||||
whitespace. Previously, for example, you could say in a builder,
|
||||
<programlisting>
|
||||
configureFlags="CFLAGS=-O0"</programlisting>
|
||||
but not
|
||||
<programlisting>
|
||||
configureFlags="CFLAGS=-O0 -g"</programlisting>
|
||||
since the <literal>-g</literal> would be interpreted as a separate
|
||||
argument to <command>configure</command>. Now you can say
|
||||
<programlisting>
|
||||
configureFlagsArray=("CFLAGS=-O0 -g")</programlisting>
|
||||
or similarly
|
||||
<programlisting>
|
||||
configureFlagsArray=("CFLAGS=-O0 -g" "LDFLAGS=-L/foo -L/bar")</programlisting>
|
||||
which does the right thing. Idem for <literal>makeFlags</literal>,
|
||||
<literal>installFlags</literal>, <literal>checkFlags</literal> and
|
||||
<literal>distFlags</literal>.
|
||||
</para>
|
||||
<para>
|
||||
Unfortunately you can't pass arrays to Bash through the environment, so
|
||||
you can't put the array above in a Nix expression, e.g.,
|
||||
<programlisting>
|
||||
configureFlagsArray = ["CFLAGS=-O0 -g"];</programlisting>
|
||||
since it would just be flattened to a since string. However, you
|
||||
<emphasis>can</emphasis> use the inline hooks described above:
|
||||
<programlisting>
|
||||
preConfigure = "configureFlagsArray=(\"CFLAGS=-O0 -g\")";</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The function <function>fetchurl</function> now has support for two
|
||||
different kinds of mirroring of files. First, it has support for
|
||||
<emphasis>content-addressable mirrors</emphasis>. For example, given the
|
||||
<function>fetchurl</function> call
|
||||
<programlisting>
|
||||
fetchurl {
|
||||
url = http://releases.mozilla.org/<replaceable>...</replaceable>/firefox-2.0.0.6-source.tar.bz2;
|
||||
sha1 = "eb72f55e4a8bf08e8c6ef227c0ade3d068ba1082";
|
||||
}</programlisting>
|
||||
<function>fetchurl</function> will first try to download this file from
|
||||
<link
|
||||
xlink:href="http://tarballs.nixos.org/sha1/eb72f55e4a8bf08e8c6ef227c0ade3d068ba1082"/>.
|
||||
If that file doesn’t exist, it will try the original URL. In general,
|
||||
the “content-addressed” location is
|
||||
<replaceable>mirror</replaceable><literal>/</literal><replaceable>hash-type</replaceable><literal>/</literal><replaceable>hash</replaceable>.
|
||||
There is currently only one content-addressable mirror
|
||||
(<link
|
||||
xlink:href="http://tarballs.nixos.org"/>), but more can be
|
||||
specified in the <varname>hashedMirrors</varname> attribute in
|
||||
<filename>pkgs/build-support/fetchurl/mirrors.nix</filename>, or by
|
||||
setting the <envar>NIX_HASHED_MIRRORS</envar> environment variable to a
|
||||
whitespace-separated list of URLs.
|
||||
</para>
|
||||
<para>
|
||||
Second, <function>fetchurl</function> has support for widely-mirrored
|
||||
distribution sites such as SourceForge or the Linux kernel archives.
|
||||
Given a URL of the form
|
||||
<literal>mirror://<replaceable>site</replaceable>/<replaceable>path</replaceable></literal>,
|
||||
it will try to download <replaceable>path</replaceable> from a
|
||||
configurable list of mirrors for <replaceable>site</replaceable>. (This
|
||||
idea was borrowed from Gentoo Linux.) Example:
|
||||
<programlisting>
|
||||
fetchurl {
|
||||
url = mirror://gnu/gcc/gcc-4.2.0/gcc-core-4.2.0.tar.bz2;
|
||||
sha256 = "0ykhzxhr8857dr97z0j9wyybfz1kjr71xk457cfapfw5fjas4ny1";
|
||||
}</programlisting>
|
||||
Currently <replaceable>site</replaceable> can be
|
||||
<literal>sourceforge</literal>, <literal>gnu</literal> and
|
||||
<literal>kernel</literal>. The list of mirrors is defined in
|
||||
<filename>pkgs/build-support/fetchurl/mirrors.nix</filename>. You can
|
||||
override the list of mirrors for a particular site by setting the
|
||||
environment variable
|
||||
<envar>NIX_MIRRORS_<replaceable>site</replaceable></envar>, e.g.
|
||||
<programlisting>
|
||||
export NIX_MIRRORS_sourceforge=http://osdn.dl.sourceforge.net/sourceforge/</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Important updates:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Glibc 2.5.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
GCC 4.1.2.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Gnome 2.16.3.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
X11R7.2.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Linux 2.6.21.7 and 2.6.22.6.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Emacs 22.1.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Major new packages:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
KDE 3.5.6 Base.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Wine 0.9.43.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
OpenOffice 2.2.1.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Many Linux system packages to support NixOS.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following people contributed to this release: Andres Löh, Arie
|
||||
Middelkoop, Armijn Hemel, Eelco Dolstra, Marc Weber, Mart Kolthof, Martin
|
||||
Bravenboer, Michael Raskin, Wouter den Breejen and Yury G. Kudryashov.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="release-notes-0.10">
|
||||
<title>Release 0.10 (October 12, 2006)</title>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
This release of Nixpkgs requires
|
||||
<link
|
||||
xlink:href='http://nixos.org/releases/nix/nix-0.10/'>Nix 0.10</link>
|
||||
or higher.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
This release has the following improvements:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<filename>pkgs/system/all-packages-generic.nix</filename> is gone, we now
|
||||
just have <filename>pkgs/top-level/all-packages.nix</filename> that
|
||||
contains all available packages. This should cause much less confusion
|
||||
with users. <filename>all-packages.nix</filename> is a function that by
|
||||
default returns packages for the current platform, but you can override
|
||||
this by specifying a different <varname>system</varname> argument.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Certain packages in Nixpkgs are now user-configurable through a
|
||||
configuration file, i.e., without having to edit the Nix expressions in
|
||||
Nixpkgs. For instance, the Firefox provided in the Nixpkgs channel is
|
||||
built without the RealPlayer plugin (for legal reasons). Previously, you
|
||||
could easily enable RealPlayer support by editing the call to the Firefox
|
||||
function in <filename>all-packages.nix</filename>, but such changes are
|
||||
not respected when Firefox is subsequently updated through the Nixpkgs
|
||||
channel.
|
||||
</para>
|
||||
<para>
|
||||
The Nixpkgs configuration file (found in
|
||||
<filename>~/.nixpkgs/config.nix</filename> or through the
|
||||
<envar>NIXPKGS_CONFIG</envar> environment variable) is an attribute set
|
||||
that contains configuration options that
|
||||
<filename>all-packages.nix</filename> reads and uses for certain packages.
|
||||
For instance, the following configuration file:
|
||||
<programlisting>
|
||||
{
|
||||
firefox = {
|
||||
enableRealPlayer = true;
|
||||
};
|
||||
}</programlisting>
|
||||
persistently enables RealPlayer support in the Firefox build.
|
||||
</para>
|
||||
<para>
|
||||
(Actually, <literal>firefox.enableRealPlayer</literal> is the
|
||||
<emphasis>only</emphasis> configuration option currently available, but
|
||||
more are sure to be added.)
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Support for new platforms:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>i686-cygwin</literal>, i.e., Windows (using
|
||||
<link xlink:href="http://www.cygwin.com/">Cygwin</link>). The standard
|
||||
environment on <literal>i686-cygwin</literal> by default builds
|
||||
binaries for the Cygwin environment (i.e., it uses Cygwin tools and
|
||||
produces executables that use the Cygwin library). However, there is
|
||||
also a standard environment that produces binaries that use
|
||||
<link
|
||||
xlink:href="http://www.mingw.org/">MinGW</link>. You can
|
||||
use it by calling <filename>all-package.nix</filename> with the
|
||||
<varname>stdenvType</varname> argument set to
|
||||
<literal>"i686-mingw"</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>i686-darwin</literal>, i.e., Mac OS X on Intel CPUs.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>powerpc-linux</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>x86_64-linux</literal>, i.e., Linux on 64-bit AMD/Intel CPUs.
|
||||
Unlike <literal>i686-linux</literal>, this platform doesn’t have a
|
||||
pure <literal>stdenv</literal> yet.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The default compiler is now GCC 4.1.1.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
X11 updated to X.org’s X11R7.1.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Notable new packages:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Opera.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Microsoft Visual C++ 2005 Express Edition and the Windows SDK.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
In total there are now around 809 packages in Nixpkgs.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
It is now <emphasis>much</emphasis> easier to override the default C
|
||||
compiler and other tools in <literal>stdenv</literal> for specific
|
||||
packages. <filename>all-packages.nix</filename> provides two utility
|
||||
functions for this purpose: <function>overrideGCC</function> and
|
||||
<function>overrideInStdenv</function>. Both take a
|
||||
<literal>stdenv</literal> and return an augmented
|
||||
<literal>stdenv</literal>; the formed changes the C compiler, and the
|
||||
latter adds additional packages to the front of
|
||||
<literal>stdenv</literal>’s initial <envar>PATH</envar>, allowing tools
|
||||
to be overridden.
|
||||
</para>
|
||||
<para>
|
||||
For instance, the package <varname>strategoxt</varname> doesn’t build
|
||||
with the GNU Make in <literal>stdenv</literal> (version 3.81), so we call
|
||||
it with an augmented <literal>stdenv</literal> that uses GNU Make 3.80:
|
||||
<programlisting>
|
||||
strategoxt = (import ../development/compilers/strategoxt) {
|
||||
inherit fetchurl pkgconfig sdf aterm;
|
||||
stdenv = overrideInStdenv stdenv [gnumake380];
|
||||
};
|
||||
|
||||
gnumake380 = <replaceable>...</replaceable>;</programlisting>
|
||||
Likewise, there are many packages that don’t compile with the default
|
||||
GCC (4.1.1), but that’s easily fixed:
|
||||
<programlisting>
|
||||
exult = import ../games/exult {
|
||||
inherit fetchurl SDL SDL_mixer zlib libpng unzip;
|
||||
stdenv = overrideGCC stdenv gcc34;
|
||||
};</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
It has also become much easier to experiment with changes to the
|
||||
<literal>stdenv</literal> setup script (which notably contains the generic
|
||||
builder). Since edits to <filename>pkgs/stdenv/generic/setup.sh</filename>
|
||||
trigger a rebuild of <emphasis>everything</emphasis>, this was formerly
|
||||
quite painful. But now <literal>stdenv</literal> contains a function to
|
||||
“regenerate” <literal>stdenv</literal> with a different setup script,
|
||||
allowing the use of a different setup script for specific packages:
|
||||
<programlisting>
|
||||
pkg = import <replaceable>...</replaceable> {
|
||||
stdenv = stdenv.regenerate ./my-setup.sh;
|
||||
<replaceable>...</replaceable>
|
||||
}</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Packages can now have a human-readable <emphasis>description</emphasis>
|
||||
field. Package descriptions are shown by <literal>nix-env -qa
|
||||
--description</literal>. In addition, they’re shown on the Nixpkgs
|
||||
release page. A description can be added to a package as follows:
|
||||
<programlisting>
|
||||
stdenv.mkDerivation {
|
||||
name = "exult-1.2";
|
||||
<replaceable>...</replaceable>
|
||||
meta = {
|
||||
description = "A reimplementation of the Ultima VII game engine";
|
||||
};
|
||||
}</programlisting>
|
||||
The <varname>meta</varname> attribute is not passed to the builder, so
|
||||
changes to the description do not trigger a rebuild. Additional
|
||||
<varname>meta</varname> attributes may be defined in the future (such as
|
||||
the URL of the package’s homepage, the license, etc.).
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
The following people contributed to this release: Andres Löh, Armijn Hemel,
|
||||
Christof Douma, Eelco Dolstra, Eelco Visser, Mart Kolthof, Martin
|
||||
Bravenboer, Merijn de Jonge, Rob Vermaas and Roy van den Broek.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="release-notes-0.9">
|
||||
<title>Release 0.9 (January 31, 2006)</title>
|
||||
|
||||
<para>
|
||||
There have been zillions of changes since the last release of Nixpkgs. Many
|
||||
packages have been added or updated. The following are some of the more
|
||||
notable changes:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Distribution files have been moved to
|
||||
<link
|
||||
xlink:href="http://nixos.org/" />.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The C library on Linux, Glibc, has been updated to version 2.3.6.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The default compiler is now GCC 3.4.5. GCC 4.0.2 is also available.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The old, unofficial Xlibs has been replaced by the official modularised
|
||||
X11 distribution from X.org, i.e., X11R7.0. X11R7.0 consists of 287 (!)
|
||||
packages, all of which are in Nixpkgs though not all have been tested. It
|
||||
is now possible to build a working X server (previously we only had X
|
||||
client libraries). We use a fully Nixified X server on NixOS.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The Sun JDK 5 has been purified, i.e., it doesn’t require any non-Nix
|
||||
components such as <filename>/lib/ld-linux.so.2</filename>. This means
|
||||
that Java applications such as Eclipse and Azureus can run on NixOS.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Hardware-accelerated OpenGL support, used by games like Quake 3 (which is
|
||||
now built from source).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Improved support for FreeBSD on x86.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Improved Haskell support; e.g., the GHC build is now pure.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Some support for cross-compilation: cross-compiling builds of GCC and
|
||||
Binutils, and cross-compiled builds of the C library uClibc.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Notable new packages:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
teTeX, including support for building LaTeX documents using Nix (with
|
||||
automatic dependency determination).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ruby.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
System-level packages to support NixOS, e.g. Grub, GNU
|
||||
<literal>parted</literal> and so on.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>ecj</literal>, the Eclipse Compiler for Java, so we finally
|
||||
have a freely distributable compiler that supports Java 5.0.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>php</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The GIMP.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Inkscape.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
GAIM.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>kdelibs</literal>. This allows us to add KDE-based packages
|
||||
(such as <literal>kcachegrind</literal>).
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
The following people contributed to this release: Andres Löh, Armijn Hemel,
|
||||
Bogdan Dumitriu, Christof Douma, Eelco Dolstra, Eelco Visser, Mart Kolthof,
|
||||
Martin Bravenboer, Rob Vermaas and Roy van den Broek.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="release-notes-0.8">
|
||||
<title>Release 0.8 (April 11, 2005)</title>
|
||||
|
||||
<para>
|
||||
This release is mostly to remain synchronised with the changed hashing
|
||||
scheme in Nix 0.8.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Notable updates:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Adobe Reader 7.0
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Various security updates (zlib 1.2.2, etc.)
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="release-notes-0.7">
|
||||
<title>Release 0.7 (March 14, 2005)</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
The bootstrap process for the standard build environment on Linux
|
||||
(stdenv-linux) has been improved. It is no longer dependent in its initial
|
||||
bootstrap stages on the system Glibc, GCC, and other tools. Rather,
|
||||
Nixpkgs contains a statically linked bash and curl, and uses that to
|
||||
download other statically linked tools. These are then used to build a
|
||||
Glibc and dynamically linked versions of all other tools.
|
||||
</para>
|
||||
<para>
|
||||
This change also makes the bootstrap process faster. For instance, GCC is
|
||||
built only once instead of three times.
|
||||
</para>
|
||||
<para>
|
||||
(Contributed by Armijn Hemel.)
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Tarballs used by Nixpkgs are now obtained from the same server that hosts
|
||||
Nixpkgs (<link
|
||||
xlink:href="http://catamaran.labs.cs.uu.nl/" />). This
|
||||
reduces the risk of packages being unbuildable due to moved or deleted
|
||||
files on various servers.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
There now is a generic mechanism for building Perl modules. See the
|
||||
various Perl modules defined in pkgs/system/all-packages-generic.nix.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Notable new packages:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Qt 3
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
MySQL
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
MythTV
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Mono
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
MonoDevelop (alpha)
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Xine
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Notable updates:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
GCC 3.4.3
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Glibc 2.3.4
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
GTK 2.6
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</article>
|
||||
@@ -1,616 +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-reviewing-contributions">
|
||||
<title>Reviewing contributions</title>
|
||||
<warning>
|
||||
<para>
|
||||
The following section is a draft, and the policy for reviewing is still
|
||||
being discussed in issues such as
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/issues/11166">#11166
|
||||
</link> and
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/issues/20836">#20836
|
||||
</link>.
|
||||
</para>
|
||||
</warning>
|
||||
<para>
|
||||
The Nixpkgs project receives a fairly high number of contributions via GitHub
|
||||
pull requests. Reviewing and approving these is an important task and a way
|
||||
to contribute to the project.
|
||||
</para>
|
||||
<para>
|
||||
The high change rate of Nixpkgs makes any pull request that remains open for
|
||||
too long subject to conflicts that will require extra work from the submitter
|
||||
or the merger. Reviewing pull requests in a timely manner and being responsive
|
||||
to the comments is the key to avoid this issue. GitHub provides sort filters
|
||||
that can be used to see the <link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc">most
|
||||
recently</link> and the <link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-asc">least
|
||||
recently</link> updated pull requests. We highly encourage looking at
|
||||
<link xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+review%3Anone+status%3Asuccess+-label%3A%222.status%3A+work-in-progress%22+no%3Aproject+no%3Aassignee+no%3Amilestone">
|
||||
this list of ready to merge, unreviewed pull requests</link>.
|
||||
</para>
|
||||
<para>
|
||||
When reviewing a pull request, please always be nice and polite.
|
||||
Controversial changes can lead to controversial opinions, but it is important
|
||||
to respect every community member and their work.
|
||||
</para>
|
||||
<para>
|
||||
GitHub provides reactions as a simple and quick way to provide feedback to
|
||||
pull requests or any comments. The thumb-down reaction should be used with
|
||||
care and if possible accompanied with some explanation so the submitter has
|
||||
directions to improve their contribution.
|
||||
</para>
|
||||
<para>
|
||||
pull request reviews should include a list of what has been reviewed in a
|
||||
comment, so other reviewers and mergers can know the state of the review.
|
||||
</para>
|
||||
<para>
|
||||
All the review template samples provided in this section are generic and
|
||||
meant as examples. Their usage is optional and the reviewer is free to adapt
|
||||
them to their liking.
|
||||
</para>
|
||||
<section xml:id="reviewing-contributions-package-updates">
|
||||
<title>Package updates</title>
|
||||
|
||||
<para>
|
||||
A package update is the most trivial and common type of pull request. These
|
||||
pull requests mainly consist of updating the version part of the package
|
||||
name and the source hash.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It can happen that non-trivial updates include patches or more complex
|
||||
changes.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Reviewing process:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Add labels to the pull request. (Requires commit rights)
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>8.has: package (update)</literal> and any topic label that fit
|
||||
the updated package.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that the package versioning fits the guidelines.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that the commit text fits the guidelines.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that the package maintainers are notified.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<link xlink:href="https://help.github.com/articles/about-codeowners/">CODEOWNERS</link>
|
||||
will make GitHub notify users based on the submitted changes, but it can
|
||||
happen that it misses some of the package maintainers.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that the meta field information is correct.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
License can change with version updates, so it should be checked to
|
||||
match the upstream license.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If the package has no maintainer, a maintainer must be set. This can be
|
||||
the update submitter or a community member that accepts to take
|
||||
maintainership of the package.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that the code contains no typos.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Building the package locally.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
pull requests are often targeted to the master or staging branch, and
|
||||
building the pull request locally when it is submitted can trigger many
|
||||
source builds.
|
||||
</para>
|
||||
<para>
|
||||
It is possible to rebase the changes on nixos-unstable or
|
||||
nixpkgs-unstable for easier review by running the following commands
|
||||
from a nixpkgs clone.
|
||||
<screen>
|
||||
$ git remote add channels https://github.com/NixOS/nixpkgs-channels.git <co
|
||||
xml:id='reviewing-rebase-1' />
|
||||
$ git fetch channels nixos-unstable <co xml:id='reviewing-rebase-2' />
|
||||
$ git fetch origin pull/PRNUMBER/head <co xml:id='reviewing-rebase-3' />
|
||||
$ git rebase --onto nixos-unstable BASEBRANCH FETCH_HEAD <co
|
||||
xml:id='reviewing-rebase-4' />
|
||||
</screen>
|
||||
<calloutlist>
|
||||
<callout arearefs='reviewing-rebase-1'>
|
||||
<para>
|
||||
This should be done only once to be able to fetch channel branches
|
||||
from the nixpkgs-channels repository.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='reviewing-rebase-2'>
|
||||
<para>
|
||||
Fetching the nixos-unstable branch.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='reviewing-rebase-3'>
|
||||
<para>
|
||||
Fetching the pull request changes, <varname>PRNUMBER</varname> is the
|
||||
number at the end of the pull request title and
|
||||
<varname>BASEBRANCH</varname> the base branch of the pull request.
|
||||
</para>
|
||||
</callout>
|
||||
<callout arearefs='reviewing-rebase-4'>
|
||||
<para>
|
||||
Rebasing the pull request changes to the nixos-unstable branch.
|
||||
</para>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The <link xlink:href="https://github.com/madjar/nox">nox</link> tool can
|
||||
be used to review a pull request content in a single command. It doesn't
|
||||
rebase on a channel branch so it might trigger multiple source builds.
|
||||
<varname>PRNUMBER</varname> should be replaced by the number at the end
|
||||
of the pull request title.
|
||||
</para>
|
||||
<screen>
|
||||
$ nix-shell -p nox --run "nox-review -k pr PRNUMBER"
|
||||
</screen>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Running every binary.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<example xml:id="reviewing-contributions-sample-package-update">
|
||||
<title>Sample template for a package update review</title>
|
||||
<screen>
|
||||
##### Reviewed points
|
||||
|
||||
- [ ] package name fits guidelines
|
||||
- [ ] package version fits guidelines
|
||||
- [ ] package build on ARCHITECTURE
|
||||
- [ ] executables tested on ARCHITECTURE
|
||||
- [ ] all depending packages build
|
||||
|
||||
##### Possible improvements
|
||||
|
||||
##### Comments
|
||||
|
||||
</screen>
|
||||
</example>
|
||||
</section>
|
||||
<section xml:id="reviewing-contributions-new-packages">
|
||||
<title>New packages</title>
|
||||
|
||||
<para>
|
||||
New packages are a common type of pull requests. These pull requests
|
||||
consists in adding a new nix-expression for a package.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Reviewing process:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Add labels to the pull request. (Requires commit rights)
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>8.has: package (new)</literal> and any topic label that fit the
|
||||
new package.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that the package versioning is fitting the guidelines.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that the commit name is fitting the guidelines.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that the meta field contains correct information.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
License must be checked to be fitting upstream license.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Platforms should be set or the package will not get binary substitutes.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
A maintainer must be set. This can be the package submitter or a
|
||||
community member that accepts to take maintainership of the package.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that the code contains no typos.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure the package source.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Mirrors urls should be used when available.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The most appropriate function should be used (e.g. packages from GitHub
|
||||
should use <literal>fetchFromGitHub</literal>).
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Building the package locally.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Running every binary.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<example xml:id="reviewing-contributions-sample-new-package">
|
||||
<title>Sample template for a new package review</title>
|
||||
<screen>
|
||||
##### Reviewed points
|
||||
|
||||
- [ ] package path fits guidelines
|
||||
- [ ] package name fits guidelines
|
||||
- [ ] package version fits guidelines
|
||||
- [ ] package build on ARCHITECTURE
|
||||
- [ ] executables tested on ARCHITECTURE
|
||||
- [ ] `meta.description` is set and fits guidelines
|
||||
- [ ] `meta.license` fits upstream license
|
||||
- [ ] `meta.platforms` is set
|
||||
- [ ] `meta.maintainers` is set
|
||||
- [ ] build time only dependencies are declared in `nativeBuildInputs`
|
||||
- [ ] source is fetched using the appropriate function
|
||||
- [ ] phases are respected
|
||||
- [ ] patches that are remotely available are fetched with `fetchpatch`
|
||||
|
||||
##### Possible improvements
|
||||
|
||||
##### Comments
|
||||
|
||||
</screen>
|
||||
</example>
|
||||
</section>
|
||||
<section xml:id="reviewing-contributions-module-updates">
|
||||
<title>Module updates</title>
|
||||
|
||||
<para>
|
||||
Module updates are submissions changing modules in some ways. These often
|
||||
contains changes to the options or introduce new options.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Reviewing process
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Add labels to the pull request. (Requires commit rights)
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>8.has: module (update)</literal> and any topic label that fit
|
||||
the module.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that the module maintainers are notified.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<link xlink:href="https://help.github.com/articles/about-codeowners/">CODEOWNERS</link>
|
||||
will make GitHub notify users based on the submitted changes, but it can
|
||||
happen that it misses some of the package maintainers.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that the module tests, if any, are succeeding.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that the introduced options are correct.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Type should be appropriate (string related types differs in their
|
||||
merging capabilities, <literal>optionSet</literal> and
|
||||
<literal>string</literal> types are deprecated).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Description, default and example should be provided.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that option changes are backward compatible.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>mkRenamedOptionModule</literal> and
|
||||
<literal>mkAliasOptionModule</literal> functions provide way to make
|
||||
option changes backward compatible.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that removed options are declared with
|
||||
<literal>mkRemovedOptionModule</literal>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that changes that are not backward compatible are mentioned in
|
||||
release notes.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that documentations affected by the change is updated.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<example xml:id="reviewing-contributions-sample-module-update">
|
||||
<title>Sample template for a module update review</title>
|
||||
<screen>
|
||||
##### Reviewed points
|
||||
|
||||
- [ ] changes are backward compatible
|
||||
- [ ] removed options are declared with `mkRemovedOptionModule`
|
||||
- [ ] changes that are not backward compatible are documented in release notes
|
||||
- [ ] module tests succeed on ARCHITECTURE
|
||||
- [ ] options types are appropriate
|
||||
- [ ] options description is set
|
||||
- [ ] options example is provided
|
||||
- [ ] documentation affected by the changes is updated
|
||||
|
||||
##### Possible improvements
|
||||
|
||||
##### Comments
|
||||
|
||||
</screen>
|
||||
</example>
|
||||
</section>
|
||||
<section xml:id="reviewing-contributions-new-modules">
|
||||
<title>New modules</title>
|
||||
|
||||
<para>
|
||||
New modules submissions introduce a new module to NixOS.
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Add labels to the pull request. (Requires commit rights)
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>8.has: module (new)</literal> and any topic label that fit the
|
||||
module.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that the module tests, if any, are succeeding.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that the introduced options are correct.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Type should be appropriate (string related types differs in their
|
||||
merging capabilities, <literal>optionSet</literal> and
|
||||
<literal>string</literal> types are deprecated).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Description, default and example should be provided.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that module <literal>meta</literal> field is present
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Maintainers should be declared in <literal>meta.maintainers</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Module documentation should be declared with
|
||||
<literal>meta.doc</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Ensure that the module respect other modules functionality.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
For example, enabling a module should not open firewall ports by
|
||||
default.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<example xml:id="reviewing-contributions-sample-new-module">
|
||||
<title>Sample template for a new module review</title>
|
||||
<screen>
|
||||
##### Reviewed points
|
||||
|
||||
- [ ] module path fits the guidelines
|
||||
- [ ] module tests succeed on ARCHITECTURE
|
||||
- [ ] options have appropriate types
|
||||
- [ ] options have default
|
||||
- [ ] options have example
|
||||
- [ ] options have descriptions
|
||||
- [ ] No unneeded package is added to environment.systemPackages
|
||||
- [ ] meta.maintainers is set
|
||||
- [ ] module documentation is declared in meta.doc
|
||||
|
||||
##### Possible improvements
|
||||
|
||||
##### Comments
|
||||
|
||||
</screen>
|
||||
</example>
|
||||
</section>
|
||||
<section xml:id="reviewing-contributions-other-submissions">
|
||||
<title>Other submissions</title>
|
||||
|
||||
<para>
|
||||
Other type of submissions requires different reviewing steps.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you consider having enough knowledge and experience in a topic and would
|
||||
like to be a long-term reviewer for related submissions, please contact the
|
||||
current reviewers for that topic. They will give you information about the
|
||||
reviewing process. The main reviewers for a topic can be hard to find as
|
||||
there is no list, but checking past pull requests to see who reviewed or
|
||||
git-blaming the code to see who committed to that topic can give some hints.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Container system, boot system and library changes are some examples of the
|
||||
pull requests fitting this category.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="reviewing-contributions--merging-pull-requests">
|
||||
<title>Merging pull requests</title>
|
||||
|
||||
<para>
|
||||
It is possible for community members that have enough knowledge and
|
||||
experience on a special topic to contribute by merging pull requests.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
TODO: add the procedure to request merging rights.
|
||||
</para>
|
||||
|
||||
<!--
|
||||
The following paragraph about how to deal with unactive contributors is just a
|
||||
proposition and should be modified to what the community agrees to be the right
|
||||
policy.
|
||||
|
||||
<para>Please note that contributors with commit rights unactive for more than
|
||||
three months will have their commit rights revoked.</para>
|
||||
-->
|
||||
|
||||
<para>
|
||||
In a case a contributor definitively leaves the Nix community, they should
|
||||
create an issue or post on
|
||||
<link
|
||||
xlink:href="https://discourse.nixos.org">Discourse</link> with
|
||||
references of packages and modules they maintain so the maintainership can be
|
||||
taken over by other contributors.
|
||||
</para>
|
||||
</section>
|
||||
</chapter>
|
||||
@@ -1,5 +0,0 @@
|
||||
{ pkgs ? import ../. {} }:
|
||||
(import ./default.nix {}).overrideAttrs (x: {
|
||||
buildInputs = x.buildInputs ++ [ pkgs.xmloscopy pkgs.ruby ];
|
||||
|
||||
})
|
||||
3024
doc/stdenv.xml
3024
doc/stdenv.xml
File diff suppressed because it is too large
Load Diff
291
doc/style.css
291
doc/style.css
@@ -1,291 +0,0 @@
|
||||
/* Copied from http://bakefile.sourceforge.net/, which appears
|
||||
licensed under the GNU GPL. */
|
||||
|
||||
|
||||
/***************************************************************************
|
||||
Basic headers and text:
|
||||
***************************************************************************/
|
||||
|
||||
body
|
||||
{
|
||||
font-family: "Nimbus Sans L", sans-serif;
|
||||
font-size: 1em;
|
||||
background: white;
|
||||
margin: 2em 1em 2em 1em;
|
||||
}
|
||||
|
||||
h1, h2, h3, h4
|
||||
{
|
||||
color: #005aa0;
|
||||
}
|
||||
|
||||
h1 /* title */
|
||||
{
|
||||
font-size: 200%;
|
||||
}
|
||||
|
||||
h2 /* chapters, appendices, subtitle */
|
||||
{
|
||||
font-size: 180%;
|
||||
}
|
||||
|
||||
div.book
|
||||
{
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
div.book > div
|
||||
{
|
||||
/*
|
||||
* based on https://medium.com/@zkareemz/golden-ratio-62b3b6d4282a
|
||||
* we do 70 characters per line to fit code listings better
|
||||
* 70 * (font-size / 1.618)
|
||||
* expression for emacs:
|
||||
* (* 70 (/ 1 1.618))
|
||||
*/
|
||||
max-width: 43.2em;
|
||||
text-align: left;
|
||||
margin: auto;
|
||||
}
|
||||
|
||||
/* Extra space between chapters, appendices. */
|
||||
div.chapter > div.titlepage h2, div.appendix > div.titlepage h2
|
||||
{
|
||||
margin-top: 1.5em;
|
||||
}
|
||||
|
||||
div.section > div.titlepage h2 /* sections */
|
||||
{
|
||||
font-size: 150%;
|
||||
margin-top: 1.5em;
|
||||
}
|
||||
|
||||
h3 /* subsections */
|
||||
{
|
||||
font-size: 125%;
|
||||
}
|
||||
|
||||
div.simplesect h2
|
||||
{
|
||||
font-size: 110%;
|
||||
}
|
||||
|
||||
div.appendix h3
|
||||
{
|
||||
font-size: 150%;
|
||||
margin-top: 1.5em;
|
||||
}
|
||||
|
||||
div.refnamediv h2, div.refsynopsisdiv h2, div.refsection h2 /* refentry parts */
|
||||
{
|
||||
margin-top: 1.4em;
|
||||
font-size: 125%;
|
||||
}
|
||||
|
||||
div.refsection h3
|
||||
{
|
||||
font-size: 110%;
|
||||
}
|
||||
|
||||
|
||||
/***************************************************************************
|
||||
Examples:
|
||||
***************************************************************************/
|
||||
|
||||
div.example
|
||||
{
|
||||
border: 1px solid #b0b0b0;
|
||||
padding: 6px 6px;
|
||||
margin-left: 1.5em;
|
||||
margin-right: 1.5em;
|
||||
background: #f4f4f8;
|
||||
border-radius: 0.4em;
|
||||
box-shadow: 0.4em 0.4em 0.5em #e0e0e0;
|
||||
}
|
||||
|
||||
div.example p.title
|
||||
{
|
||||
margin-top: 0em;
|
||||
}
|
||||
|
||||
div.example pre
|
||||
{
|
||||
box-shadow: none;
|
||||
}
|
||||
|
||||
|
||||
/***************************************************************************
|
||||
Screen dumps:
|
||||
***************************************************************************/
|
||||
|
||||
pre.screen, pre.programlisting
|
||||
{
|
||||
border: 1px solid #b0b0b0;
|
||||
padding: 3px 3px;
|
||||
margin-left: 0.5em;
|
||||
margin-right: 0.5em;
|
||||
|
||||
background: #f4f4f8;
|
||||
font-family: monospace;
|
||||
border-radius: 0.4em;
|
||||
box-shadow: 0.4em 0.4em 0.5em #e0e0e0;
|
||||
}
|
||||
|
||||
div.example pre.programlisting
|
||||
{
|
||||
border: 0px;
|
||||
padding: 0 0;
|
||||
margin: 0 0 0 0;
|
||||
}
|
||||
|
||||
/***************************************************************************
|
||||
Notes, warnings etc:
|
||||
***************************************************************************/
|
||||
|
||||
.note, .warning
|
||||
{
|
||||
border: 1px solid #b0b0b0;
|
||||
padding: 3px 3px;
|
||||
margin-left: 1.5em;
|
||||
margin-right: 1.5em;
|
||||
margin-bottom: 1em;
|
||||
padding: 0.3em 0.3em 0.3em 0.3em;
|
||||
background: #fffff5;
|
||||
border-radius: 0.4em;
|
||||
box-shadow: 0.4em 0.4em 0.5em #e0e0e0;
|
||||
}
|
||||
|
||||
div.note, div.warning
|
||||
{
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
div.note h3, div.warning h3
|
||||
{
|
||||
color: red;
|
||||
font-size: 100%;
|
||||
padding-right: 0.5em;
|
||||
display: inline;
|
||||
}
|
||||
|
||||
div.note p, div.warning p
|
||||
{
|
||||
margin-bottom: 0em;
|
||||
}
|
||||
|
||||
div.note h3 + p, div.warning h3 + p
|
||||
{
|
||||
display: inline;
|
||||
}
|
||||
|
||||
div.note h3
|
||||
{
|
||||
color: blue;
|
||||
font-size: 100%;
|
||||
}
|
||||
|
||||
div.navfooter *
|
||||
{
|
||||
font-size: 90%;
|
||||
}
|
||||
|
||||
|
||||
/***************************************************************************
|
||||
Links colors and highlighting:
|
||||
***************************************************************************/
|
||||
|
||||
a { text-decoration: none; }
|
||||
a:hover { text-decoration: underline; }
|
||||
a:link { color: #0048b3; }
|
||||
a:visited { color: #002a6a; }
|
||||
|
||||
|
||||
/***************************************************************************
|
||||
Table of contents:
|
||||
***************************************************************************/
|
||||
|
||||
div.toc
|
||||
{
|
||||
font-size: 90%;
|
||||
}
|
||||
|
||||
div.toc dl
|
||||
{
|
||||
margin-top: 0em;
|
||||
margin-bottom: 0em;
|
||||
}
|
||||
|
||||
|
||||
/***************************************************************************
|
||||
Special elements:
|
||||
***************************************************************************/
|
||||
|
||||
tt, code
|
||||
{
|
||||
color: #400000;
|
||||
}
|
||||
|
||||
.term
|
||||
{
|
||||
font-weight: bold;
|
||||
|
||||
}
|
||||
|
||||
div.variablelist dd p, div.glosslist dd p
|
||||
{
|
||||
margin-top: 0em;
|
||||
}
|
||||
|
||||
div.variablelist dd, div.glosslist dd
|
||||
{
|
||||
margin-left: 1.5em;
|
||||
}
|
||||
|
||||
div.glosslist dt
|
||||
{
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
.varname
|
||||
{
|
||||
color: #400000;
|
||||
}
|
||||
|
||||
span.command strong
|
||||
{
|
||||
font-weight: normal;
|
||||
color: #400000;
|
||||
}
|
||||
|
||||
div.calloutlist table
|
||||
{
|
||||
box-shadow: none;
|
||||
}
|
||||
|
||||
table
|
||||
{
|
||||
border-collapse: collapse;
|
||||
box-shadow: 0.4em 0.4em 0.5em #e0e0e0;
|
||||
}
|
||||
|
||||
table.simplelist
|
||||
{
|
||||
text-align: left;
|
||||
color: #005aa0;
|
||||
border: 0;
|
||||
padding: 5px;
|
||||
background: #fffff5;
|
||||
font-weight: normal;
|
||||
font-style: italic;
|
||||
box-shadow: none;
|
||||
margin-bottom: 1em;
|
||||
}
|
||||
|
||||
div.navheader table, div.navfooter table {
|
||||
box-shadow: none;
|
||||
}
|
||||
|
||||
div.affiliation
|
||||
{
|
||||
font-style: italic;
|
||||
}
|
||||
@@ -1,523 +0,0 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="chap-submitting-changes">
|
||||
<title>Submitting changes</title>
|
||||
<section xml:id="submitting-changes-making-patches">
|
||||
<title>Making patches</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Read <link xlink:href="https://nixos.org/nixpkgs/manual/">Manual (How to
|
||||
write packages for Nix)</link>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Fork the repository on GitHub.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Create a branch for your future fix.
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
You can make branch from a commit of your local
|
||||
<command>nixos-version</command>. That will help you to avoid
|
||||
additional local compilations. Because you will receive packages from
|
||||
binary cache.
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
For example: <command>nixos-version</command> returns
|
||||
<command>15.05.git.0998212 (Dingo)</command>. So you can do:
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<screen>
|
||||
$ git checkout 0998212
|
||||
$ git checkout -b 'fix/pkg-name-update'
|
||||
</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Please avoid working directly on the <command>master</command> branch.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Make commits of logical units.
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
If you removed pkgs, made some major NixOS changes etc., write about
|
||||
them in
|
||||
<command>nixos/doc/manual/release-notes/rl-unstable.xml</command>.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Check for unnecessary whitespace with <command>git diff --check</command>
|
||||
before committing.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Format the commit in a following way:
|
||||
</para>
|
||||
<programlisting>
|
||||
(pkg-name | nixos/<module>): (from -> to | init at version | refactor | etc)
|
||||
Additional information.
|
||||
</programlisting>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Examples:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<command>nginx: init at 2.0.1</command>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<command>firefox: 54.0.1 -> 55.0</command>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<command>nixos/hydra: add bazBaz option</command>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<command>nixos/nginx: refactor config generation</command>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Test your changes. If you work with
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
nixpkgs:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
update pkg ->
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<command>nix-env -i pkg-name -f <path to your local nixpkgs
|
||||
folder></command>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
add pkg ->
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Make sure it's in
|
||||
<command>pkgs/top-level/all-packages.nix</command>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<command>nix-env -i pkg-name -f <path to your local nixpkgs
|
||||
folder></command>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<emphasis>If you don't want to install pkg in you
|
||||
profile</emphasis>.
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<command>nix-build -A pkg-attribute-name <path to your local
|
||||
nixpkgs folder>/default.nix</command> and check results in the
|
||||
folder <command>result</command>. It will appear in the same
|
||||
directory where you did <command>nix-build</command>.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If you did <command>nix-env -i pkg-name</command> you can do
|
||||
<command>nix-env -e pkg-name</command> to uninstall it from your
|
||||
system.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
NixOS and its modules:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
You can add new module to your NixOS configuration file (usually
|
||||
it's <command>/etc/nixos/configuration.nix</command>). And do
|
||||
<command>sudo nixos-rebuild test -I nixpkgs=<path to your local
|
||||
nixpkgs folder> --fast</command>.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If you have commits <command>pkg-name: oh, forgot to insert
|
||||
whitespace</command>: squash commits in this case. Use <command>git rebase
|
||||
-i</command>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Rebase you branch against current <command>master</command>.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section xml:id="submitting-changes-submitting-changes">
|
||||
<title>Submitting changes</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Push your changes to your fork of nixpkgs.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Create pull request:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Write the title in format <command>(pkg-name | nixos/<module>):
|
||||
improvement</command>.
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
If you update the pkg, write versions <command>from -> to</command>.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Write in comment if you have tested your patch. Do not rely much on
|
||||
<command>TravisCI</command>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If you make an improvement, write about your motivation.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Notify maintainers of the package. For example add to the message:
|
||||
<command>cc @jagajaga @domenkozar</command>.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section xml:id="submitting-changes-pull-request-template">
|
||||
<title>Pull Request Template</title>
|
||||
|
||||
<para>
|
||||
The pull request template helps determine what steps have been made for a
|
||||
contribution so far, and will help guide maintainers on the status of a
|
||||
change. The motivation section of the PR should include any extra details
|
||||
the title does not address and link any existing issues related to the pull
|
||||
request.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When a PR is created, it will be pre-populated with some checkboxes detailed
|
||||
below:
|
||||
</para>
|
||||
|
||||
<section xml:id="submitting-changes-tested-with-sandbox">
|
||||
<title>Tested using sandboxing</title>
|
||||
|
||||
<para>
|
||||
When sandbox builds are enabled, Nix will setup an isolated environment for
|
||||
each build process. It is used to remove further hidden dependencies set by
|
||||
the build environment to improve reproducibility. This includes access to
|
||||
the network during the build outside of <function>fetch*</function>
|
||||
functions and files outside the Nix store. Depending on the operating
|
||||
system access to other resources are blocked as well (ex. inter process
|
||||
communication is isolated on Linux); see
|
||||
<link
|
||||
xlink:href="https://nixos.org/nix/manual/#description-45">build-use-sandbox</link>
|
||||
in Nix manual for details.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Sandboxing is not enabled by default in Nix due to a small performance hit
|
||||
on each build. In pull requests for
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/">nixpkgs</link>
|
||||
people are asked to test builds with sandboxing enabled (see
|
||||
<literal>Tested using sandboxing</literal> in the pull request template)
|
||||
because
|
||||
in<link
|
||||
xlink:href="https://nixos.org/hydra/">https://nixos.org/hydra/</link>
|
||||
sandboxing is also used.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Depending if you use NixOS or other platforms you can use one of the
|
||||
following methods to enable sandboxing
|
||||
<emphasis role="bold">before</emphasis> building the package:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<emphasis role="bold">Globally enable sandboxing on NixOS</emphasis>:
|
||||
add the following to <filename>configuration.nix</filename>
|
||||
<screen>nix.useSandbox = true;</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<emphasis role="bold">Globally enable sandboxing on non-NixOS
|
||||
platforms</emphasis>: add the following to:
|
||||
<filename>/etc/nix/nix.conf</filename>
|
||||
<screen>build-use-sandbox = true</screen>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="submitting-changes-platform-diversity">
|
||||
<title>Built on platform(s)</title>
|
||||
|
||||
<para>
|
||||
Many Nix packages are designed to run on multiple platforms. As such, it's
|
||||
important to let the maintainer know which platforms your changes have been
|
||||
tested on. It's not always practical to test a change on all platforms, and
|
||||
is not required for a pull request to be merged. Only check the systems you
|
||||
tested the build on in this section.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="submitting-changes-nixos-tests">
|
||||
<title>Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)</title>
|
||||
|
||||
<para>
|
||||
Packages with automated tests are much more likely to be merged in a timely
|
||||
fashion because it doesn't require as much manual testing by the maintainer
|
||||
to verify the functionality of the package. If there are existing tests for
|
||||
the package, they should be run to verify your changes do not break the
|
||||
tests. Tests only apply to packages with NixOS modules defined and can only
|
||||
be run on Linux. For more details on writing and running tests, see the
|
||||
<link
|
||||
xlink:href="https://nixos.org/nixos/manual/index.html#sec-nixos-tests">section
|
||||
in the NixOS manual</link>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="submitting-changes-tested-compilation">
|
||||
<title>Tested compilation of all pkgs that depend on this change using <command>nox-review</command></title>
|
||||
|
||||
<para>
|
||||
If you are updating a package's version, you can use nox to make sure all
|
||||
packages that depend on the updated package still compile correctly. This
|
||||
can be done using the nox utility. The <command>nox-review</command>
|
||||
utility can look for and build all dependencies either based on uncommited
|
||||
changes with the <literal>wip</literal> option or specifying a github pull
|
||||
request number.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
review uncommitted changes:
|
||||
<screen>nix-shell -p nox --run "nox-review wip"</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
review changes from pull request number 12345:
|
||||
<screen>nix-shell -p nox --run "nox-review pr 12345"</screen>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="submitting-changes-tested-execution">
|
||||
<title>Tested execution of all binary files (usually in <filename>./result/bin/</filename>)</title>
|
||||
|
||||
<para>
|
||||
It's important to test any executables generated by a build when you change
|
||||
or create a package in nixpkgs. This can be done by looking in
|
||||
<filename>./result/bin</filename> and running any files in there, or at a
|
||||
minimum, the main executable for the package. For example, if you make a
|
||||
change to <package>texlive</package>, you probably would only check the
|
||||
binaries associated with the change you made rather than testing all of
|
||||
them.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="submitting-changes-contribution-standards">
|
||||
<title>Meets Nixpkgs contribution standards</title>
|
||||
|
||||
<para>
|
||||
The last checkbox is fits
|
||||
<link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md">CONTRIBUTING.md</link>.
|
||||
The contributing document has detailed information on standards the Nix
|
||||
community has for commit messages, reviews, licensing of contributions you
|
||||
make to the project, etc... Everyone should read and understand the
|
||||
standards the community has for contributing before submitting a pull
|
||||
request.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="submitting-changes-hotfixing-pull-requests">
|
||||
<title>Hotfixing pull requests</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Make the appropriate changes in you branch.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Don't create additional commits, do
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<command>git rebase -i</command>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<command>git push --force</command> to your branch.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section xml:id="submitting-changes-commit-policy">
|
||||
<title>Commit policy</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Commits must be sufficiently tested before being merged, both for the
|
||||
master and staging branches.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Hydra builds for master and staging should not be used as testing
|
||||
platform, it's a build farm for changes that have been already tested.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
When changing the bootloader installation process, extra care must be
|
||||
taken. Grub installations cannot be rolled back, hence changes may break
|
||||
people's installations forever. For any non-trivial change to the
|
||||
bootloader please file a PR asking for review, especially from @edolstra.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<section xml:id="submitting-changes-master-branch">
|
||||
<title>Master branch</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
It should only see non-breaking commits that do not cause mass rebuilds.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section xml:id="submitting-changes-staging-branch">
|
||||
<title>Staging branch</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
It's only for non-breaking mass-rebuild commits. That means it's not to
|
||||
be used for testing, and changes must have been well tested already.
|
||||
<link xlink:href="https://web.archive.org/web/20160528180406/http://comments.gmane.org/gmane.linux.distributions.nixos/13447">Read
|
||||
policy here</link>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If the branch is already in a broken state, please refrain from adding
|
||||
extra new breakages. Stabilize it for a few days, merge into master, then
|
||||
resume development on staging.
|
||||
<link xlink:href="http://hydra.nixos.org/jobset/nixpkgs/staging#tabs-evaluations">Keep
|
||||
an eye on the staging evaluations here</link>. If any fixes for staging
|
||||
happen to be already in master, then master can be merged into staging.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section xml:id="submitting-changes-stable-release-branches">
|
||||
<title>Stable release branches</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
If you're cherry-picking a commit to a stable release branch, always use
|
||||
<command>git cherry-pick -xe</command> and ensure the message contains a
|
||||
clear description about why this needs to be included in the stable
|
||||
branch.
|
||||
</para>
|
||||
<para>
|
||||
An example of a cherry-picked commit would look like this:
|
||||
</para>
|
||||
<screen>
|
||||
nixos: Refactor the world.
|
||||
|
||||
The original commit message describing the reason why the world was torn apart.
|
||||
|
||||
(cherry picked from commit abcdef)
|
||||
Reason: I just had a gut feeling that this would also be wanted by people from
|
||||
the stone age.
|
||||
</screen>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</section>
|
||||
</chapter>
|
||||
@@ -1,44 +0,0 @@
|
||||
{ lib }:
|
||||
|
||||
rec {
|
||||
|
||||
/* Print a trace message if pred is false.
|
||||
Intended to be used to augment asserts with helpful error messages.
|
||||
|
||||
Example:
|
||||
assertMsg false "nope"
|
||||
=> false
|
||||
stderr> trace: nope
|
||||
|
||||
assert (assertMsg ("foo" == "bar") "foo is not bar, silly"); ""
|
||||
stderr> trace: foo is not bar, silly
|
||||
stderr> assert failed at …
|
||||
|
||||
Type:
|
||||
assertMsg :: Bool -> String -> Bool
|
||||
*/
|
||||
# TODO(Profpatsch): add tests that check stderr
|
||||
assertMsg = pred: msg:
|
||||
if pred
|
||||
then true
|
||||
else builtins.trace msg false;
|
||||
|
||||
/* Specialized `assertMsg` for checking if val is one of the elements
|
||||
of a list. Useful for checking enums.
|
||||
|
||||
Example:
|
||||
let sslLibrary = "libressl"
|
||||
in assertOneOf "sslLibrary" sslLibrary [ "openssl" "bearssl" ]
|
||||
=> false
|
||||
stderr> trace: sslLibrary must be one of "openssl", "bearssl", but is: "libressl"
|
||||
|
||||
Type:
|
||||
assertOneOf :: String -> ComparableVal -> List ComparableVal -> Bool
|
||||
*/
|
||||
assertOneOf = name: val: xs: assertMsg
|
||||
(lib.elem val xs)
|
||||
"${name} must be one of ${
|
||||
lib.generators.toPretty {} xs}, but is: ${
|
||||
lib.generators.toPretty {} val}";
|
||||
|
||||
}
|
||||
482
lib/attrsets.nix
482
lib/attrsets.nix
@@ -1,482 +0,0 @@
|
||||
{ lib }:
|
||||
# Operations on attribute sets.
|
||||
|
||||
let
|
||||
inherit (builtins) head tail length;
|
||||
inherit (lib.trivial) and;
|
||||
inherit (lib.strings) concatStringsSep;
|
||||
inherit (lib.lists) fold concatMap concatLists;
|
||||
in
|
||||
|
||||
rec {
|
||||
inherit (builtins) attrNames listToAttrs hasAttr isAttrs getAttr;
|
||||
|
||||
|
||||
/* Return an attribute from nested attribute sets.
|
||||
|
||||
Example:
|
||||
x = { a = { b = 3; }; }
|
||||
attrByPath ["a" "b"] 6 x
|
||||
=> 3
|
||||
attrByPath ["z" "z"] 6 x
|
||||
=> 6
|
||||
*/
|
||||
attrByPath = attrPath: default: e:
|
||||
let attr = head attrPath;
|
||||
in
|
||||
if attrPath == [] then e
|
||||
else if e ? ${attr}
|
||||
then attrByPath (tail attrPath) default e.${attr}
|
||||
else default;
|
||||
|
||||
/* Return if an attribute from nested attribute set exists.
|
||||
|
||||
Example:
|
||||
x = { a = { b = 3; }; }
|
||||
hasAttrByPath ["a" "b"] x
|
||||
=> true
|
||||
hasAttrByPath ["z" "z"] x
|
||||
=> false
|
||||
|
||||
*/
|
||||
hasAttrByPath = attrPath: e:
|
||||
let attr = head attrPath;
|
||||
in
|
||||
if attrPath == [] then true
|
||||
else if e ? ${attr}
|
||||
then hasAttrByPath (tail attrPath) e.${attr}
|
||||
else false;
|
||||
|
||||
|
||||
/* Return nested attribute set in which an attribute is set.
|
||||
|
||||
Example:
|
||||
setAttrByPath ["a" "b"] 3
|
||||
=> { a = { b = 3; }; }
|
||||
*/
|
||||
setAttrByPath = attrPath: value:
|
||||
if attrPath == [] then value
|
||||
else listToAttrs
|
||||
[ { name = head attrPath; value = setAttrByPath (tail attrPath) value; } ];
|
||||
|
||||
|
||||
/* Like `getAttrPath' without a default value. If it doesn't find the
|
||||
path it will throw.
|
||||
|
||||
Example:
|
||||
x = { a = { b = 3; }; }
|
||||
getAttrFromPath ["a" "b"] x
|
||||
=> 3
|
||||
getAttrFromPath ["z" "z"] x
|
||||
=> error: cannot find attribute `z.z'
|
||||
*/
|
||||
getAttrFromPath = attrPath: set:
|
||||
let errorMsg = "cannot find attribute `" + concatStringsSep "." attrPath + "'";
|
||||
in attrByPath attrPath (abort errorMsg) set;
|
||||
|
||||
|
||||
/* Return the specified attributes from a set.
|
||||
|
||||
Example:
|
||||
attrVals ["a" "b" "c"] as
|
||||
=> [as.a as.b as.c]
|
||||
*/
|
||||
attrVals = nameList: set: map (x: set.${x}) nameList;
|
||||
|
||||
|
||||
/* Return the values of all attributes in the given set, sorted by
|
||||
attribute name.
|
||||
|
||||
Example:
|
||||
attrValues {c = 3; a = 1; b = 2;}
|
||||
=> [1 2 3]
|
||||
*/
|
||||
attrValues = builtins.attrValues or (attrs: attrVals (attrNames attrs) attrs);
|
||||
|
||||
|
||||
/* Given a set of attribute names, return the set of the corresponding
|
||||
attributes from the given set.
|
||||
|
||||
Example:
|
||||
getAttrs [ "a" "b" ] { a = 1; b = 2; c = 3; }
|
||||
=> { a = 1; b = 2; }
|
||||
*/
|
||||
getAttrs = names: attrs: genAttrs names (name: attrs.${name});
|
||||
|
||||
/* Collect each attribute named `attr' from a list of attribute
|
||||
sets. Sets that don't contain the named attribute are ignored.
|
||||
|
||||
Example:
|
||||
catAttrs "a" [{a = 1;} {b = 0;} {a = 2;}]
|
||||
=> [1 2]
|
||||
*/
|
||||
catAttrs = builtins.catAttrs or
|
||||
(attr: l: concatLists (map (s: if s ? ${attr} then [s.${attr}] else []) l));
|
||||
|
||||
|
||||
/* Filter an attribute set by removing all attributes for which the
|
||||
given predicate return false.
|
||||
|
||||
Example:
|
||||
filterAttrs (n: v: n == "foo") { foo = 1; bar = 2; }
|
||||
=> { foo = 1; }
|
||||
*/
|
||||
filterAttrs = pred: set:
|
||||
listToAttrs (concatMap (name: let v = set.${name}; in if pred name v then [(nameValuePair name v)] else []) (attrNames set));
|
||||
|
||||
|
||||
/* Filter an attribute set recursively by removing all attributes for
|
||||
which the given predicate return false.
|
||||
|
||||
Example:
|
||||
filterAttrsRecursive (n: v: v != null) { foo = { bar = null; }; }
|
||||
=> { foo = {}; }
|
||||
*/
|
||||
filterAttrsRecursive = pred: set:
|
||||
listToAttrs (
|
||||
concatMap (name:
|
||||
let v = set.${name}; in
|
||||
if pred name v then [
|
||||
(nameValuePair name (
|
||||
if isAttrs v then filterAttrsRecursive pred v
|
||||
else v
|
||||
))
|
||||
] else []
|
||||
) (attrNames set)
|
||||
);
|
||||
|
||||
/* Apply fold functions to values grouped by key.
|
||||
|
||||
Example:
|
||||
foldAttrs (n: a: [n] ++ a) [] [{ a = 2; } { a = 3; }]
|
||||
=> { a = [ 2 3 ]; }
|
||||
*/
|
||||
foldAttrs = op: nul: list_of_attrs:
|
||||
fold (n: a:
|
||||
fold (name: o:
|
||||
o // { ${name} = op n.${name} (a.${name} or nul); }
|
||||
) a (attrNames n)
|
||||
) {} list_of_attrs;
|
||||
|
||||
|
||||
/* Recursively collect sets that verify a given predicate named `pred'
|
||||
from the set `attrs'. The recursion is stopped when the predicate is
|
||||
verified.
|
||||
|
||||
Type:
|
||||
collect ::
|
||||
(AttrSet -> Bool) -> AttrSet -> [x]
|
||||
|
||||
Example:
|
||||
collect isList { a = { b = ["b"]; }; c = [1]; }
|
||||
=> [["b"] [1]]
|
||||
|
||||
collect (x: x ? outPath)
|
||||
{ a = { outPath = "a/"; }; b = { outPath = "b/"; }; }
|
||||
=> [{ outPath = "a/"; } { outPath = "b/"; }]
|
||||
*/
|
||||
collect = pred: attrs:
|
||||
if pred attrs then
|
||||
[ attrs ]
|
||||
else if isAttrs attrs then
|
||||
concatMap (collect pred) (attrValues attrs)
|
||||
else
|
||||
[];
|
||||
|
||||
|
||||
/* Utility function that creates a {name, value} pair as expected by
|
||||
builtins.listToAttrs.
|
||||
|
||||
Example:
|
||||
nameValuePair "some" 6
|
||||
=> { name = "some"; value = 6; }
|
||||
*/
|
||||
nameValuePair = name: value: { inherit name value; };
|
||||
|
||||
|
||||
/* Apply a function to each element in an attribute set. The
|
||||
function takes two arguments --- the attribute name and its value
|
||||
--- and returns the new value for the attribute. The result is a
|
||||
new attribute set.
|
||||
|
||||
Example:
|
||||
mapAttrs (name: value: name + "-" + value)
|
||||
{ x = "foo"; y = "bar"; }
|
||||
=> { x = "x-foo"; y = "y-bar"; }
|
||||
*/
|
||||
mapAttrs = builtins.mapAttrs or
|
||||
(f: set:
|
||||
listToAttrs (map (attr: { name = attr; value = f attr set.${attr}; }) (attrNames set)));
|
||||
|
||||
|
||||
/* Like `mapAttrs', but allows the name of each attribute to be
|
||||
changed in addition to the value. The applied function should
|
||||
return both the new name and value as a `nameValuePair'.
|
||||
|
||||
Example:
|
||||
mapAttrs' (name: value: nameValuePair ("foo_" + name) ("bar-" + value))
|
||||
{ x = "a"; y = "b"; }
|
||||
=> { foo_x = "bar-a"; foo_y = "bar-b"; }
|
||||
*/
|
||||
mapAttrs' = f: set:
|
||||
listToAttrs (map (attr: f attr set.${attr}) (attrNames set));
|
||||
|
||||
|
||||
/* Call a function for each attribute in the given set and return
|
||||
the result in a list.
|
||||
|
||||
Example:
|
||||
mapAttrsToList (name: value: name + value)
|
||||
{ x = "a"; y = "b"; }
|
||||
=> [ "xa" "yb" ]
|
||||
*/
|
||||
mapAttrsToList = f: attrs:
|
||||
map (name: f name attrs.${name}) (attrNames attrs);
|
||||
|
||||
|
||||
/* Like `mapAttrs', except that it recursively applies itself to
|
||||
attribute sets. Also, the first argument of the argument
|
||||
function is a *list* of the names of the containing attributes.
|
||||
|
||||
Type:
|
||||
mapAttrsRecursive ::
|
||||
([String] -> a -> b) -> AttrSet -> AttrSet
|
||||
|
||||
Example:
|
||||
mapAttrsRecursive (path: value: concatStringsSep "-" (path ++ [value]))
|
||||
{ n = { a = "A"; m = { b = "B"; c = "C"; }; }; d = "D"; }
|
||||
=> { n = { a = "n-a-A"; m = { b = "n-m-b-B"; c = "n-m-c-C"; }; }; d = "d-D"; }
|
||||
*/
|
||||
mapAttrsRecursive = mapAttrsRecursiveCond (as: true);
|
||||
|
||||
|
||||
/* Like `mapAttrsRecursive', but it takes an additional predicate
|
||||
function that tells it whether to recursive into an attribute
|
||||
set. If it returns false, `mapAttrsRecursiveCond' does not
|
||||
recurse, but does apply the map function. It is returns true, it
|
||||
does recurse, and does not apply the map function.
|
||||
|
||||
Type:
|
||||
mapAttrsRecursiveCond ::
|
||||
(AttrSet -> Bool) -> ([String] -> a -> b) -> AttrSet -> AttrSet
|
||||
|
||||
Example:
|
||||
# To prevent recursing into derivations (which are attribute
|
||||
# sets with the attribute "type" equal to "derivation"):
|
||||
mapAttrsRecursiveCond
|
||||
(as: !(as ? "type" && as.type == "derivation"))
|
||||
(x: ... do something ...)
|
||||
attrs
|
||||
*/
|
||||
mapAttrsRecursiveCond = cond: f: set:
|
||||
let
|
||||
recurse = path: set:
|
||||
let
|
||||
g =
|
||||
name: value:
|
||||
if isAttrs value && cond value
|
||||
then recurse (path ++ [name]) value
|
||||
else f (path ++ [name]) value;
|
||||
in mapAttrs g set;
|
||||
in recurse [] set;
|
||||
|
||||
|
||||
/* Generate an attribute set by mapping a function over a list of
|
||||
attribute names.
|
||||
|
||||
Example:
|
||||
genAttrs [ "foo" "bar" ] (name: "x_" + name)
|
||||
=> { foo = "x_foo"; bar = "x_bar"; }
|
||||
*/
|
||||
genAttrs = names: f:
|
||||
listToAttrs (map (n: nameValuePair n (f n)) names);
|
||||
|
||||
|
||||
/* Check whether the argument is a derivation. Any set with
|
||||
{ type = "derivation"; } counts as a derivation.
|
||||
|
||||
Example:
|
||||
nixpkgs = import <nixpkgs> {}
|
||||
isDerivation nixpkgs.ruby
|
||||
=> true
|
||||
isDerivation "foobar"
|
||||
=> false
|
||||
*/
|
||||
isDerivation = x: isAttrs x && x ? type && x.type == "derivation";
|
||||
|
||||
/* Converts a store path to a fake derivation. */
|
||||
toDerivation = path:
|
||||
let
|
||||
path' = builtins.storePath path;
|
||||
res =
|
||||
{ type = "derivation";
|
||||
name = builtins.unsafeDiscardStringContext (builtins.substring 33 (-1) (baseNameOf path'));
|
||||
outPath = path';
|
||||
outputs = [ "out" ];
|
||||
out = res;
|
||||
outputName = "out";
|
||||
};
|
||||
in res;
|
||||
|
||||
|
||||
/* If `cond' is true, return the attribute set `as',
|
||||
otherwise an empty attribute set.
|
||||
|
||||
Example:
|
||||
optionalAttrs (true) { my = "set"; }
|
||||
=> { my = "set"; }
|
||||
optionalAttrs (false) { my = "set"; }
|
||||
=> { }
|
||||
*/
|
||||
optionalAttrs = cond: as: if cond then as else {};
|
||||
|
||||
|
||||
/* Merge sets of attributes and use the function f to merge attributes
|
||||
values.
|
||||
|
||||
Example:
|
||||
zipAttrsWithNames ["a"] (name: vs: vs) [{a = "x";} {a = "y"; b = "z";}]
|
||||
=> { a = ["x" "y"]; }
|
||||
*/
|
||||
zipAttrsWithNames = names: f: sets:
|
||||
listToAttrs (map (name: {
|
||||
inherit name;
|
||||
value = f name (catAttrs name sets);
|
||||
}) names);
|
||||
|
||||
/* Implementation note: Common names appear multiple times in the list of
|
||||
names, hopefully this does not affect the system because the maximal
|
||||
laziness avoid computing twice the same expression and listToAttrs does
|
||||
not care about duplicated attribute names.
|
||||
|
||||
Example:
|
||||
zipAttrsWith (name: values: values) [{a = "x";} {a = "y"; b = "z";}]
|
||||
=> { a = ["x" "y"]; b = ["z"] }
|
||||
*/
|
||||
zipAttrsWith = f: sets: zipAttrsWithNames (concatMap attrNames sets) f sets;
|
||||
/* Like `zipAttrsWith' with `(name: values: value)' as the function.
|
||||
|
||||
Example:
|
||||
zipAttrs [{a = "x";} {a = "y"; b = "z";}]
|
||||
=> { a = ["x" "y"]; b = ["z"] }
|
||||
*/
|
||||
zipAttrs = zipAttrsWith (name: values: values);
|
||||
|
||||
/* Does the same as the update operator '//' except that attributes are
|
||||
merged until the given predicate is verified. The predicate should
|
||||
accept 3 arguments which are the path to reach the attribute, a part of
|
||||
the first attribute set and a part of the second attribute set. When
|
||||
the predicate is verified, the value of the first attribute set is
|
||||
replaced by the value of the second attribute set.
|
||||
|
||||
Example:
|
||||
recursiveUpdateUntil (path: l: r: path == ["foo"]) {
|
||||
# first attribute set
|
||||
foo.bar = 1;
|
||||
foo.baz = 2;
|
||||
bar = 3;
|
||||
} {
|
||||
#second attribute set
|
||||
foo.bar = 1;
|
||||
foo.quz = 2;
|
||||
baz = 4;
|
||||
}
|
||||
|
||||
returns: {
|
||||
foo.bar = 1; # 'foo.*' from the second set
|
||||
foo.quz = 2; #
|
||||
bar = 3; # 'bar' from the first set
|
||||
baz = 4; # 'baz' from the second set
|
||||
}
|
||||
|
||||
*/
|
||||
recursiveUpdateUntil = pred: lhs: rhs:
|
||||
let f = attrPath:
|
||||
zipAttrsWith (n: values:
|
||||
let here = attrPath ++ [n]; in
|
||||
if tail values == []
|
||||
|| pred here (head (tail values)) (head values) then
|
||||
head values
|
||||
else
|
||||
f here values
|
||||
);
|
||||
in f [] [rhs lhs];
|
||||
|
||||
/* A recursive variant of the update operator ‘//’. The recursion
|
||||
stops when one of the attribute values is not an attribute set,
|
||||
in which case the right hand side value takes precedence over the
|
||||
left hand side value.
|
||||
|
||||
Example:
|
||||
recursiveUpdate {
|
||||
boot.loader.grub.enable = true;
|
||||
boot.loader.grub.device = "/dev/hda";
|
||||
} {
|
||||
boot.loader.grub.device = "";
|
||||
}
|
||||
|
||||
returns: {
|
||||
boot.loader.grub.enable = true;
|
||||
boot.loader.grub.device = "";
|
||||
}
|
||||
|
||||
*/
|
||||
recursiveUpdate = lhs: rhs:
|
||||
recursiveUpdateUntil (path: lhs: rhs:
|
||||
!(isAttrs lhs && isAttrs rhs)
|
||||
) lhs rhs;
|
||||
|
||||
/* Returns true if the pattern is contained in the set. False otherwise.
|
||||
|
||||
Example:
|
||||
matchAttrs { cpu = {}; } { cpu = { bits = 64; }; }
|
||||
=> true
|
||||
*/
|
||||
matchAttrs = pattern: attrs: assert isAttrs pattern;
|
||||
fold and true (attrValues (zipAttrsWithNames (attrNames pattern) (n: values:
|
||||
let pat = head values; val = head (tail values); in
|
||||
if length values == 1 then false
|
||||
else if isAttrs pat then isAttrs val && matchAttrs pat val
|
||||
else pat == val
|
||||
) [pattern attrs]));
|
||||
|
||||
/* Override only the attributes that are already present in the old set
|
||||
useful for deep-overriding.
|
||||
|
||||
Example:
|
||||
overrideExisting {} { a = 1; }
|
||||
=> {}
|
||||
overrideExisting { b = 2; } { a = 1; }
|
||||
=> { b = 2; }
|
||||
overrideExisting { a = 3; b = 2; } { a = 1; }
|
||||
=> { a = 1; b = 2; }
|
||||
*/
|
||||
overrideExisting = old: new:
|
||||
mapAttrs (name: value: new.${name} or value) old;
|
||||
|
||||
/* Get a package output.
|
||||
If no output is found, fallback to `.out` and then to the default.
|
||||
|
||||
Example:
|
||||
getOutput "dev" pkgs.openssl
|
||||
=> "/nix/store/9rz8gxhzf8sw4kf2j2f1grr49w8zx5vj-openssl-1.0.1r-dev"
|
||||
*/
|
||||
getOutput = output: pkg:
|
||||
if pkg.outputUnspecified or false
|
||||
then pkg.${output} or pkg.out or pkg
|
||||
else pkg;
|
||||
|
||||
getBin = getOutput "bin";
|
||||
getLib = getOutput "lib";
|
||||
getDev = getOutput "dev";
|
||||
|
||||
/* Pick the outputs of packages to place in buildInputs */
|
||||
chooseDevOutputs = drvs: builtins.map getDev drvs;
|
||||
|
||||
/*** deprecated stuff ***/
|
||||
|
||||
zipWithNames = zipAttrsWithNames;
|
||||
zip = builtins.trace
|
||||
"lib.zip is deprecated, use lib.zipAttrsWith instead" zipAttrsWith;
|
||||
|
||||
}
|
||||
@@ -1,206 +0,0 @@
|
||||
{ lib }:
|
||||
|
||||
rec {
|
||||
|
||||
|
||||
/* `overrideDerivation drv f' takes a derivation (i.e., the result
|
||||
of a call to the builtin function `derivation') and returns a new
|
||||
derivation in which the attributes of the original are overridden
|
||||
according to the function `f'. The function `f' is called with
|
||||
the original derivation attributes.
|
||||
|
||||
`overrideDerivation' allows certain "ad-hoc" customisation
|
||||
scenarios (e.g. in ~/.config/nixpkgs/config.nix). For instance,
|
||||
if you want to "patch" the derivation returned by a package
|
||||
function in Nixpkgs to build another version than what the
|
||||
function itself provides, you can do something like this:
|
||||
|
||||
mySed = overrideDerivation pkgs.gnused (oldAttrs: {
|
||||
name = "sed-4.2.2-pre";
|
||||
src = fetchurl {
|
||||
url = ftp://alpha.gnu.org/gnu/sed/sed-4.2.2-pre.tar.bz2;
|
||||
sha256 = "11nq06d131y4wmf3drm0yk502d2xc6n5qy82cg88rb9nqd2lj41k";
|
||||
};
|
||||
patches = [];
|
||||
});
|
||||
|
||||
For another application, see build-support/vm, where this
|
||||
function is used to build arbitrary derivations inside a QEMU
|
||||
virtual machine.
|
||||
*/
|
||||
overrideDerivation = drv: f:
|
||||
let
|
||||
newDrv = derivation (drv.drvAttrs // (f drv));
|
||||
in lib.flip (extendDerivation true) newDrv (
|
||||
{ meta = drv.meta or {};
|
||||
passthru = if drv ? passthru then drv.passthru else {};
|
||||
}
|
||||
//
|
||||
(drv.passthru or {})
|
||||
//
|
||||
(if (drv ? crossDrv && drv ? nativeDrv)
|
||||
then {
|
||||
crossDrv = overrideDerivation drv.crossDrv f;
|
||||
nativeDrv = overrideDerivation drv.nativeDrv f;
|
||||
}
|
||||
else { }));
|
||||
|
||||
|
||||
/* `makeOverridable` takes a function from attribute set to attribute set and
|
||||
injects `override` attibute which can be used to override arguments of
|
||||
the function.
|
||||
|
||||
nix-repl> x = {a, b}: { result = a + b; }
|
||||
|
||||
nix-repl> y = lib.makeOverridable x { a = 1; b = 2; }
|
||||
|
||||
nix-repl> y
|
||||
{ override = «lambda»; overrideDerivation = «lambda»; result = 3; }
|
||||
|
||||
nix-repl> y.override { a = 10; }
|
||||
{ override = «lambda»; overrideDerivation = «lambda»; result = 12; }
|
||||
|
||||
Please refer to "Nixpkgs Contributors Guide" section
|
||||
"<pkg>.overrideDerivation" to learn about `overrideDerivation` and caveats
|
||||
related to its use.
|
||||
*/
|
||||
makeOverridable = f: origArgs:
|
||||
let
|
||||
ff = f origArgs;
|
||||
overrideWith = newArgs: origArgs // (if lib.isFunction newArgs then newArgs origArgs else newArgs);
|
||||
in
|
||||
if builtins.isAttrs ff then (ff // {
|
||||
override = newArgs: makeOverridable f (overrideWith newArgs);
|
||||
overrideDerivation = fdrv:
|
||||
makeOverridable (args: overrideDerivation (f args) fdrv) origArgs;
|
||||
${if ff ? overrideAttrs then "overrideAttrs" else null} = fdrv:
|
||||
makeOverridable (args: (f args).overrideAttrs fdrv) origArgs;
|
||||
})
|
||||
else if lib.isFunction ff then {
|
||||
override = newArgs: makeOverridable f (overrideWith newArgs);
|
||||
__functor = self: ff;
|
||||
overrideDerivation = throw "overrideDerivation not yet supported for functors";
|
||||
}
|
||||
else ff;
|
||||
|
||||
|
||||
/* Call the package function in the file `fn' with the required
|
||||
arguments automatically. The function is called with the
|
||||
arguments `args', but any missing arguments are obtained from
|
||||
`autoArgs'. This function is intended to be partially
|
||||
parameterised, e.g.,
|
||||
|
||||
callPackage = callPackageWith pkgs;
|
||||
pkgs = {
|
||||
libfoo = callPackage ./foo.nix { };
|
||||
libbar = callPackage ./bar.nix { };
|
||||
};
|
||||
|
||||
If the `libbar' function expects an argument named `libfoo', it is
|
||||
automatically passed as an argument. Overrides or missing
|
||||
arguments can be supplied in `args', e.g.
|
||||
|
||||
libbar = callPackage ./bar.nix {
|
||||
libfoo = null;
|
||||
enableX11 = true;
|
||||
};
|
||||
*/
|
||||
callPackageWith = autoArgs: fn: args:
|
||||
let
|
||||
f = if lib.isFunction fn then fn else import fn;
|
||||
auto = builtins.intersectAttrs (lib.functionArgs f) autoArgs;
|
||||
in makeOverridable f (auto // args);
|
||||
|
||||
|
||||
/* Like callPackage, but for a function that returns an attribute
|
||||
set of derivations. The override function is added to the
|
||||
individual attributes. */
|
||||
callPackagesWith = autoArgs: fn: args:
|
||||
let
|
||||
f = if lib.isFunction fn then fn else import fn;
|
||||
auto = builtins.intersectAttrs (lib.functionArgs f) autoArgs;
|
||||
origArgs = auto // args;
|
||||
pkgs = f origArgs;
|
||||
mkAttrOverridable = name: _: makeOverridable (newArgs: (f newArgs).${name}) origArgs;
|
||||
in lib.mapAttrs mkAttrOverridable pkgs;
|
||||
|
||||
|
||||
/* Add attributes to each output of a derivation without changing
|
||||
the derivation itself and check a given condition when evaluating. */
|
||||
extendDerivation = condition: passthru: drv:
|
||||
let
|
||||
outputs = drv.outputs or [ "out" ];
|
||||
|
||||
commonAttrs = drv // (builtins.listToAttrs outputsList) //
|
||||
({ all = map (x: x.value) outputsList; }) // passthru;
|
||||
|
||||
outputToAttrListElement = outputName:
|
||||
{ name = outputName;
|
||||
value = commonAttrs // {
|
||||
inherit (drv.${outputName}) type outputName;
|
||||
drvPath = assert condition; drv.${outputName}.drvPath;
|
||||
outPath = assert condition; drv.${outputName}.outPath;
|
||||
};
|
||||
};
|
||||
|
||||
outputsList = map outputToAttrListElement outputs;
|
||||
in commonAttrs // {
|
||||
outputUnspecified = true;
|
||||
drvPath = assert condition; drv.drvPath;
|
||||
outPath = assert condition; drv.outPath;
|
||||
};
|
||||
|
||||
/* Strip a derivation of all non-essential attributes, returning
|
||||
only those needed by hydra-eval-jobs. Also strictly evaluate the
|
||||
result to ensure that there are no thunks kept alive to prevent
|
||||
garbage collection. */
|
||||
hydraJob = drv:
|
||||
let
|
||||
outputs = drv.outputs or ["out"];
|
||||
|
||||
commonAttrs =
|
||||
{ inherit (drv) name system meta; inherit outputs; }
|
||||
// lib.optionalAttrs (drv._hydraAggregate or false) {
|
||||
_hydraAggregate = true;
|
||||
constituents = map hydraJob (lib.flatten drv.constituents);
|
||||
}
|
||||
// (lib.listToAttrs outputsList);
|
||||
|
||||
makeOutput = outputName:
|
||||
let output = drv.${outputName}; in
|
||||
{ name = outputName;
|
||||
value = commonAttrs // {
|
||||
outPath = output.outPath;
|
||||
drvPath = output.drvPath;
|
||||
type = "derivation";
|
||||
inherit outputName;
|
||||
};
|
||||
};
|
||||
|
||||
outputsList = map makeOutput outputs;
|
||||
|
||||
drv' = (lib.head outputsList).value;
|
||||
in lib.deepSeq drv' drv';
|
||||
|
||||
/* Make a set of packages with a common scope. All packages called
|
||||
with the provided `callPackage' will be evaluated with the same
|
||||
arguments. Any package in the set may depend on any other. The
|
||||
`overrideScope'` function allows subsequent modification of the package
|
||||
set in a consistent way, i.e. all packages in the set will be
|
||||
called with the overridden packages. The package sets may be
|
||||
hierarchical: the packages in the set are called with the scope
|
||||
provided by `newScope' and the set provides a `newScope' attribute
|
||||
which can form the parent scope for later package sets. */
|
||||
makeScope = newScope: f:
|
||||
let self = f self // {
|
||||
newScope = scope: newScope (self // scope);
|
||||
callPackage = self.newScope {};
|
||||
overrideScope = g: lib.warn
|
||||
"`overrideScope` (from `lib.makeScope`) is deprecated. Do `overrideScope' (self: super: { … })` instead of `overrideScope (super: self: { … })`. All other overrides have the parameters in that order, including other definitions of `overrideScope`. This was the only definition violating the pattern."
|
||||
(makeScope newScope (lib.fixedPoints.extends (lib.flip g) f));
|
||||
overrideScope' = g: makeScope newScope (lib.fixedPoints.extends g f);
|
||||
packages = f;
|
||||
};
|
||||
in self;
|
||||
|
||||
}
|
||||
253
lib/debug.nix
253
lib/debug.nix
@@ -1,253 +0,0 @@
|
||||
/* Collection of functions useful for debugging
|
||||
broken nix expressions.
|
||||
|
||||
* `trace`-like functions take two values, print
|
||||
the first to stderr and return the second.
|
||||
* `traceVal`-like functions take one argument
|
||||
which both printed and returned.
|
||||
* `traceSeq`-like functions fully evaluate their
|
||||
traced value before printing (not just to “weak
|
||||
head normal form” like trace does by default).
|
||||
* Functions that end in `-Fn` take an additional
|
||||
function as their first argument, which is applied
|
||||
to the traced value before it is printed.
|
||||
*/
|
||||
{ lib }:
|
||||
let
|
||||
inherit (builtins) trace isAttrs isList isInt
|
||||
head substring attrNames;
|
||||
inherit (lib) id elem isFunction;
|
||||
in
|
||||
|
||||
rec {
|
||||
|
||||
# -- TRACING --
|
||||
|
||||
/* Conditionally trace the supplied message, based on a predicate.
|
||||
|
||||
Type: traceIf :: bool -> string -> a -> a
|
||||
|
||||
Example:
|
||||
traceIf true "hello" 3
|
||||
trace: hello
|
||||
=> 3
|
||||
*/
|
||||
traceIf =
|
||||
# Predicate to check
|
||||
pred:
|
||||
# Message that should be traced
|
||||
msg:
|
||||
# Value to return
|
||||
x: if pred then trace msg x else x;
|
||||
|
||||
/* Trace the supplied value after applying a function to it, and
|
||||
return the original value.
|
||||
|
||||
Type: traceValFn :: (a -> b) -> a -> a
|
||||
|
||||
Example:
|
||||
traceValFn (v: "mystring ${v}") "foo"
|
||||
trace: mystring foo
|
||||
=> "foo"
|
||||
*/
|
||||
traceValFn =
|
||||
# Function to apply
|
||||
f:
|
||||
# Value to trace and return
|
||||
x: trace (f x) x;
|
||||
|
||||
/* Trace the supplied value and return it.
|
||||
|
||||
Type: traceVal :: a -> a
|
||||
|
||||
Example:
|
||||
traceVal 42
|
||||
# trace: 42
|
||||
=> 42
|
||||
*/
|
||||
traceVal = traceValFn id;
|
||||
|
||||
/* `builtins.trace`, but the value is `builtins.deepSeq`ed first.
|
||||
|
||||
Type: traceSeq :: a -> b -> b
|
||||
|
||||
Example:
|
||||
trace { a.b.c = 3; } null
|
||||
trace: { a = <CODE>; }
|
||||
=> null
|
||||
traceSeq { a.b.c = 3; } null
|
||||
trace: { a = { b = { c = 3; }; }; }
|
||||
=> null
|
||||
*/
|
||||
traceSeq =
|
||||
# The value to trace
|
||||
x:
|
||||
# The value to return
|
||||
y: trace (builtins.deepSeq x x) y;
|
||||
|
||||
/* Like `traceSeq`, but only evaluate down to depth n.
|
||||
This is very useful because lots of `traceSeq` usages
|
||||
lead to an infinite recursion.
|
||||
|
||||
Example:
|
||||
traceSeqN 2 { a.b.c = 3; } null
|
||||
trace: { a = { b = {…}; }; }
|
||||
=> null
|
||||
*/
|
||||
traceSeqN = depth: x: y: with lib;
|
||||
let snip = v: if isList v then noQuotes "[…]" v
|
||||
else if isAttrs v then noQuotes "{…}" v
|
||||
else v;
|
||||
noQuotes = str: v: { __pretty = const str; val = v; };
|
||||
modify = n: fn: v: if (n == 0) then fn v
|
||||
else if isList v then map (modify (n - 1) fn) v
|
||||
else if isAttrs v then mapAttrs
|
||||
(const (modify (n - 1) fn)) v
|
||||
else v;
|
||||
in trace (generators.toPretty { allowPrettyValues = true; }
|
||||
(modify depth snip x)) y;
|
||||
|
||||
/* A combination of `traceVal` and `traceSeq` that applies a
|
||||
provided function to the value to be traced after `deepSeq`ing
|
||||
it.
|
||||
*/
|
||||
traceValSeqFn =
|
||||
# Function to apply
|
||||
f:
|
||||
# Value to trace
|
||||
v: traceValFn f (builtins.deepSeq v v);
|
||||
|
||||
/* A combination of `traceVal` and `traceSeq`. */
|
||||
traceValSeq = traceValSeqFn id;
|
||||
|
||||
/* A combination of `traceVal` and `traceSeqN` that applies a
|
||||
provided function to the value to be traced. */
|
||||
traceValSeqNFn =
|
||||
# Function to apply
|
||||
f:
|
||||
depth:
|
||||
# Value to trace
|
||||
v: traceSeqN depth (f v) v;
|
||||
|
||||
/* A combination of `traceVal` and `traceSeqN`. */
|
||||
traceValSeqN = traceValSeqNFn id;
|
||||
|
||||
|
||||
# -- TESTING --
|
||||
|
||||
/* Evaluate a set of tests. A test is an attribute set `{expr,
|
||||
expected}`, denoting an expression and its expected result. The
|
||||
result is a list of failed tests, each represented as `{name,
|
||||
expected, actual}`, denoting the attribute name of the failing
|
||||
test and its expected and actual results.
|
||||
|
||||
Used for regression testing of the functions in lib; see
|
||||
tests.nix for an example. Only tests having names starting with
|
||||
"test" are run.
|
||||
|
||||
Add attr { tests = ["testName"]; } to run these tests only.
|
||||
*/
|
||||
runTests =
|
||||
# Tests to run
|
||||
tests: lib.concatLists (lib.attrValues (lib.mapAttrs (name: test:
|
||||
let testsToRun = if tests ? tests then tests.tests else [];
|
||||
in if (substring 0 4 name == "test" || elem name testsToRun)
|
||||
&& ((testsToRun == []) || elem name tests.tests)
|
||||
&& (test.expr != test.expected)
|
||||
|
||||
then [ { inherit name; expected = test.expected; result = test.expr; } ]
|
||||
else [] ) tests));
|
||||
|
||||
/* Create a test assuming that list elements are `true`.
|
||||
|
||||
Example:
|
||||
{ testX = allTrue [ true ]; }
|
||||
*/
|
||||
testAllTrue = expr: { inherit expr; expected = map (x: true) expr; };
|
||||
|
||||
|
||||
# -- DEPRECATED --
|
||||
|
||||
traceShowVal = x: trace (showVal x) x;
|
||||
traceShowValMarked = str: x: trace (str + showVal x) x;
|
||||
|
||||
attrNamesToStr = a:
|
||||
trace ( "Warning: `attrNamesToStr` is deprecated "
|
||||
+ "and will be removed in the next release. "
|
||||
+ "Please use more specific concatenation "
|
||||
+ "for your uses (`lib.concat(Map)StringsSep`)." )
|
||||
(lib.concatStringsSep "; " (map (x: "${x}=") (attrNames a)));
|
||||
|
||||
showVal = with lib;
|
||||
trace ( "Warning: `showVal` is deprecated "
|
||||
+ "and will be removed in the next release, "
|
||||
+ "please use `traceSeqN`" )
|
||||
(let
|
||||
modify = v:
|
||||
let pr = f: { __pretty = f; val = v; };
|
||||
in if isDerivation v then pr
|
||||
(drv: "<δ:${drv.name}:${concatStringsSep ","
|
||||
(attrNames drv)}>")
|
||||
else if [] == v then pr (const "[]")
|
||||
else if isList v then pr (l: "[ ${go (head l)}, … ]")
|
||||
else if isAttrs v then pr
|
||||
(a: "{ ${ concatStringsSep ", " (attrNames a)} }")
|
||||
else v;
|
||||
go = x: generators.toPretty
|
||||
{ allowPrettyValues = true; }
|
||||
(modify x);
|
||||
in go);
|
||||
|
||||
traceXMLVal = x:
|
||||
trace ( "Warning: `traceXMLVal` is deprecated "
|
||||
+ "and will be removed in the next release. "
|
||||
+ "Please use `traceValFn builtins.toXML`." )
|
||||
(trace (builtins.toXML x) x);
|
||||
traceXMLValMarked = str: x:
|
||||
trace ( "Warning: `traceXMLValMarked` is deprecated "
|
||||
+ "and will be removed in the next release. "
|
||||
+ "Please use `traceValFn (x: str + builtins.toXML x)`." )
|
||||
(trace (str + builtins.toXML x) x);
|
||||
|
||||
# trace the arguments passed to function and its result
|
||||
# maybe rewrite these functions in a traceCallXml like style. Then one function is enough
|
||||
traceCall = n: f: a: let t = n2: x: traceShowValMarked "${n} ${n2}:" x; in t "result" (f (t "arg 1" a));
|
||||
traceCall2 = n: f: a: b: let t = n2: x: traceShowValMarked "${n} ${n2}:" x; in t "result" (f (t "arg 1" a) (t "arg 2" b));
|
||||
traceCall3 = n: f: a: b: c: let t = n2: x: traceShowValMarked "${n} ${n2}:" x; in t "result" (f (t "arg 1" a) (t "arg 2" b) (t "arg 3" c));
|
||||
|
||||
traceValIfNot = c: x:
|
||||
trace ( "Warning: `traceValIfNot` is deprecated "
|
||||
+ "and will be removed in the next release. "
|
||||
+ "Please use `if/then/else` and `traceValSeq 1`.")
|
||||
(if c x then true else traceSeq (showVal x) false);
|
||||
|
||||
|
||||
addErrorContextToAttrs = attrs:
|
||||
trace ( "Warning: `addErrorContextToAttrs` is deprecated "
|
||||
+ "and will be removed in the next release. "
|
||||
+ "Please use `builtins.addErrorContext` directly." )
|
||||
(lib.mapAttrs (a: v: lib.addErrorContext "while evaluating ${a}" v) attrs);
|
||||
|
||||
# example: (traceCallXml "myfun" id 3) will output something like
|
||||
# calling myfun arg 1: 3 result: 3
|
||||
# this forces deep evaluation of all arguments and the result!
|
||||
# note: if result doesn't evaluate you'll get no trace at all (FIXME)
|
||||
# args should be printed in any case
|
||||
traceCallXml = a:
|
||||
trace ( "Warning: `traceCallXml` is deprecated "
|
||||
+ "and will be removed in the next release. "
|
||||
+ "Please complain if you use the function regularly." )
|
||||
(if !isInt a then
|
||||
traceCallXml 1 "calling ${a}\n"
|
||||
else
|
||||
let nr = a;
|
||||
in (str: expr:
|
||||
if isFunction expr then
|
||||
(arg:
|
||||
traceCallXml (builtins.add 1 nr) "${str}\n arg ${builtins.toString nr} is \n ${builtins.toXML (builtins.seq arg arg)}" (expr arg)
|
||||
)
|
||||
else
|
||||
let r = builtins.seq expr expr;
|
||||
in trace "${str}\n result:\n${builtins.toXML r}" r
|
||||
));
|
||||
}
|
||||
138
lib/default.nix
138
lib/default.nix
@@ -1,138 +0,0 @@
|
||||
/* Library of low-level helper functions for nix expressions.
|
||||
*
|
||||
* Please implement (mostly) exhaustive unit tests
|
||||
* for new functions in `./tests.nix'.
|
||||
*/
|
||||
let
|
||||
|
||||
inherit (import ./fixed-points.nix {}) makeExtensible;
|
||||
|
||||
lib = makeExtensible (self: let
|
||||
callLibs = file: import file { lib = self; };
|
||||
in with self; {
|
||||
|
||||
# often used, or depending on very little
|
||||
trivial = callLibs ./trivial.nix;
|
||||
fixedPoints = callLibs ./fixed-points.nix;
|
||||
|
||||
# datatypes
|
||||
attrsets = callLibs ./attrsets.nix;
|
||||
lists = callLibs ./lists.nix;
|
||||
strings = callLibs ./strings.nix;
|
||||
stringsWithDeps = callLibs ./strings-with-deps.nix;
|
||||
|
||||
# packaging
|
||||
customisation = callLibs ./customisation.nix;
|
||||
maintainers = import ../maintainers/maintainer-list.nix;
|
||||
meta = callLibs ./meta.nix;
|
||||
sources = callLibs ./sources.nix;
|
||||
versions = callLibs ./versions.nix;
|
||||
|
||||
# module system
|
||||
modules = callLibs ./modules.nix;
|
||||
options = callLibs ./options.nix;
|
||||
types = callLibs ./types.nix;
|
||||
|
||||
# constants
|
||||
licenses = callLibs ./licenses.nix;
|
||||
systems = callLibs ./systems;
|
||||
|
||||
# misc
|
||||
asserts = callLibs ./asserts.nix;
|
||||
debug = callLibs ./debug.nix;
|
||||
generators = callLibs ./generators.nix;
|
||||
misc = callLibs ./deprecated.nix;
|
||||
|
||||
# domain-specific
|
||||
fetchers = callLibs ./fetchers.nix;
|
||||
|
||||
# Eval-time filesystem handling
|
||||
filesystem = callLibs ./filesystem.nix;
|
||||
|
||||
# back-compat aliases
|
||||
platforms = systems.forMeta;
|
||||
|
||||
inherit (builtins) add addErrorContext attrNames concatLists
|
||||
deepSeq elem elemAt filter genericClosure genList getAttr
|
||||
hasAttr head isAttrs isBool isInt isList isString length
|
||||
lessThan listToAttrs pathExists readFile replaceStrings seq
|
||||
stringLength sub substring tail;
|
||||
inherit (trivial) id const concat or and bitAnd bitOr bitXor bitNot
|
||||
boolToString mergeAttrs flip mapNullable inNixShell min max
|
||||
importJSON warn info nixpkgsVersion version mod compare
|
||||
splitByAndCompare functionArgs setFunctionArgs isFunction;
|
||||
inherit (fixedPoints) fix fix' converge extends composeExtensions
|
||||
makeExtensible makeExtensibleWithCustomName;
|
||||
inherit (attrsets) attrByPath hasAttrByPath setAttrByPath
|
||||
getAttrFromPath attrVals attrValues getAttrs catAttrs filterAttrs
|
||||
filterAttrsRecursive foldAttrs collect nameValuePair mapAttrs
|
||||
mapAttrs' mapAttrsToList mapAttrsRecursive mapAttrsRecursiveCond
|
||||
genAttrs isDerivation toDerivation optionalAttrs
|
||||
zipAttrsWithNames zipAttrsWith zipAttrs recursiveUpdateUntil
|
||||
recursiveUpdate matchAttrs overrideExisting getOutput getBin
|
||||
getLib getDev chooseDevOutputs zipWithNames zip;
|
||||
inherit (lists) singleton foldr fold foldl foldl' imap0 imap1
|
||||
concatMap flatten remove findSingle findFirst any all count
|
||||
optional optionals toList range partition zipListsWith zipLists
|
||||
reverseList listDfs toposort sort naturalSort compareLists take
|
||||
drop sublist last init crossLists unique intersectLists
|
||||
subtractLists mutuallyExclusive groupBy groupBy';
|
||||
inherit (strings) concatStrings concatMapStrings concatImapStrings
|
||||
intersperse concatStringsSep concatMapStringsSep
|
||||
concatImapStringsSep makeSearchPath makeSearchPathOutput
|
||||
makeLibraryPath makeBinPath optionalString
|
||||
hasPrefix hasSuffix stringToCharacters stringAsChars escape
|
||||
escapeShellArg escapeShellArgs replaceChars lowerChars
|
||||
upperChars toLower toUpper addContextFrom splitString
|
||||
removePrefix removeSuffix versionOlder versionAtLeast getVersion
|
||||
nameFromURL enableFeature enableFeatureAs withFeature
|
||||
withFeatureAs fixedWidthString fixedWidthNumber isStorePath
|
||||
toInt readPathsFromFile fileContents;
|
||||
inherit (stringsWithDeps) textClosureList textClosureMap
|
||||
noDepEntry fullDepEntry packEntry stringAfter;
|
||||
inherit (customisation) overrideDerivation makeOverridable
|
||||
callPackageWith callPackagesWith extendDerivation hydraJob
|
||||
makeScope;
|
||||
inherit (meta) addMetaAttrs dontDistribute setName updateName
|
||||
appendToName mapDerivationAttrset setPrio lowPrio lowPrioSet hiPrio
|
||||
hiPrioSet;
|
||||
inherit (sources) pathType pathIsDirectory cleanSourceFilter
|
||||
cleanSource sourceByRegex sourceFilesBySuffices
|
||||
commitIdFromGitRepo cleanSourceWith pathHasContext
|
||||
canCleanSource;
|
||||
inherit (modules) evalModules closeModules unifyModuleSyntax
|
||||
applyIfFunction unpackSubmodule packSubmodule mergeModules
|
||||
mergeModules' mergeOptionDecls evalOptionValue mergeDefinitions
|
||||
pushDownProperties dischargeProperties filterOverrides
|
||||
sortProperties fixupOptionType mkIf mkAssert mkMerge mkOverride
|
||||
mkOptionDefault mkDefault mkForce mkVMOverride mkStrict
|
||||
mkFixStrictness mkOrder mkBefore mkAfter mkAliasDefinitions
|
||||
mkAliasAndWrapDefinitions fixMergeModules mkRemovedOptionModule
|
||||
mkRenamedOptionModule mkMergedOptionModule mkChangedOptionModule
|
||||
mkAliasOptionModule doRename filterModules;
|
||||
inherit (options) isOption mkEnableOption mkSinkUndeclaredOptions
|
||||
mergeDefaultOption mergeOneOption mergeEqualOption getValues
|
||||
getFiles optionAttrSetToDocList optionAttrSetToDocList'
|
||||
scrubOptionValue literalExample showOption showFiles
|
||||
unknownModule mkOption;
|
||||
inherit (types) isType setType defaultTypeMerge defaultFunctor
|
||||
isOptionType mkOptionType;
|
||||
inherit (asserts)
|
||||
assertMsg assertOneOf;
|
||||
inherit (debug) addErrorContextToAttrs traceIf traceVal traceValFn
|
||||
traceXMLVal traceXMLValMarked traceSeq traceSeqN traceValSeq
|
||||
traceValSeqFn traceValSeqN traceValSeqNFn traceShowVal
|
||||
traceShowValMarked showVal traceCall traceCall2 traceCall3
|
||||
traceValIfNot runTests testAllTrue traceCallXml attrNamesToStr;
|
||||
inherit (misc) maybeEnv defaultMergeArg defaultMerge foldArgs
|
||||
maybeAttrNullable maybeAttr ifEnable checkFlag getValue
|
||||
checkReqs uniqList uniqListExt condConcat lazyGenericClosure
|
||||
innerModifySumArgs modifySumArgs innerClosePropagation
|
||||
closePropagation mapAttrsFlatten nvs setAttr setAttrMerge
|
||||
mergeAttrsWithFunc mergeAttrsConcatenateValues
|
||||
mergeAttrsNoOverride mergeAttrByFunc mergeAttrsByFuncDefaults
|
||||
mergeAttrsByFuncDefaultsClean mergeAttrBy
|
||||
fakeSha256 fakeSha512
|
||||
nixType imap;
|
||||
});
|
||||
in lib
|
||||
@@ -1,277 +0,0 @@
|
||||
{ lib }:
|
||||
let
|
||||
inherit (builtins) head tail isList isAttrs isInt attrNames;
|
||||
|
||||
in
|
||||
|
||||
with lib.lists;
|
||||
with lib.attrsets;
|
||||
with lib.strings;
|
||||
|
||||
rec {
|
||||
|
||||
# returns default if env var is not set
|
||||
maybeEnv = name: default:
|
||||
let value = builtins.getEnv name; in
|
||||
if value == "" then default else value;
|
||||
|
||||
defaultMergeArg = x : y: if builtins.isAttrs y then
|
||||
y
|
||||
else
|
||||
(y x);
|
||||
defaultMerge = x: y: x // (defaultMergeArg x y);
|
||||
foldArgs = merger: f: init: x:
|
||||
let arg = (merger init (defaultMergeArg init x));
|
||||
# now add the function with composed args already applied to the final attrs
|
||||
base = (setAttrMerge "passthru" {} (f arg)
|
||||
( z: z // rec {
|
||||
function = foldArgs merger f arg;
|
||||
args = (lib.attrByPath ["passthru" "args"] {} z) // x;
|
||||
} ));
|
||||
withStdOverrides = base // {
|
||||
override = base.passthru.function;
|
||||
};
|
||||
in
|
||||
withStdOverrides;
|
||||
|
||||
|
||||
# shortcut for attrByPath ["name"] default attrs
|
||||
maybeAttrNullable = maybeAttr;
|
||||
|
||||
# shortcut for attrByPath ["name"] default attrs
|
||||
maybeAttr = name: default: attrs: attrs.${name} or default;
|
||||
|
||||
|
||||
# Return the second argument if the first one is true or the empty version
|
||||
# of the second argument.
|
||||
ifEnable = cond: val:
|
||||
if cond then val
|
||||
else if builtins.isList val then []
|
||||
else if builtins.isAttrs val then {}
|
||||
# else if builtins.isString val then ""
|
||||
else if val == true || val == false then false
|
||||
else null;
|
||||
|
||||
|
||||
# Return true only if there is an attribute and it is true.
|
||||
checkFlag = attrSet: name:
|
||||
if name == "true" then true else
|
||||
if name == "false" then false else
|
||||
if (elem name (attrByPath ["flags"] [] attrSet)) then true else
|
||||
attrByPath [name] false attrSet ;
|
||||
|
||||
|
||||
# Input : attrSet, [ [name default] ... ], name
|
||||
# Output : its value or default.
|
||||
getValue = attrSet: argList: name:
|
||||
( attrByPath [name] (if checkFlag attrSet name then true else
|
||||
if argList == [] then null else
|
||||
let x = builtins.head argList; in
|
||||
if (head x) == name then
|
||||
(head (tail x))
|
||||
else (getValue attrSet
|
||||
(tail argList) name)) attrSet );
|
||||
|
||||
|
||||
# Input : attrSet, [[name default] ...], [ [flagname reqs..] ... ]
|
||||
# Output : are reqs satisfied? It's asserted.
|
||||
checkReqs = attrSet: argList: condList:
|
||||
(
|
||||
fold lib.and true
|
||||
(map (x: let name = (head x); in
|
||||
|
||||
((checkFlag attrSet name) ->
|
||||
(fold lib.and true
|
||||
(map (y: let val=(getValue attrSet argList y); in
|
||||
(val!=null) && (val!=false))
|
||||
(tail x))))) condList));
|
||||
|
||||
|
||||
# This function has O(n^2) performance.
|
||||
uniqList = { inputList, acc ? [] }:
|
||||
let go = xs: acc:
|
||||
if xs == []
|
||||
then []
|
||||
else let x = head xs;
|
||||
y = if elem x acc then [] else [x];
|
||||
in y ++ go (tail xs) (y ++ acc);
|
||||
in go inputList acc;
|
||||
|
||||
uniqListExt = { inputList,
|
||||
outputList ? [],
|
||||
getter ? (x: x),
|
||||
compare ? (x: y: x==y) }:
|
||||
if inputList == [] then outputList else
|
||||
let x = head inputList;
|
||||
isX = y: (compare (getter y) (getter x));
|
||||
newOutputList = outputList ++
|
||||
(if any isX outputList then [] else [x]);
|
||||
in uniqListExt { outputList = newOutputList;
|
||||
inputList = (tail inputList);
|
||||
inherit getter compare;
|
||||
};
|
||||
|
||||
condConcat = name: list: checker:
|
||||
if list == [] then name else
|
||||
if checker (head list) then
|
||||
condConcat
|
||||
(name + (head (tail list)))
|
||||
(tail (tail list))
|
||||
checker
|
||||
else condConcat
|
||||
name (tail (tail list)) checker;
|
||||
|
||||
lazyGenericClosure = {startSet, operator}:
|
||||
let
|
||||
work = list: doneKeys: result:
|
||||
if list == [] then
|
||||
result
|
||||
else
|
||||
let x = head list; key = x.key; in
|
||||
if elem key doneKeys then
|
||||
work (tail list) doneKeys result
|
||||
else
|
||||
work (tail list ++ operator x) ([key] ++ doneKeys) ([x] ++ result);
|
||||
in
|
||||
work startSet [] [];
|
||||
|
||||
innerModifySumArgs = f: x: a: b: if b == null then (f a b) // x else
|
||||
innerModifySumArgs f x (a // b);
|
||||
modifySumArgs = f: x: innerModifySumArgs f x {};
|
||||
|
||||
|
||||
innerClosePropagation = acc: xs:
|
||||
if xs == []
|
||||
then acc
|
||||
else let y = head xs;
|
||||
ys = tail xs;
|
||||
in if ! isAttrs y
|
||||
then innerClosePropagation acc ys
|
||||
else let acc' = [y] ++ acc;
|
||||
in innerClosePropagation
|
||||
acc'
|
||||
(uniqList { inputList = (maybeAttrNullable "propagatedBuildInputs" [] y)
|
||||
++ (maybeAttrNullable "propagatedNativeBuildInputs" [] y)
|
||||
++ ys;
|
||||
acc = acc';
|
||||
}
|
||||
);
|
||||
|
||||
closePropagation = list: (uniqList {inputList = (innerClosePropagation [] list);});
|
||||
|
||||
# calls a function (f attr value ) for each record item. returns a list
|
||||
mapAttrsFlatten = f: r: map (attr: f attr r.${attr}) (attrNames r);
|
||||
|
||||
# attribute set containing one attribute
|
||||
nvs = name: value: listToAttrs [ (nameValuePair name value) ];
|
||||
# adds / replaces an attribute of an attribute set
|
||||
setAttr = set: name: v: set // (nvs name v);
|
||||
|
||||
# setAttrMerge (similar to mergeAttrsWithFunc but only merges the values of a particular name)
|
||||
# setAttrMerge "a" [] { a = [2];} (x: x ++ [3]) -> { a = [2 3]; }
|
||||
# setAttrMerge "a" [] { } (x: x ++ [3]) -> { a = [ 3]; }
|
||||
setAttrMerge = name: default: attrs: f:
|
||||
setAttr attrs name (f (maybeAttr name default attrs));
|
||||
|
||||
# Using f = a: b = b the result is similar to //
|
||||
# merge attributes with custom function handling the case that the attribute
|
||||
# exists in both sets
|
||||
mergeAttrsWithFunc = f: set1: set2:
|
||||
fold (n: set: if set ? ${n}
|
||||
then setAttr set n (f set.${n} set2.${n})
|
||||
else set )
|
||||
(set2 // set1) (attrNames set2);
|
||||
|
||||
# merging two attribute set concatenating the values of same attribute names
|
||||
# eg { a = 7; } { a = [ 2 3 ]; } becomes { a = [ 7 2 3 ]; }
|
||||
mergeAttrsConcatenateValues = mergeAttrsWithFunc ( a: b: (toList a) ++ (toList b) );
|
||||
|
||||
# merges attributes using //, if a name exists in both attributes
|
||||
# an error will be triggered unless its listed in mergeLists
|
||||
# so you can mergeAttrsNoOverride { buildInputs = [a]; } { buildInputs = [a]; } {} to get
|
||||
# { buildInputs = [a b]; }
|
||||
# merging buildPhase doesn't really make sense. The cases will be rare where appending /prefixing will fit your needs?
|
||||
# in these cases the first buildPhase will override the second one
|
||||
# ! deprecated, use mergeAttrByFunc instead
|
||||
mergeAttrsNoOverride = { mergeLists ? ["buildInputs" "propagatedBuildInputs"],
|
||||
overrideSnd ? [ "buildPhase" ]
|
||||
}: attrs1: attrs2:
|
||||
fold (n: set:
|
||||
setAttr set n ( if set ? ${n}
|
||||
then # merge
|
||||
if elem n mergeLists # attribute contains list, merge them by concatenating
|
||||
then attrs2.${n} ++ attrs1.${n}
|
||||
else if elem n overrideSnd
|
||||
then attrs1.${n}
|
||||
else throw "error mergeAttrsNoOverride, attribute ${n} given in both attributes - no merge func defined"
|
||||
else attrs2.${n} # add attribute not existing in attr1
|
||||
)) attrs1 (attrNames attrs2);
|
||||
|
||||
|
||||
# example usage:
|
||||
# mergeAttrByFunc {
|
||||
# inherit mergeAttrBy; # defined below
|
||||
# buildInputs = [ a b ];
|
||||
# } {
|
||||
# buildInputs = [ c d ];
|
||||
# };
|
||||
# will result in
|
||||
# { mergeAttrsBy = [...]; buildInputs = [ a b c d ]; }
|
||||
# is used by defaultOverridableDelayableArgs and can be used when composing using
|
||||
# foldArgs, composedArgsAndFun or applyAndFun. Example: composableDerivation in all-packages.nix
|
||||
mergeAttrByFunc = x: y:
|
||||
let
|
||||
mergeAttrBy2 = { mergeAttrBy = lib.mergeAttrs; }
|
||||
// (maybeAttr "mergeAttrBy" {} x)
|
||||
// (maybeAttr "mergeAttrBy" {} y); in
|
||||
fold lib.mergeAttrs {} [
|
||||
x y
|
||||
(mapAttrs ( a: v: # merge special names using given functions
|
||||
if x ? ${a}
|
||||
then if y ? ${a}
|
||||
then v x.${a} y.${a} # both have attr, use merge func
|
||||
else x.${a} # only x has attr
|
||||
else y.${a} # only y has attr)
|
||||
) (removeAttrs mergeAttrBy2
|
||||
# don't merge attrs which are neither in x nor y
|
||||
(filter (a: ! x ? ${a} && ! y ? ${a})
|
||||
(attrNames mergeAttrBy2))
|
||||
)
|
||||
)
|
||||
];
|
||||
mergeAttrsByFuncDefaults = foldl mergeAttrByFunc { inherit mergeAttrBy; };
|
||||
mergeAttrsByFuncDefaultsClean = list: removeAttrs (mergeAttrsByFuncDefaults list) ["mergeAttrBy"];
|
||||
|
||||
# sane defaults (same name as attr name so that inherit can be used)
|
||||
mergeAttrBy = # { buildInputs = concatList; [...]; passthru = mergeAttr; [..]; }
|
||||
listToAttrs (map (n: nameValuePair n lib.concat)
|
||||
[ "nativeBuildInputs" "buildInputs" "propagatedBuildInputs" "configureFlags" "prePhases" "postAll" "patches" ])
|
||||
// listToAttrs (map (n: nameValuePair n lib.mergeAttrs) [ "passthru" "meta" "cfg" "flags" ])
|
||||
// listToAttrs (map (n: nameValuePair n (a: b: "${a}\n${b}") ) [ "preConfigure" "postInstall" ])
|
||||
;
|
||||
|
||||
nixType = x:
|
||||
if isAttrs x then
|
||||
if x ? outPath then "derivation"
|
||||
else "attrs"
|
||||
else if lib.isFunction x then "function"
|
||||
else if isList x then "list"
|
||||
else if x == true then "bool"
|
||||
else if x == false then "bool"
|
||||
else if x == null then "null"
|
||||
else if isInt x then "int"
|
||||
else "string";
|
||||
|
||||
/* deprecated:
|
||||
|
||||
For historical reasons, imap has an index starting at 1.
|
||||
|
||||
But for consistency with the rest of the library we want an index
|
||||
starting at zero.
|
||||
*/
|
||||
imap = imap1;
|
||||
|
||||
# Fake hashes. Can be used as hash placeholders, when computing hash ahead isn't trivial
|
||||
fakeSha256 = "0000000000000000000000000000000000000000000000000000000000000000";
|
||||
fakeSha512 = "00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000";
|
||||
}
|
||||
@@ -1,13 +0,0 @@
|
||||
# snippets that can be shared by multiple fetchers (pkgs/build-support)
|
||||
{ lib }:
|
||||
{
|
||||
|
||||
proxyImpureEnvVars = [
|
||||
# We borrow these environment variables from the caller to allow
|
||||
# easy proxy configuration. This is impure, but a fixed-output
|
||||
# derivation like fetchurl is allowed to do so since its result is
|
||||
# by definition pure.
|
||||
"http_proxy" "https_proxy" "ftp_proxy" "all_proxy" "no_proxy"
|
||||
];
|
||||
|
||||
}
|
||||
@@ -1,45 +0,0 @@
|
||||
{ lib }:
|
||||
{ # haskellPathsInDir : Path -> Map String Path
|
||||
# A map of all haskell packages defined in the given path,
|
||||
# identified by having a cabal file with the same name as the
|
||||
# directory itself.
|
||||
haskellPathsInDir = root:
|
||||
let # Files in the root
|
||||
root-files = builtins.attrNames (builtins.readDir root);
|
||||
# Files with their full paths
|
||||
root-files-with-paths =
|
||||
map (file:
|
||||
{ name = file; value = root + "/${file}"; }
|
||||
) root-files;
|
||||
# Subdirectories of the root with a cabal file.
|
||||
cabal-subdirs =
|
||||
builtins.filter ({ name, value }:
|
||||
builtins.pathExists (value + "/${name}.cabal")
|
||||
) root-files-with-paths;
|
||||
in builtins.listToAttrs cabal-subdirs;
|
||||
# locateDominatingFile : RegExp
|
||||
# -> Path
|
||||
# -> Nullable { path : Path;
|
||||
# matches : [ MatchResults ];
|
||||
# }
|
||||
# Find the first directory containing a file matching 'pattern'
|
||||
# upward from a given 'file'.
|
||||
# Returns 'null' if no directories contain a file matching 'pattern'.
|
||||
locateDominatingFile = pattern: file:
|
||||
let go = path:
|
||||
let files = builtins.attrNames (builtins.readDir path);
|
||||
matches = builtins.filter (match: match != null)
|
||||
(map (builtins.match pattern) files);
|
||||
in
|
||||
if builtins.length matches != 0
|
||||
then { inherit path matches; }
|
||||
else if path == /.
|
||||
then null
|
||||
else go (dirOf path);
|
||||
parent = dirOf file;
|
||||
isDir =
|
||||
let base = baseNameOf file;
|
||||
type = (builtins.readDir parent).${base} or null;
|
||||
in file == /. || type == "directory";
|
||||
in go (if isDir then file else parent);
|
||||
}
|
||||
@@ -1,101 +0,0 @@
|
||||
{ ... }:
|
||||
rec {
|
||||
# Compute the fixed point of the given function `f`, which is usually an
|
||||
# attribute set that expects its final, non-recursive representation as an
|
||||
# argument:
|
||||
#
|
||||
# f = self: { foo = "foo"; bar = "bar"; foobar = self.foo + self.bar; }
|
||||
#
|
||||
# Nix evaluates this recursion until all references to `self` have been
|
||||
# resolved. At that point, the final result is returned and `f x = x` holds:
|
||||
#
|
||||
# nix-repl> fix f
|
||||
# { bar = "bar"; foo = "foo"; foobar = "foobar"; }
|
||||
#
|
||||
# Type: fix :: (a -> a) -> a
|
||||
#
|
||||
# See https://en.wikipedia.org/wiki/Fixed-point_combinator for further
|
||||
# details.
|
||||
fix = f: let x = f x; in x;
|
||||
|
||||
# A variant of `fix` that records the original recursive attribute set in the
|
||||
# result. This is useful in combination with the `extends` function to
|
||||
# implement deep overriding. See pkgs/development/haskell-modules/default.nix
|
||||
# for a concrete example.
|
||||
fix' = f: let x = f x // { __unfix__ = f; }; in x;
|
||||
|
||||
# Return the fixpoint that `f` converges to when called recursively, starting
|
||||
# with the input `x`.
|
||||
#
|
||||
# nix-repl> converge (x: x / 2) 16
|
||||
# 0
|
||||
converge = f: x:
|
||||
if (f x) == x
|
||||
then x
|
||||
else converge f (f x);
|
||||
|
||||
# Modify the contents of an explicitly recursive attribute set in a way that
|
||||
# honors `self`-references. This is accomplished with a function
|
||||
#
|
||||
# g = self: super: { foo = super.foo + " + "; }
|
||||
#
|
||||
# that has access to the unmodified input (`super`) as well as the final
|
||||
# non-recursive representation of the attribute set (`self`). `extends`
|
||||
# differs from the native `//` operator insofar as that it's applied *before*
|
||||
# references to `self` are resolved:
|
||||
#
|
||||
# nix-repl> fix (extends g f)
|
||||
# { bar = "bar"; foo = "foo + "; foobar = "foo + bar"; }
|
||||
#
|
||||
# The name of the function is inspired by object-oriented inheritance, i.e.
|
||||
# think of it as an infix operator `g extends f` that mimics the syntax from
|
||||
# Java. It may seem counter-intuitive to have the "base class" as the second
|
||||
# argument, but it's nice this way if several uses of `extends` are cascaded.
|
||||
#
|
||||
# To get a better understanding how `extends` turns a function with a fix
|
||||
# point (the package set we start with) into a new function with a different fix
|
||||
# point (the desired packages set) lets just see, how `extends g f`
|
||||
# unfolds with `g` and `f` defined above:
|
||||
#
|
||||
# extends g f = self: let super = f self; in super // g self super;
|
||||
# = self: let super = { foo = "foo"; bar = "bar"; foobar = self.foo + self.bar; }; in super // g self super
|
||||
# = self: { foo = "foo"; bar = "bar"; foobar = self.foo + self.bar; } // g self { foo = "foo"; bar = "bar"; foobar = self.foo + self.bar; }
|
||||
# = self: { foo = "foo"; bar = "bar"; foobar = self.foo + self.bar; } // { foo = "foo" + " + "; }
|
||||
# = self: { foo = "foo + "; bar = "bar"; foobar = self.foo + self.bar; }
|
||||
#
|
||||
extends = f: rattrs: self: let super = rattrs self; in super // f self super;
|
||||
|
||||
# Compose two extending functions of the type expected by 'extends'
|
||||
# into one where changes made in the first are available in the
|
||||
# 'super' of the second
|
||||
composeExtensions =
|
||||
f: g: self: super:
|
||||
let fApplied = f self super;
|
||||
super' = super // fApplied;
|
||||
in fApplied // g self super';
|
||||
|
||||
# Create an overridable, recursive attribute set. For example:
|
||||
#
|
||||
# nix-repl> obj = makeExtensible (self: { })
|
||||
#
|
||||
# nix-repl> obj
|
||||
# { __unfix__ = «lambda»; extend = «lambda»; }
|
||||
#
|
||||
# nix-repl> obj = obj.extend (self: super: { foo = "foo"; })
|
||||
#
|
||||
# nix-repl> obj
|
||||
# { __unfix__ = «lambda»; extend = «lambda»; foo = "foo"; }
|
||||
#
|
||||
# nix-repl> obj = obj.extend (self: super: { foo = super.foo + " + "; bar = "bar"; foobar = self.foo + self.bar; })
|
||||
#
|
||||
# nix-repl> obj
|
||||
# { __unfix__ = «lambda»; bar = "bar"; extend = «lambda»; foo = "foo + "; foobar = "foo + bar"; }
|
||||
makeExtensible = makeExtensibleWithCustomName "extend";
|
||||
|
||||
# Same as `makeExtensible` but the name of the extending attribute is
|
||||
# customized.
|
||||
makeExtensibleWithCustomName = extenderName: rattrs:
|
||||
fix' rattrs // {
|
||||
${extenderName} = f: makeExtensibleWithCustomName extenderName (extends f rattrs);
|
||||
};
|
||||
}
|
||||
@@ -1,227 +0,0 @@
|
||||
/* Functions that generate widespread file
|
||||
* formats from nix data structures.
|
||||
*
|
||||
* They all follow a similar interface:
|
||||
* generator { config-attrs } data
|
||||
*
|
||||
* `config-attrs` are “holes” in the generators
|
||||
* with sensible default implementations that
|
||||
* can be overwritten. The default implementations
|
||||
* are mostly generators themselves, called with
|
||||
* their respective default values; they can be reused.
|
||||
*
|
||||
* Tests can be found in ./tests.nix
|
||||
* Documentation in the manual, #sec-generators
|
||||
*/
|
||||
{ lib }:
|
||||
with (lib).trivial;
|
||||
let
|
||||
libStr = lib.strings;
|
||||
libAttr = lib.attrsets;
|
||||
|
||||
inherit (lib) isFunction;
|
||||
in
|
||||
|
||||
rec {
|
||||
|
||||
## -- HELPER FUNCTIONS & DEFAULTS --
|
||||
|
||||
/* Convert a value to a sensible default string representation.
|
||||
* The builtin `toString` function has some strange defaults,
|
||||
* suitable for bash scripts but not much else.
|
||||
*/
|
||||
mkValueStringDefault = {}: v: with builtins;
|
||||
let err = t: v: abort
|
||||
("generators.mkValueStringDefault: " +
|
||||
"${t} not supported: ${toPretty {} v}");
|
||||
in if isInt v then toString v
|
||||
# we default to not quoting strings
|
||||
else if isString v then v
|
||||
# isString returns "1", which is not a good default
|
||||
else if true == v then "true"
|
||||
# here it returns to "", which is even less of a good default
|
||||
else if false == v then "false"
|
||||
else if null == v then "null"
|
||||
# if you have lists you probably want to replace this
|
||||
else if isList v then err "lists" v
|
||||
# same as for lists, might want to replace
|
||||
else if isAttrs v then err "attrsets" v
|
||||
else if isFunction v then err "functions" v
|
||||
else err "this value is" (toString v);
|
||||
|
||||
|
||||
/* Generate a line of key k and value v, separated by
|
||||
* character sep. If sep appears in k, it is escaped.
|
||||
* Helper for synaxes with different separators.
|
||||
*
|
||||
* mkValueString specifies how values should be formatted.
|
||||
*
|
||||
* mkKeyValueDefault {} ":" "f:oo" "bar"
|
||||
* > "f\:oo:bar"
|
||||
*/
|
||||
mkKeyValueDefault = {
|
||||
mkValueString ? mkValueStringDefault {}
|
||||
}: sep: k: v:
|
||||
"${libStr.escape [sep] k}${sep}${mkValueString v}";
|
||||
|
||||
|
||||
## -- FILE FORMAT GENERATORS --
|
||||
|
||||
|
||||
/* Generate a key-value-style config file from an attrset.
|
||||
*
|
||||
* mkKeyValue is the same as in toINI.
|
||||
*/
|
||||
toKeyValue = {
|
||||
mkKeyValue ? mkKeyValueDefault {} "="
|
||||
}: attrs:
|
||||
let mkLine = k: v: mkKeyValue k v + "\n";
|
||||
in libStr.concatStrings (libAttr.mapAttrsToList mkLine attrs);
|
||||
|
||||
|
||||
/* Generate an INI-style config file from an
|
||||
* attrset of sections to an attrset of key-value pairs.
|
||||
*
|
||||
* generators.toINI {} {
|
||||
* foo = { hi = "${pkgs.hello}"; ciao = "bar"; };
|
||||
* baz = { "also, integers" = 42; };
|
||||
* }
|
||||
*
|
||||
*> [baz]
|
||||
*> also, integers=42
|
||||
*>
|
||||
*> [foo]
|
||||
*> ciao=bar
|
||||
*> hi=/nix/store/y93qql1p5ggfnaqjjqhxcw0vqw95rlz0-hello-2.10
|
||||
*
|
||||
* The mk* configuration attributes can generically change
|
||||
* the way sections and key-value strings are generated.
|
||||
*
|
||||
* For more examples see the test cases in ./tests.nix.
|
||||
*/
|
||||
toINI = {
|
||||
# apply transformations (e.g. escapes) to section names
|
||||
mkSectionName ? (name: libStr.escape [ "[" "]" ] name),
|
||||
# format a setting line from key and value
|
||||
mkKeyValue ? mkKeyValueDefault {} "="
|
||||
}: attrsOfAttrs:
|
||||
let
|
||||
# map function to string for each key val
|
||||
mapAttrsToStringsSep = sep: mapFn: attrs:
|
||||
libStr.concatStringsSep sep
|
||||
(libAttr.mapAttrsToList mapFn attrs);
|
||||
mkSection = sectName: sectValues: ''
|
||||
[${mkSectionName sectName}]
|
||||
'' + toKeyValue { inherit mkKeyValue; } sectValues;
|
||||
in
|
||||
# map input to ini sections
|
||||
mapAttrsToStringsSep "\n" mkSection attrsOfAttrs;
|
||||
|
||||
|
||||
/* Generates JSON from an arbitrary (non-function) value.
|
||||
* For more information see the documentation of the builtin.
|
||||
*/
|
||||
toJSON = {}: builtins.toJSON;
|
||||
|
||||
|
||||
/* YAML has been a strict superset of JSON since 1.2, so we
|
||||
* use toJSON. Before it only had a few differences referring
|
||||
* to implicit typing rules, so it should work with older
|
||||
* parsers as well.
|
||||
*/
|
||||
toYAML = {}@args: toJSON args;
|
||||
|
||||
|
||||
/* Pretty print a value, akin to `builtins.trace`.
|
||||
* Should probably be a builtin as well.
|
||||
*/
|
||||
toPretty = {
|
||||
/* If this option is true, attrsets like { __pretty = fn; val = …; }
|
||||
will use fn to convert val to a pretty printed representation.
|
||||
(This means fn is type Val -> String.) */
|
||||
allowPrettyValues ? false
|
||||
}@args: v: with builtins;
|
||||
let isPath = v: typeOf v == "path";
|
||||
in if isInt v then toString v
|
||||
else if isFloat v then "~${toString v}"
|
||||
else if isString v then ''"${libStr.escape [''"''] v}"''
|
||||
else if true == v then "true"
|
||||
else if false == v then "false"
|
||||
else if null == v then "null"
|
||||
else if isPath v then toString v
|
||||
else if isList v then "[ "
|
||||
+ libStr.concatMapStringsSep " " (toPretty args) v
|
||||
+ " ]"
|
||||
else if isAttrs v then
|
||||
# apply pretty values if allowed
|
||||
if attrNames v == [ "__pretty" "val" ] && allowPrettyValues
|
||||
then v.__pretty v.val
|
||||
# TODO: there is probably a better representation?
|
||||
else if v ? type && v.type == "derivation" then
|
||||
"<δ:${v.name}>"
|
||||
# "<δ:${concatStringsSep "," (builtins.attrNames v)}>"
|
||||
else "{ "
|
||||
+ libStr.concatStringsSep " " (libAttr.mapAttrsToList
|
||||
(name: value:
|
||||
"${toPretty args name} = ${toPretty args value};") v)
|
||||
+ " }"
|
||||
else if isFunction v then
|
||||
let fna = lib.functionArgs v;
|
||||
showFnas = concatStringsSep "," (libAttr.mapAttrsToList
|
||||
(name: hasDefVal: if hasDefVal then "(${name})" else name)
|
||||
fna);
|
||||
in if fna == {} then "<λ>"
|
||||
else "<λ:{${showFnas}}>"
|
||||
else abort "generators.toPretty: should never happen (v = ${v})";
|
||||
|
||||
# PLIST handling
|
||||
toPlist = {}: v: let
|
||||
isFloat = builtins.isFloat or (x: false);
|
||||
expr = ind: x: with builtins;
|
||||
if isNull x then "" else
|
||||
if isBool x then bool ind x else
|
||||
if isInt x then int ind x else
|
||||
if isString x then str ind x else
|
||||
if isList x then list ind x else
|
||||
if isAttrs x then attrs ind x else
|
||||
if isFloat x then float ind x else
|
||||
abort "generators.toPlist: should never happen (v = ${v})";
|
||||
|
||||
literal = ind: x: ind + x;
|
||||
|
||||
bool = ind: x: literal ind (if x then "<true/>" else "<false/>");
|
||||
int = ind: x: literal ind "<integer>${toString x}</integer>";
|
||||
str = ind: x: literal ind "<string>${x}</string>";
|
||||
key = ind: x: literal ind "<key>${x}</key>";
|
||||
float = ind: x: literal ind "<real>${toString x}</real>";
|
||||
|
||||
indent = ind: expr "\t${ind}";
|
||||
|
||||
item = ind: libStr.concatMapStringsSep "\n" (indent ind);
|
||||
|
||||
list = ind: x: libStr.concatStringsSep "\n" [
|
||||
(literal ind "<array>")
|
||||
(item ind x)
|
||||
(literal ind "</array>")
|
||||
];
|
||||
|
||||
attrs = ind: x: libStr.concatStringsSep "\n" [
|
||||
(literal ind "<dict>")
|
||||
(attr ind x)
|
||||
(literal ind "</dict>")
|
||||
];
|
||||
|
||||
attr = let attrFilter = name: value: name != "_module" && value != null;
|
||||
in ind: x: libStr.concatStringsSep "\n" (lib.flatten (lib.mapAttrsToList
|
||||
(name: value: lib.optional (attrFilter name value) [
|
||||
(key "\t${ind}" name)
|
||||
(expr "\t${ind}" value)
|
||||
]) x));
|
||||
|
||||
in ''<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
|
||||
<plist version="1.0">
|
||||
${expr "" v}
|
||||
</plist>'';
|
||||
|
||||
}
|
||||
@@ -1,21 +0,0 @@
|
||||
{ lib, version }:
|
||||
|
||||
with lib;
|
||||
rec {
|
||||
# Common patterns/legacy
|
||||
whenAtLeast = ver: mkIf (versionAtLeast version ver);
|
||||
whenOlder = ver: mkIf (versionOlder version ver);
|
||||
# range is (inclusive, exclusive)
|
||||
whenBetween = verLow: verHigh: mkIf (versionAtLeast version verLow && versionOlder version verHigh);
|
||||
|
||||
|
||||
# Keeping these around in case we decide to change this horrible implementation :)
|
||||
option = x:
|
||||
x // { optional = true; };
|
||||
|
||||
yes = { tristate = "y"; };
|
||||
no = { tristate = "n"; };
|
||||
module = { tristate = "m"; };
|
||||
freeform = x: { freeform = x; };
|
||||
|
||||
}
|
||||
742
lib/licenses.nix
742
lib/licenses.nix
@@ -1,742 +0,0 @@
|
||||
{ lib }:
|
||||
let
|
||||
|
||||
spdx = lic: lic // {
|
||||
url = "http://spdx.org/licenses/${lic.spdxId}.html";
|
||||
};
|
||||
|
||||
in
|
||||
|
||||
lib.mapAttrs (n: v: v // { shortName = n; }) rec {
|
||||
/* License identifiers from spdx.org where possible.
|
||||
* If you cannot find your license here, then look for a similar license or
|
||||
* add it to this list. The URL mentioned above is a good source for inspiration.
|
||||
*/
|
||||
|
||||
abstyles = spdx {
|
||||
spdxId = "Abstyles";
|
||||
fullName = "Abstyles License";
|
||||
};
|
||||
|
||||
afl21 = spdx {
|
||||
spdxId = "AFL-2.1";
|
||||
fullName = "Academic Free License v2.1";
|
||||
};
|
||||
|
||||
afl3 = spdx {
|
||||
spdxId = "AFL-3.0";
|
||||
fullName = "Academic Free License v3.0";
|
||||
};
|
||||
|
||||
agpl3 = spdx {
|
||||
spdxId = "AGPL-3.0-only";
|
||||
fullName = "GNU Affero General Public License v3.0 only";
|
||||
};
|
||||
|
||||
agpl3Plus = spdx {
|
||||
spdxId = "AGPL-3.0-or-later";
|
||||
fullName = "GNU Affero General Public License v3.0 or later";
|
||||
};
|
||||
|
||||
amazonsl = {
|
||||
fullName = "Amazon Software License";
|
||||
url = http://aws.amazon.com/asl/;
|
||||
free = false;
|
||||
};
|
||||
|
||||
amd = {
|
||||
fullName = "AMD License Agreement";
|
||||
url = http://developer.amd.com/amd-license-agreement/;
|
||||
free = false;
|
||||
};
|
||||
|
||||
apsl20 = spdx {
|
||||
spdxId = "APSL-2.0";
|
||||
fullName = "Apple Public Source License 2.0";
|
||||
};
|
||||
|
||||
arphicpl = {
|
||||
fullName = "Arphic Public License";
|
||||
url = https://www.freedesktop.org/wiki/Arphic_Public_License/;
|
||||
};
|
||||
|
||||
artistic1 = spdx {
|
||||
spdxId = "Artistic-1.0";
|
||||
fullName = "Artistic License 1.0";
|
||||
};
|
||||
|
||||
artistic2 = spdx {
|
||||
spdxId = "Artistic-2.0";
|
||||
fullName = "Artistic License 2.0";
|
||||
};
|
||||
|
||||
asl20 = spdx {
|
||||
spdxId = "Apache-2.0";
|
||||
fullName = "Apache License 2.0";
|
||||
};
|
||||
|
||||
boost = spdx {
|
||||
spdxId = "BSL-1.0";
|
||||
fullName = "Boost Software License 1.0";
|
||||
};
|
||||
|
||||
beerware = spdx {
|
||||
spdxId = "Beerware";
|
||||
fullName = ''Beerware License'';
|
||||
};
|
||||
|
||||
bsd0 = spdx {
|
||||
spdxId = "0BSD";
|
||||
fullName = "BSD Zero Clause License";
|
||||
};
|
||||
|
||||
bsd2 = spdx {
|
||||
spdxId = "BSD-2-Clause";
|
||||
fullName = ''BSD 2-clause "Simplified" License'';
|
||||
};
|
||||
|
||||
bsd3 = spdx {
|
||||
spdxId = "BSD-3-Clause";
|
||||
fullName = ''BSD 3-clause "New" or "Revised" License'';
|
||||
};
|
||||
|
||||
bsdOriginal = spdx {
|
||||
spdxId = "BSD-4-Clause";
|
||||
fullName = ''BSD 4-clause "Original" or "Old" License'';
|
||||
};
|
||||
|
||||
bsl11 = {
|
||||
fullName = "Business Source License 1.1";
|
||||
url = https://mariadb.com/bsl11;
|
||||
free = false;
|
||||
};
|
||||
|
||||
clArtistic = spdx {
|
||||
spdxId = "ClArtistic";
|
||||
fullName = "Clarified Artistic License";
|
||||
};
|
||||
|
||||
cc0 = spdx {
|
||||
spdxId = "CC0-1.0";
|
||||
fullName = "Creative Commons Zero v1.0 Universal";
|
||||
};
|
||||
|
||||
cc-by-nc-sa-20 = spdx {
|
||||
spdxId = "CC-BY-NC-SA-2.0";
|
||||
fullName = "Creative Commons Attribution Non Commercial Share Alike 2.0";
|
||||
free = false;
|
||||
};
|
||||
|
||||
cc-by-nc-sa-25 = spdx {
|
||||
spdxId = "CC-BY-NC-SA-2.5";
|
||||
fullName = "Creative Commons Attribution Non Commercial Share Alike 2.5";
|
||||
free = false;
|
||||
};
|
||||
|
||||
cc-by-nc-sa-30 = spdx {
|
||||
spdxId = "CC-BY-NC-SA-3.0";
|
||||
fullName = "Creative Commons Attribution Non Commercial Share Alike 3.0";
|
||||
free = false;
|
||||
};
|
||||
|
||||
cc-by-nc-sa-40 = spdx {
|
||||
spdxId = "CC-BY-NC-SA-4.0";
|
||||
fullName = "Creative Commons Attribution Non Commercial Share Alike 4.0";
|
||||
free = false;
|
||||
};
|
||||
|
||||
cc-by-nc-40 = spdx {
|
||||
spdxId = "CC-BY-NC-4.0";
|
||||
fullName = "Creative Commons Attribution Non Commercial 4.0 International";
|
||||
free = false;
|
||||
};
|
||||
|
||||
cc-by-nd-30 = spdx {
|
||||
spdxId = "CC-BY-ND-3.0";
|
||||
fullName = "Creative Commons Attribution-No Derivative Works v3.00";
|
||||
free = false;
|
||||
};
|
||||
|
||||
cc-by-sa-25 = spdx {
|
||||
spdxId = "CC-BY-SA-2.5";
|
||||
fullName = "Creative Commons Attribution Share Alike 2.5";
|
||||
};
|
||||
|
||||
cc-by-30 = spdx {
|
||||
spdxId = "CC-BY-3.0";
|
||||
fullName = "Creative Commons Attribution 3.0";
|
||||
};
|
||||
|
||||
cc-by-sa-30 = spdx {
|
||||
spdxId = "CC-BY-SA-3.0";
|
||||
fullName = "Creative Commons Attribution Share Alike 3.0";
|
||||
};
|
||||
|
||||
cc-by-40 = spdx {
|
||||
spdxId = "CC-BY-4.0";
|
||||
fullName = "Creative Commons Attribution 4.0";
|
||||
};
|
||||
|
||||
cc-by-sa-40 = spdx {
|
||||
spdxId = "CC-BY-SA-4.0";
|
||||
fullName = "Creative Commons Attribution Share Alike 4.0";
|
||||
};
|
||||
|
||||
cddl = spdx {
|
||||
spdxId = "CDDL-1.0";
|
||||
fullName = "Common Development and Distribution License 1.0";
|
||||
};
|
||||
|
||||
cecill20 = spdx {
|
||||
spdxId = "CECILL-2.0";
|
||||
fullName = "CeCILL Free Software License Agreement v2.0";
|
||||
};
|
||||
|
||||
cecill-b = spdx {
|
||||
spdxId = "CECILL-B";
|
||||
fullName = "CeCILL-B Free Software License Agreement";
|
||||
};
|
||||
|
||||
cecill-c = spdx {
|
||||
spdxId = "CECILL-C";
|
||||
fullName = "CeCILL-C Free Software License Agreement";
|
||||
};
|
||||
|
||||
cpal10 = spdx {
|
||||
spdxId = "CPAL-1.0";
|
||||
fullName = "Common Public Attribution License 1.0";
|
||||
};
|
||||
|
||||
cpl10 = spdx {
|
||||
spdxId = "CPL-1.0";
|
||||
fullName = "Common Public License 1.0";
|
||||
};
|
||||
|
||||
curl = {
|
||||
fullName = "MIT/X11 derivate";
|
||||
url = "https://curl.haxx.se/docs/copyright.html";
|
||||
};
|
||||
|
||||
doc = spdx {
|
||||
spdxId = "DOC";
|
||||
fullName = "DOC License";
|
||||
};
|
||||
|
||||
eapl = {
|
||||
fullName = "EPSON AVASYS PUBLIC LICENSE";
|
||||
url = http://avasys.jp/hp/menu000000700/hpg000000603.htm;
|
||||
free = false;
|
||||
};
|
||||
|
||||
efl10 = spdx {
|
||||
spdxId = "EFL-1.0";
|
||||
fullName = "Eiffel Forum License v1.0";
|
||||
};
|
||||
|
||||
efl20 = spdx {
|
||||
spdxId = "EFL-2.0";
|
||||
fullName = "Eiffel Forum License v2.0";
|
||||
};
|
||||
|
||||
elastic = {
|
||||
fullName = "ELASTIC LICENSE";
|
||||
url = https://github.com/elastic/elasticsearch/blob/master/licenses/ELASTIC-LICENSE.txt;
|
||||
free = false;
|
||||
};
|
||||
|
||||
epl10 = spdx {
|
||||
spdxId = "EPL-1.0";
|
||||
fullName = "Eclipse Public License 1.0";
|
||||
};
|
||||
|
||||
epl20 = spdx {
|
||||
spdxId = "EPL-2.0";
|
||||
fullName = "Eclipse Public License 2.0";
|
||||
};
|
||||
|
||||
epson = {
|
||||
fullName = "Seiko Epson Corporation Software License Agreement for Linux";
|
||||
url = https://download.ebz.epson.net/dsc/du/02/eula/global/LINUX_EN.html;
|
||||
free = false;
|
||||
};
|
||||
|
||||
eupl11 = spdx {
|
||||
spdxId = "EUPL-1.1";
|
||||
fullName = "European Union Public License 1.1";
|
||||
};
|
||||
|
||||
fdl12 = spdx {
|
||||
spdxId = "GFDL-1.2-only";
|
||||
fullName = "GNU Free Documentation License v1.2 only";
|
||||
};
|
||||
|
||||
fdl12Plus = spdx {
|
||||
spdxId = "GFDL-1.2-or-later";
|
||||
fullName = "GNU Free Documentation License v1.2 or later";
|
||||
};
|
||||
|
||||
fdl13 = spdx {
|
||||
spdxId = "GFDL-1.3-only";
|
||||
fullName = "GNU Free Documentation License v1.3 only";
|
||||
};
|
||||
|
||||
fdl13Plus = spdx {
|
||||
spdxId = "GFDL-1.3-or-later";
|
||||
fullName = "GNU Free Documentation License v1.3 or later";
|
||||
};
|
||||
|
||||
ffsl = {
|
||||
fullName = "Floodgap Free Software License";
|
||||
url = http://www.floodgap.com/software/ffsl/license.html;
|
||||
free = false;
|
||||
};
|
||||
|
||||
free = {
|
||||
fullName = "Unspecified free software license";
|
||||
};
|
||||
|
||||
g4sl = {
|
||||
fullName = "Geant4 Software License";
|
||||
url = https://geant4.web.cern.ch/geant4/license/LICENSE.html;
|
||||
};
|
||||
|
||||
geogebra = {
|
||||
fullName = "GeoGebra Non-Commercial License Agreement";
|
||||
url = https://www.geogebra.org/license;
|
||||
free = false;
|
||||
};
|
||||
|
||||
gpl1 = spdx {
|
||||
spdxId = "GPL-1.0-only";
|
||||
fullName = "GNU General Public License v1.0 only";
|
||||
};
|
||||
|
||||
gpl1Plus = spdx {
|
||||
spdxId = "GPL-1.0-or-later";
|
||||
fullName = "GNU General Public License v1.0 or later";
|
||||
};
|
||||
|
||||
gpl2 = spdx {
|
||||
spdxId = "GPL-2.0-only";
|
||||
fullName = "GNU General Public License v2.0 only";
|
||||
};
|
||||
|
||||
gpl2Classpath = spdx {
|
||||
spdxId = "GPL-2.0-with-classpath-exception";
|
||||
fullName = "GNU General Public License v2.0 only (with Classpath exception)";
|
||||
};
|
||||
|
||||
gpl2ClasspathPlus = {
|
||||
fullName = "GNU General Public License v2.0 or later (with Classpath exception)";
|
||||
url = https://fedoraproject.org/wiki/Licensing/GPL_Classpath_Exception;
|
||||
};
|
||||
|
||||
gpl2Oss = {
|
||||
fullName = "GNU General Public License version 2 only (with OSI approved licenses linking exception)";
|
||||
url = https://www.mysql.com/about/legal/licensing/foss-exception;
|
||||
};
|
||||
|
||||
gpl2Plus = spdx {
|
||||
spdxId = "GPL-2.0-or-later";
|
||||
fullName = "GNU General Public License v2.0 or later";
|
||||
};
|
||||
|
||||
gpl3 = spdx {
|
||||
spdxId = "GPL-3.0-only";
|
||||
fullName = "GNU General Public License v3.0 only";
|
||||
};
|
||||
|
||||
gpl3Plus = spdx {
|
||||
spdxId = "GPL-3.0-or-later";
|
||||
fullName = "GNU General Public License v3.0 or later";
|
||||
};
|
||||
|
||||
gpl3ClasspathPlus = {
|
||||
fullName = "GNU General Public License v3.0 or later (with Classpath exception)";
|
||||
url = https://fedoraproject.org/wiki/Licensing/GPL_Classpath_Exception;
|
||||
};
|
||||
|
||||
hpnd = spdx {
|
||||
spdxId = "HPND";
|
||||
fullName = "Historic Permission Notice and Disclaimer";
|
||||
};
|
||||
|
||||
# Intel's license, seems free
|
||||
iasl = {
|
||||
fullName = "iASL";
|
||||
url = http://www.calculate-linux.org/packages/licenses/iASL;
|
||||
};
|
||||
|
||||
ijg = spdx {
|
||||
spdxId = "IJG";
|
||||
fullName = "Independent JPEG Group License";
|
||||
};
|
||||
|
||||
imagemagick = spdx {
|
||||
fullName = "ImageMagick License";
|
||||
spdxId = "imagemagick";
|
||||
};
|
||||
|
||||
inria-compcert = {
|
||||
fullName = "INRIA Non-Commercial License Agreement for the CompCert verified compiler";
|
||||
url = "http://compcert.inria.fr/doc/LICENSE";
|
||||
free = false;
|
||||
};
|
||||
|
||||
inria-icesl = {
|
||||
fullName = "INRIA Non-Commercial License Agreement for IceSL";
|
||||
url = "http://shapeforge.loria.fr/icesl/EULA_IceSL_binary.pdf";
|
||||
free = false;
|
||||
};
|
||||
|
||||
ipa = spdx {
|
||||
spdxId = "IPA";
|
||||
fullName = "IPA Font License";
|
||||
};
|
||||
|
||||
ipl10 = spdx {
|
||||
spdxId = "IPL-1.0";
|
||||
fullName = "IBM Public License v1.0";
|
||||
};
|
||||
|
||||
isc = spdx {
|
||||
spdxId = "ISC";
|
||||
fullName = "ISC License";
|
||||
};
|
||||
|
||||
# Proprietary binaries; free to redistribute without modification.
|
||||
issl = {
|
||||
fullName = "Intel Simplified Software License";
|
||||
url = https://software.intel.com/en-us/license/intel-simplified-software-license;
|
||||
free = false;
|
||||
};
|
||||
|
||||
jasper = spdx {
|
||||
spdxId = "JasPer-2.0";
|
||||
fullName = "JasPer License";
|
||||
};
|
||||
|
||||
lgpl2 = spdx {
|
||||
spdxId = "LGPL-2.0-only";
|
||||
fullName = "GNU Library General Public License v2 only";
|
||||
};
|
||||
|
||||
lgpl2Plus = spdx {
|
||||
spdxId = "LGPL-2.0-or-later";
|
||||
fullName = "GNU Library General Public License v2 or later";
|
||||
};
|
||||
|
||||
lgpl21 = spdx {
|
||||
spdxId = "LGPL-2.1-only";
|
||||
fullName = "GNU Library General Public License v2.1 only";
|
||||
};
|
||||
|
||||
lgpl21Plus = spdx {
|
||||
spdxId = "LGPL-2.1-or-later";
|
||||
fullName = "GNU Library General Public License v2.1 or later";
|
||||
};
|
||||
|
||||
lgpl3 = spdx {
|
||||
spdxId = "LGPL-3.0-only";
|
||||
fullName = "GNU Lesser General Public License v3.0 only";
|
||||
};
|
||||
|
||||
lgpl3Plus = spdx {
|
||||
spdxId = "LGPL-3.0-or-later";
|
||||
fullName = "GNU Lesser General Public License v3.0 or later";
|
||||
};
|
||||
|
||||
libpng = spdx {
|
||||
spdxId = "Libpng";
|
||||
fullName = "libpng License";
|
||||
};
|
||||
|
||||
libpng2 = {
|
||||
fullName = "libpng License v2"; # 1.6.36+
|
||||
url = "http://www.libpng.org/pub/png/src/libpng-LICENSE.txt";
|
||||
};
|
||||
|
||||
libtiff = spdx {
|
||||
spdxId = "libtiff";
|
||||
fullName = "libtiff License";
|
||||
};
|
||||
|
||||
llgpl21 = {
|
||||
fullName = "Lisp LGPL; GNU Lesser General Public License version 2.1 with Franz Inc. preamble for clarification of LGPL terms in context of Lisp";
|
||||
url = http://opensource.franz.com/preamble.html;
|
||||
};
|
||||
|
||||
lppl12 = spdx {
|
||||
spdxId = "LPPL-1.2";
|
||||
fullName = "LaTeX Project Public License v1.2";
|
||||
};
|
||||
|
||||
lppl13c = spdx {
|
||||
spdxId = "LPPL-1.3c";
|
||||
fullName = "LaTeX Project Public License v1.3c";
|
||||
};
|
||||
|
||||
lpl-102 = spdx {
|
||||
spdxId = "LPL-1.02";
|
||||
fullName = "Lucent Public License v1.02";
|
||||
};
|
||||
|
||||
miros = {
|
||||
fullName = "MirOS License";
|
||||
url = https://opensource.org/licenses/MirOS;
|
||||
};
|
||||
|
||||
# spdx.org does not (yet) differentiate between the X11 and Expat versions
|
||||
# for details see http://en.wikipedia.org/wiki/MIT_License#Various_versions
|
||||
mit = spdx {
|
||||
spdxId = "MIT";
|
||||
fullName = "MIT License";
|
||||
};
|
||||
|
||||
mpl10 = spdx {
|
||||
spdxId = "MPL-1.0";
|
||||
fullName = "Mozilla Public License 1.0";
|
||||
};
|
||||
|
||||
mpl11 = spdx {
|
||||
spdxId = "MPL-1.1";
|
||||
fullName = "Mozilla Public License 1.1";
|
||||
};
|
||||
|
||||
mpl20 = spdx {
|
||||
spdxId = "MPL-2.0";
|
||||
fullName = "Mozilla Public License 2.0";
|
||||
};
|
||||
|
||||
mspl = spdx {
|
||||
spdxId = "MS-PL";
|
||||
fullName = "Microsoft Public License";
|
||||
};
|
||||
|
||||
msrla = {
|
||||
fullName = "Microsoft Research License Agreement";
|
||||
url = "http://research.microsoft.com/en-us/projects/pex/msr-la.txt";
|
||||
free = false;
|
||||
};
|
||||
|
||||
nasa13 = spdx {
|
||||
spdxId = "NASA-1.3";
|
||||
fullName = "NASA Open Source Agreement 1.3";
|
||||
free = false;
|
||||
};
|
||||
|
||||
ncsa = spdx {
|
||||
spdxId = "NCSA";
|
||||
fullName = "University of Illinois/NCSA Open Source License";
|
||||
};
|
||||
|
||||
notion_lgpl = {
|
||||
url = "https://raw.githubusercontent.com/raboof/notion/master/LICENSE";
|
||||
fullName = "Notion modified LGPL";
|
||||
};
|
||||
|
||||
nposl3 = spdx {
|
||||
spdxId = "NPOSL-3.0";
|
||||
fullName = "Non-Profit Open Software License 3.0";
|
||||
};
|
||||
|
||||
ocamlpro_nc = {
|
||||
fullName = "OCamlPro Non Commercial license version 1";
|
||||
url = "https://alt-ergo.ocamlpro.com/http/alt-ergo-2.2.0/OCamlPro-Non-Commercial-License.pdf";
|
||||
free = false;
|
||||
};
|
||||
|
||||
ofl = spdx {
|
||||
spdxId = "OFL-1.1";
|
||||
fullName = "SIL Open Font License 1.1";
|
||||
};
|
||||
|
||||
openldap = spdx {
|
||||
spdxId = "OLDAP-2.8";
|
||||
fullName = "Open LDAP Public License v2.8";
|
||||
};
|
||||
|
||||
openssl = spdx {
|
||||
spdxId = "OpenSSL";
|
||||
fullName = "OpenSSL License";
|
||||
};
|
||||
|
||||
osl2 = spdx {
|
||||
spdxId = "OSL-2.0";
|
||||
fullName = "Open Software License 2.0";
|
||||
};
|
||||
|
||||
osl21 = spdx {
|
||||
spdxId = "OSL-2.1";
|
||||
fullName = "Open Software License 2.1";
|
||||
};
|
||||
|
||||
osl3 = spdx {
|
||||
spdxId = "OSL-3.0";
|
||||
fullName = "Open Software License 3.0";
|
||||
};
|
||||
|
||||
php301 = spdx {
|
||||
spdxId = "PHP-3.01";
|
||||
fullName = "PHP License v3.01";
|
||||
};
|
||||
|
||||
postgresql = spdx {
|
||||
spdxId = "PostgreSQL";
|
||||
fullName = "PostgreSQL License";
|
||||
};
|
||||
|
||||
postman = {
|
||||
fullName = "Postman EULA";
|
||||
url = https://www.getpostman.com/licenses/postman_base_app;
|
||||
free = false;
|
||||
};
|
||||
|
||||
psfl = spdx {
|
||||
spdxId = "Python-2.0";
|
||||
fullName = "Python Software Foundation License version 2";
|
||||
#url = http://docs.python.org/license.html;
|
||||
};
|
||||
|
||||
publicDomain = {
|
||||
fullName = "Public Domain";
|
||||
};
|
||||
|
||||
purdueBsd = {
|
||||
fullName = " Purdue BSD-Style License"; # also know as lsof license
|
||||
url = https://enterprise.dejacode.com/licenses/public/purdue-bsd;
|
||||
};
|
||||
|
||||
qpl = spdx {
|
||||
spdxId = "QPL-1.0";
|
||||
fullName = "Q Public License 1.0";
|
||||
};
|
||||
|
||||
qwt = {
|
||||
fullName = "Qwt License, Version 1.0";
|
||||
url = http://qwt.sourceforge.net/qwtlicense.html;
|
||||
};
|
||||
|
||||
ruby = spdx {
|
||||
spdxId = "Ruby";
|
||||
fullName = "Ruby License";
|
||||
};
|
||||
|
||||
sendmail = spdx {
|
||||
spdxId = "Sendmail";
|
||||
fullName = "Sendmail License";
|
||||
};
|
||||
|
||||
sgi-b-20 = spdx {
|
||||
spdxId = "SGI-B-2.0";
|
||||
fullName = "SGI Free Software License B v2.0";
|
||||
};
|
||||
|
||||
sleepycat = spdx {
|
||||
spdxId = "Sleepycat";
|
||||
fullName = "Sleepycat License";
|
||||
};
|
||||
|
||||
smail = {
|
||||
shortName = "smail";
|
||||
fullName = "SMAIL General Public License";
|
||||
url = http://metadata.ftp-master.debian.org/changelogs/main/d/debianutils/debianutils_4.8.1_copyright;
|
||||
};
|
||||
|
||||
tcltk = spdx {
|
||||
spdxId = "TCL";
|
||||
fullName = "TCL/TK License";
|
||||
};
|
||||
|
||||
ufl = {
|
||||
fullName = "Ubuntu Font License 1.0";
|
||||
url = http://font.ubuntu.com/ufl/ubuntu-font-licence-1.0.txt;
|
||||
};
|
||||
|
||||
unfree = {
|
||||
fullName = "Unfree";
|
||||
free = false;
|
||||
};
|
||||
|
||||
unfreeRedistributable = {
|
||||
fullName = "Unfree redistributable";
|
||||
free = false;
|
||||
};
|
||||
|
||||
unfreeRedistributableFirmware = {
|
||||
fullName = "Unfree redistributable firmware";
|
||||
# Note: we currently consider these "free" for inclusion in the
|
||||
# channel and NixOS images.
|
||||
};
|
||||
|
||||
unlicense = spdx {
|
||||
spdxId = "Unlicense";
|
||||
fullName = "The Unlicense";
|
||||
};
|
||||
|
||||
upl = {
|
||||
fullName = "Universal Permissive License";
|
||||
url = "https://oss.oracle.com/licenses/upl/";
|
||||
};
|
||||
|
||||
vim = spdx {
|
||||
spdxId = "Vim";
|
||||
fullName = "Vim License";
|
||||
};
|
||||
|
||||
virtualbox-puel = {
|
||||
fullName = "Oracle VM VirtualBox Extension Pack Personal Use and Evaluation License (PUEL)";
|
||||
url = "https://www.virtualbox.org/wiki/VirtualBox_PUEL";
|
||||
free = false;
|
||||
};
|
||||
|
||||
vsl10 = spdx {
|
||||
spdxId = "VSL-1.0";
|
||||
fullName = "Vovida Software License v1.0";
|
||||
};
|
||||
|
||||
watcom = spdx {
|
||||
spdxId = "Watcom-1.0";
|
||||
fullName = "Sybase Open Watcom Public License 1.0";
|
||||
};
|
||||
|
||||
w3c = spdx {
|
||||
spdxId = "W3C";
|
||||
fullName = "W3C Software Notice and License";
|
||||
};
|
||||
|
||||
wadalab = {
|
||||
fullName = "Wadalab Font License";
|
||||
url = https://fedoraproject.org/wiki/Licensing:Wadalab?rd=Licensing/Wadalab;
|
||||
};
|
||||
|
||||
wtfpl = spdx {
|
||||
spdxId = "WTFPL";
|
||||
fullName = "Do What The F*ck You Want To Public License";
|
||||
};
|
||||
|
||||
wxWindows = spdx {
|
||||
spdxId = "wxWindows";
|
||||
fullName = "wxWindows Library Licence, Version 3.1";
|
||||
};
|
||||
|
||||
xfig = {
|
||||
fullName = "xfig";
|
||||
url = "http://mcj.sourceforge.net/authors.html#xfig";
|
||||
};
|
||||
|
||||
zlib = spdx {
|
||||
spdxId = "Zlib";
|
||||
fullName = "zlib License";
|
||||
};
|
||||
|
||||
zpl20 = spdx {
|
||||
spdxId = "ZPL-2.0";
|
||||
fullName = "Zope Public License 2.0";
|
||||
};
|
||||
|
||||
zpl21 = spdx {
|
||||
spdxId = "ZPL-2.1";
|
||||
fullName = "Zope Public License 2.1";
|
||||
};
|
||||
}
|
||||
663
lib/lists.nix
663
lib/lists.nix
@@ -1,663 +0,0 @@
|
||||
# General list operations.
|
||||
|
||||
{ lib }:
|
||||
with lib.trivial;
|
||||
let
|
||||
inherit (lib.strings) toInt;
|
||||
in
|
||||
rec {
|
||||
|
||||
inherit (builtins) head tail length isList elemAt concatLists filter elem genList;
|
||||
|
||||
/* Create a list consisting of a single element. `singleton x` is
|
||||
sometimes more convenient with respect to indentation than `[x]`
|
||||
when x spans multiple lines.
|
||||
|
||||
Type: singleton :: a -> [a]
|
||||
|
||||
Example:
|
||||
singleton "foo"
|
||||
=> [ "foo" ]
|
||||
*/
|
||||
singleton = x: [x];
|
||||
|
||||
/* “right fold” a binary function `op` between successive elements of
|
||||
`list` with `nul' as the starting value, i.e.,
|
||||
`foldr op nul [x_1 x_2 ... x_n] == op x_1 (op x_2 ... (op x_n nul))`.
|
||||
|
||||
Type: foldr :: (a -> b -> b) -> b -> [a] -> b
|
||||
|
||||
Example:
|
||||
concat = foldr (a: b: a + b) "z"
|
||||
concat [ "a" "b" "c" ]
|
||||
=> "abcz"
|
||||
# different types
|
||||
strange = foldr (int: str: toString (int + 1) + str) "a"
|
||||
strange [ 1 2 3 4 ]
|
||||
=> "2345a"
|
||||
*/
|
||||
foldr = op: nul: list:
|
||||
let
|
||||
len = length list;
|
||||
fold' = n:
|
||||
if n == len
|
||||
then nul
|
||||
else op (elemAt list n) (fold' (n + 1));
|
||||
in fold' 0;
|
||||
|
||||
/* `fold` is an alias of `foldr` for historic reasons */
|
||||
# FIXME(Profpatsch): deprecate?
|
||||
fold = foldr;
|
||||
|
||||
|
||||
/* “left fold”, like `foldr`, but from the left:
|
||||
`foldl op nul [x_1 x_2 ... x_n] == op (... (op (op nul x_1) x_2) ... x_n)`.
|
||||
|
||||
Type: foldl :: (b -> a -> b) -> b -> [a] -> b
|
||||
|
||||
Example:
|
||||
lconcat = foldl (a: b: a + b) "z"
|
||||
lconcat [ "a" "b" "c" ]
|
||||
=> "zabc"
|
||||
# different types
|
||||
lstrange = foldl (str: int: str + toString (int + 1)) ""
|
||||
strange [ 1 2 3 4 ]
|
||||
=> "a2345"
|
||||
*/
|
||||
foldl = op: nul: list:
|
||||
let
|
||||
foldl' = n:
|
||||
if n == -1
|
||||
then nul
|
||||
else op (foldl' (n - 1)) (elemAt list n);
|
||||
in foldl' (length list - 1);
|
||||
|
||||
/* Strict version of `foldl`.
|
||||
|
||||
The difference is that evaluation is forced upon access. Usually used
|
||||
with small whole results (in contract with lazily-generated list or large
|
||||
lists where only a part is consumed.)
|
||||
|
||||
Type: foldl' :: (b -> a -> b) -> b -> [a] -> b
|
||||
*/
|
||||
foldl' = builtins.foldl' or foldl;
|
||||
|
||||
/* Map with index starting from 0
|
||||
|
||||
Type: imap0 :: (int -> a -> b) -> [a] -> [b]
|
||||
|
||||
Example:
|
||||
imap0 (i: v: "${v}-${toString i}") ["a" "b"]
|
||||
=> [ "a-0" "b-1" ]
|
||||
*/
|
||||
imap0 = f: list: genList (n: f n (elemAt list n)) (length list);
|
||||
|
||||
/* Map with index starting from 1
|
||||
|
||||
Type: imap1 :: (int -> a -> b) -> [a] -> [b]
|
||||
|
||||
Example:
|
||||
imap1 (i: v: "${v}-${toString i}") ["a" "b"]
|
||||
=> [ "a-1" "b-2" ]
|
||||
*/
|
||||
imap1 = f: list: genList (n: f (n + 1) (elemAt list n)) (length list);
|
||||
|
||||
/* Map and concatenate the result.
|
||||
|
||||
Type: concatMap :: (a -> [b]) -> [a] -> [b]
|
||||
|
||||
Example:
|
||||
concatMap (x: [x] ++ ["z"]) ["a" "b"]
|
||||
=> [ "a" "z" "b" "z" ]
|
||||
*/
|
||||
concatMap = builtins.concatMap or (f: list: concatLists (map f list));
|
||||
|
||||
/* Flatten the argument into a single list; that is, nested lists are
|
||||
spliced into the top-level lists.
|
||||
|
||||
Example:
|
||||
flatten [1 [2 [3] 4] 5]
|
||||
=> [1 2 3 4 5]
|
||||
flatten 1
|
||||
=> [1]
|
||||
*/
|
||||
flatten = x:
|
||||
if isList x
|
||||
then concatMap (y: flatten y) x
|
||||
else [x];
|
||||
|
||||
/* Remove elements equal to 'e' from a list. Useful for buildInputs.
|
||||
|
||||
Type: remove :: a -> [a] -> [a]
|
||||
|
||||
Example:
|
||||
remove 3 [ 1 3 4 3 ]
|
||||
=> [ 1 4 ]
|
||||
*/
|
||||
remove =
|
||||
# Element to remove from the list
|
||||
e: filter (x: x != e);
|
||||
|
||||
/* Find the sole element in the list matching the specified
|
||||
predicate, returns `default` if no such element exists, or
|
||||
`multiple` if there are multiple matching elements.
|
||||
|
||||
Type: findSingle :: (a -> bool) -> a -> a -> [a] -> a
|
||||
|
||||
Example:
|
||||
findSingle (x: x == 3) "none" "multiple" [ 1 3 3 ]
|
||||
=> "multiple"
|
||||
findSingle (x: x == 3) "none" "multiple" [ 1 3 ]
|
||||
=> 3
|
||||
findSingle (x: x == 3) "none" "multiple" [ 1 9 ]
|
||||
=> "none"
|
||||
*/
|
||||
findSingle =
|
||||
# Predicate
|
||||
pred:
|
||||
# Default value to return if element was not found.
|
||||
default:
|
||||
# Default value to return if more than one element was found
|
||||
multiple:
|
||||
# Input list
|
||||
list:
|
||||
let found = filter pred list; len = length found;
|
||||
in if len == 0 then default
|
||||
else if len != 1 then multiple
|
||||
else head found;
|
||||
|
||||
/* Find the first element in the list matching the specified
|
||||
predicate or return `default` if no such element exists.
|
||||
|
||||
Type: findFirst :: (a -> bool) -> a -> [a] -> a
|
||||
|
||||
Example:
|
||||
findFirst (x: x > 3) 7 [ 1 6 4 ]
|
||||
=> 6
|
||||
findFirst (x: x > 9) 7 [ 1 6 4 ]
|
||||
=> 7
|
||||
*/
|
||||
findFirst =
|
||||
# Predicate
|
||||
pred:
|
||||
# Default value to return
|
||||
default:
|
||||
# Input list
|
||||
list:
|
||||
let found = filter pred list;
|
||||
in if found == [] then default else head found;
|
||||
|
||||
/* Return true if function `pred` returns true for at least one
|
||||
element of `list`.
|
||||
|
||||
Type: any :: (a -> bool) -> [a] -> bool
|
||||
|
||||
Example:
|
||||
any isString [ 1 "a" { } ]
|
||||
=> true
|
||||
any isString [ 1 { } ]
|
||||
=> false
|
||||
*/
|
||||
any = builtins.any or (pred: foldr (x: y: if pred x then true else y) false);
|
||||
|
||||
/* Return true if function `pred` returns true for all elements of
|
||||
`list`.
|
||||
|
||||
Type: all :: (a -> bool) -> [a] -> bool
|
||||
|
||||
Example:
|
||||
all (x: x < 3) [ 1 2 ]
|
||||
=> true
|
||||
all (x: x < 3) [ 1 2 3 ]
|
||||
=> false
|
||||
*/
|
||||
all = builtins.all or (pred: foldr (x: y: if pred x then y else false) true);
|
||||
|
||||
/* Count how many elements of `list` match the supplied predicate
|
||||
function.
|
||||
|
||||
Type: count :: (a -> bool) -> [a] -> int
|
||||
|
||||
Example:
|
||||
count (x: x == 3) [ 3 2 3 4 6 ]
|
||||
=> 2
|
||||
*/
|
||||
count =
|
||||
# Predicate
|
||||
pred: foldl' (c: x: if pred x then c + 1 else c) 0;
|
||||
|
||||
/* Return a singleton list or an empty list, depending on a boolean
|
||||
value. Useful when building lists with optional elements
|
||||
(e.g. `++ optional (system == "i686-linux") flashplayer').
|
||||
|
||||
Type: optional :: bool -> a -> [a]
|
||||
|
||||
Example:
|
||||
optional true "foo"
|
||||
=> [ "foo" ]
|
||||
optional false "foo"
|
||||
=> [ ]
|
||||
*/
|
||||
optional = cond: elem: if cond then [elem] else [];
|
||||
|
||||
/* Return a list or an empty list, depending on a boolean value.
|
||||
|
||||
Type: optionals :: bool -> [a] -> [a]
|
||||
|
||||
Example:
|
||||
optionals true [ 2 3 ]
|
||||
=> [ 2 3 ]
|
||||
optionals false [ 2 3 ]
|
||||
=> [ ]
|
||||
*/
|
||||
optionals =
|
||||
# Condition
|
||||
cond:
|
||||
# List to return if condition is true
|
||||
elems: if cond then elems else [];
|
||||
|
||||
|
||||
/* If argument is a list, return it; else, wrap it in a singleton
|
||||
list. If you're using this, you should almost certainly
|
||||
reconsider if there isn't a more "well-typed" approach.
|
||||
|
||||
Example:
|
||||
toList [ 1 2 ]
|
||||
=> [ 1 2 ]
|
||||
toList "hi"
|
||||
=> [ "hi "]
|
||||
*/
|
||||
toList = x: if isList x then x else [x];
|
||||
|
||||
/* Return a list of integers from `first' up to and including `last'.
|
||||
|
||||
Type: range :: int -> int -> [int]
|
||||
|
||||
Example:
|
||||
range 2 4
|
||||
=> [ 2 3 4 ]
|
||||
range 3 2
|
||||
=> [ ]
|
||||
*/
|
||||
range =
|
||||
# First integer in the range
|
||||
first:
|
||||
# Last integer in the range
|
||||
last:
|
||||
if first > last then
|
||||
[]
|
||||
else
|
||||
genList (n: first + n) (last - first + 1);
|
||||
|
||||
/* Splits the elements of a list in two lists, `right` and
|
||||
`wrong`, depending on the evaluation of a predicate.
|
||||
|
||||
Type: (a -> bool) -> [a] -> { right :: [a], wrong :: [a] }
|
||||
|
||||
Example:
|
||||
partition (x: x > 2) [ 5 1 2 3 4 ]
|
||||
=> { right = [ 5 3 4 ]; wrong = [ 1 2 ]; }
|
||||
*/
|
||||
partition = builtins.partition or (pred:
|
||||
foldr (h: t:
|
||||
if pred h
|
||||
then { right = [h] ++ t.right; wrong = t.wrong; }
|
||||
else { right = t.right; wrong = [h] ++ t.wrong; }
|
||||
) { right = []; wrong = []; });
|
||||
|
||||
/* Splits the elements of a list into many lists, using the return value of a predicate.
|
||||
Predicate should return a string which becomes keys of attrset `groupBy' returns.
|
||||
|
||||
`groupBy'` allows to customise the combining function and initial value
|
||||
|
||||
Example:
|
||||
groupBy (x: boolToString (x > 2)) [ 5 1 2 3 4 ]
|
||||
=> { true = [ 5 3 4 ]; false = [ 1 2 ]; }
|
||||
groupBy (x: x.name) [ {name = "icewm"; script = "icewm &";}
|
||||
{name = "xfce"; script = "xfce4-session &";}
|
||||
{name = "icewm"; script = "icewmbg &";}
|
||||
{name = "mate"; script = "gnome-session &";}
|
||||
]
|
||||
=> { icewm = [ { name = "icewm"; script = "icewm &"; }
|
||||
{ name = "icewm"; script = "icewmbg &"; } ];
|
||||
mate = [ { name = "mate"; script = "gnome-session &"; } ];
|
||||
xfce = [ { name = "xfce"; script = "xfce4-session &"; } ];
|
||||
}
|
||||
|
||||
groupBy' builtins.add 0 (x: boolToString (x > 2)) [ 5 1 2 3 4 ]
|
||||
=> { true = 12; false = 3; }
|
||||
*/
|
||||
groupBy' = op: nul: pred: lst:
|
||||
foldl' (r: e:
|
||||
let
|
||||
key = pred e;
|
||||
in
|
||||
r // { ${key} = op (r.${key} or nul) e; }
|
||||
) {} lst;
|
||||
|
||||
groupBy = groupBy' (sum: e: sum ++ [e]) [];
|
||||
|
||||
/* Merges two lists of the same size together. If the sizes aren't the same
|
||||
the merging stops at the shortest. How both lists are merged is defined
|
||||
by the first argument.
|
||||
|
||||
Type: zipListsWith :: (a -> b -> c) -> [a] -> [b] -> [c]
|
||||
|
||||
Example:
|
||||
zipListsWith (a: b: a + b) ["h" "l"] ["e" "o"]
|
||||
=> ["he" "lo"]
|
||||
*/
|
||||
zipListsWith =
|
||||
# Function to zip elements of both lists
|
||||
f:
|
||||
# First list
|
||||
fst:
|
||||
# Second list
|
||||
snd:
|
||||
genList
|
||||
(n: f (elemAt fst n) (elemAt snd n)) (min (length fst) (length snd));
|
||||
|
||||
/* Merges two lists of the same size together. If the sizes aren't the same
|
||||
the merging stops at the shortest.
|
||||
|
||||
Type: zipLists :: [a] -> [b] -> [{ fst :: a, snd :: b}]
|
||||
|
||||
Example:
|
||||
zipLists [ 1 2 ] [ "a" "b" ]
|
||||
=> [ { fst = 1; snd = "a"; } { fst = 2; snd = "b"; } ]
|
||||
*/
|
||||
zipLists = zipListsWith (fst: snd: { inherit fst snd; });
|
||||
|
||||
/* Reverse the order of the elements of a list.
|
||||
|
||||
Type: reverseList :: [a] -> [a]
|
||||
|
||||
Example:
|
||||
|
||||
reverseList [ "b" "o" "j" ]
|
||||
=> [ "j" "o" "b" ]
|
||||
*/
|
||||
reverseList = xs:
|
||||
let l = length xs; in genList (n: elemAt xs (l - n - 1)) l;
|
||||
|
||||
/* Depth-First Search (DFS) for lists `list != []`.
|
||||
|
||||
`before a b == true` means that `b` depends on `a` (there's an
|
||||
edge from `b` to `a`).
|
||||
|
||||
Example:
|
||||
listDfs true hasPrefix [ "/home/user" "other" "/" "/home" ]
|
||||
== { minimal = "/"; # minimal element
|
||||
visited = [ "/home/user" ]; # seen elements (in reverse order)
|
||||
rest = [ "/home" "other" ]; # everything else
|
||||
}
|
||||
|
||||
listDfs true hasPrefix [ "/home/user" "other" "/" "/home" "/" ]
|
||||
== { cycle = "/"; # cycle encountered at this element
|
||||
loops = [ "/" ]; # and continues to these elements
|
||||
visited = [ "/" "/home/user" ]; # elements leading to the cycle (in reverse order)
|
||||
rest = [ "/home" "other" ]; # everything else
|
||||
|
||||
*/
|
||||
listDfs = stopOnCycles: before: list:
|
||||
let
|
||||
dfs' = us: visited: rest:
|
||||
let
|
||||
c = filter (x: before x us) visited;
|
||||
b = partition (x: before x us) rest;
|
||||
in if stopOnCycles && (length c > 0)
|
||||
then { cycle = us; loops = c; inherit visited rest; }
|
||||
else if length b.right == 0
|
||||
then # nothing is before us
|
||||
{ minimal = us; inherit visited rest; }
|
||||
else # grab the first one before us and continue
|
||||
dfs' (head b.right)
|
||||
([ us ] ++ visited)
|
||||
(tail b.right ++ b.wrong);
|
||||
in dfs' (head list) [] (tail list);
|
||||
|
||||
/* Sort a list based on a partial ordering using DFS. This
|
||||
implementation is O(N^2), if your ordering is linear, use `sort`
|
||||
instead.
|
||||
|
||||
`before a b == true` means that `b` should be after `a`
|
||||
in the result.
|
||||
|
||||
Example:
|
||||
|
||||
toposort hasPrefix [ "/home/user" "other" "/" "/home" ]
|
||||
== { result = [ "/" "/home" "/home/user" "other" ]; }
|
||||
|
||||
toposort hasPrefix [ "/home/user" "other" "/" "/home" "/" ]
|
||||
== { cycle = [ "/home/user" "/" "/" ]; # path leading to a cycle
|
||||
loops = [ "/" ]; } # loops back to these elements
|
||||
|
||||
toposort hasPrefix [ "other" "/home/user" "/home" "/" ]
|
||||
== { result = [ "other" "/" "/home" "/home/user" ]; }
|
||||
|
||||
toposort (a: b: a < b) [ 3 2 1 ] == { result = [ 1 2 3 ]; }
|
||||
|
||||
*/
|
||||
toposort = before: list:
|
||||
let
|
||||
dfsthis = listDfs true before list;
|
||||
toporest = toposort before (dfsthis.visited ++ dfsthis.rest);
|
||||
in
|
||||
if length list < 2
|
||||
then # finish
|
||||
{ result = list; }
|
||||
else if dfsthis ? "cycle"
|
||||
then # there's a cycle, starting from the current vertex, return it
|
||||
{ cycle = reverseList ([ dfsthis.cycle ] ++ dfsthis.visited);
|
||||
inherit (dfsthis) loops; }
|
||||
else if toporest ? "cycle"
|
||||
then # there's a cycle somewhere else in the graph, return it
|
||||
toporest
|
||||
# Slow, but short. Can be made a bit faster with an explicit stack.
|
||||
else # there are no cycles
|
||||
{ result = [ dfsthis.minimal ] ++ toporest.result; };
|
||||
|
||||
/* Sort a list based on a comparator function which compares two
|
||||
elements and returns true if the first argument is strictly below
|
||||
the second argument. The returned list is sorted in an increasing
|
||||
order. The implementation does a quick-sort.
|
||||
|
||||
Example:
|
||||
sort (a: b: a < b) [ 5 3 7 ]
|
||||
=> [ 3 5 7 ]
|
||||
*/
|
||||
sort = builtins.sort or (
|
||||
strictLess: list:
|
||||
let
|
||||
len = length list;
|
||||
first = head list;
|
||||
pivot' = n: acc@{ left, right }: let el = elemAt list n; next = pivot' (n + 1); in
|
||||
if n == len
|
||||
then acc
|
||||
else if strictLess first el
|
||||
then next { inherit left; right = [ el ] ++ right; }
|
||||
else
|
||||
next { left = [ el ] ++ left; inherit right; };
|
||||
pivot = pivot' 1 { left = []; right = []; };
|
||||
in
|
||||
if len < 2 then list
|
||||
else (sort strictLess pivot.left) ++ [ first ] ++ (sort strictLess pivot.right));
|
||||
|
||||
/* Compare two lists element-by-element.
|
||||
|
||||
Example:
|
||||
compareLists compare [] []
|
||||
=> 0
|
||||
compareLists compare [] [ "a" ]
|
||||
=> -1
|
||||
compareLists compare [ "a" ] []
|
||||
=> 1
|
||||
compareLists compare [ "a" "b" ] [ "a" "c" ]
|
||||
=> 1
|
||||
*/
|
||||
compareLists = cmp: a: b:
|
||||
if a == []
|
||||
then if b == []
|
||||
then 0
|
||||
else -1
|
||||
else if b == []
|
||||
then 1
|
||||
else let rel = cmp (head a) (head b); in
|
||||
if rel == 0
|
||||
then compareLists cmp (tail a) (tail b)
|
||||
else rel;
|
||||
|
||||
/* Sort list using "Natural sorting".
|
||||
Numeric portions of strings are sorted in numeric order.
|
||||
|
||||
Example:
|
||||
naturalSort ["disk11" "disk8" "disk100" "disk9"]
|
||||
=> ["disk8" "disk9" "disk11" "disk100"]
|
||||
naturalSort ["10.46.133.149" "10.5.16.62" "10.54.16.25"]
|
||||
=> ["10.5.16.62" "10.46.133.149" "10.54.16.25"]
|
||||
naturalSort ["v0.2" "v0.15" "v0.0.9"]
|
||||
=> [ "v0.0.9" "v0.2" "v0.15" ]
|
||||
*/
|
||||
naturalSort = lst:
|
||||
let
|
||||
vectorise = s: map (x: if isList x then toInt (head x) else x) (builtins.split "(0|[1-9][0-9]*)" s);
|
||||
prepared = map (x: [ (vectorise x) x ]) lst; # remember vectorised version for O(n) regex splits
|
||||
less = a: b: (compareLists compare (head a) (head b)) < 0;
|
||||
in
|
||||
map (x: elemAt x 1) (sort less prepared);
|
||||
|
||||
/* Return the first (at most) N elements of a list.
|
||||
|
||||
Type: take :: int -> [a] -> [a]
|
||||
|
||||
Example:
|
||||
take 2 [ "a" "b" "c" "d" ]
|
||||
=> [ "a" "b" ]
|
||||
take 2 [ ]
|
||||
=> [ ]
|
||||
*/
|
||||
take =
|
||||
# Number of elements to take
|
||||
count: sublist 0 count;
|
||||
|
||||
/* Remove the first (at most) N elements of a list.
|
||||
|
||||
Type: drop :: int -> [a] -> [a]
|
||||
|
||||
Example:
|
||||
drop 2 [ "a" "b" "c" "d" ]
|
||||
=> [ "c" "d" ]
|
||||
drop 2 [ ]
|
||||
=> [ ]
|
||||
*/
|
||||
drop =
|
||||
# Number of elements to drop
|
||||
count:
|
||||
# Input list
|
||||
list: sublist count (length list) list;
|
||||
|
||||
/* Return a list consisting of at most `count` elements of `list`,
|
||||
starting at index `start`.
|
||||
|
||||
Type: sublist :: int -> int -> [a] -> [a]
|
||||
|
||||
Example:
|
||||
sublist 1 3 [ "a" "b" "c" "d" "e" ]
|
||||
=> [ "b" "c" "d" ]
|
||||
sublist 1 3 [ ]
|
||||
=> [ ]
|
||||
*/
|
||||
sublist =
|
||||
# Index at which to start the sublist
|
||||
start:
|
||||
# Number of elements to take
|
||||
count:
|
||||
# Input list
|
||||
list:
|
||||
let len = length list; in
|
||||
genList
|
||||
(n: elemAt list (n + start))
|
||||
(if start >= len then 0
|
||||
else if start + count > len then len - start
|
||||
else count);
|
||||
|
||||
/* Return the last element of a list.
|
||||
|
||||
This function throws an error if the list is empty.
|
||||
|
||||
Type: last :: [a] -> a
|
||||
|
||||
Example:
|
||||
last [ 1 2 3 ]
|
||||
=> 3
|
||||
*/
|
||||
last = list:
|
||||
assert lib.assertMsg (list != []) "lists.last: list must not be empty!";
|
||||
elemAt list (length list - 1);
|
||||
|
||||
/* Return all elements but the last.
|
||||
|
||||
This function throws an error if the list is empty.
|
||||
|
||||
Type: init :: [a] -> [a]
|
||||
|
||||
Example:
|
||||
init [ 1 2 3 ]
|
||||
=> [ 1 2 ]
|
||||
*/
|
||||
init = list:
|
||||
assert lib.assertMsg (list != []) "lists.init: list must not be empty!";
|
||||
take (length list - 1) list;
|
||||
|
||||
|
||||
/* Return the image of the cross product of some lists by a function.
|
||||
|
||||
Example:
|
||||
crossLists (x:y: "${toString x}${toString y}") [[1 2] [3 4]]
|
||||
=> [ "13" "14" "23" "24" ]
|
||||
*/
|
||||
crossLists = f: foldl (fs: args: concatMap (f: map f args) fs) [f];
|
||||
|
||||
|
||||
/* Remove duplicate elements from the list. O(n^2) complexity.
|
||||
|
||||
Type: unique :: [a] -> [a]
|
||||
|
||||
Example:
|
||||
unique [ 3 2 3 4 ]
|
||||
=> [ 3 2 4 ]
|
||||
*/
|
||||
unique = list:
|
||||
if list == [] then
|
||||
[]
|
||||
else
|
||||
let
|
||||
x = head list;
|
||||
xs = unique (drop 1 list);
|
||||
in [x] ++ remove x xs;
|
||||
|
||||
/* Intersects list 'e' and another list. O(nm) complexity.
|
||||
|
||||
Example:
|
||||
intersectLists [ 1 2 3 ] [ 6 3 2 ]
|
||||
=> [ 3 2 ]
|
||||
*/
|
||||
intersectLists = e: filter (x: elem x e);
|
||||
|
||||
/* Subtracts list 'e' from another list. O(nm) complexity.
|
||||
|
||||
Example:
|
||||
subtractLists [ 3 2 ] [ 1 2 3 4 5 3 ]
|
||||
=> [ 1 4 5 ]
|
||||
*/
|
||||
subtractLists = e: filter (x: !(elem x e));
|
||||
|
||||
/* Test if two lists have no common element.
|
||||
It should be slightly more efficient than (intersectLists a b == [])
|
||||
*/
|
||||
mutuallyExclusive = a: b:
|
||||
(builtins.length a) == 0 ||
|
||||
(!(builtins.elem (builtins.head a) b) &&
|
||||
mutuallyExclusive (builtins.tail a) b);
|
||||
|
||||
}
|
||||
90
lib/meta.nix
90
lib/meta.nix
@@ -1,90 +0,0 @@
|
||||
/* Some functions for manipulating meta attributes, as well as the
|
||||
name attribute. */
|
||||
|
||||
{ lib }:
|
||||
|
||||
rec {
|
||||
|
||||
|
||||
/* Add to or override the meta attributes of the given
|
||||
derivation.
|
||||
|
||||
Example:
|
||||
addMetaAttrs {description = "Bla blah";} somePkg
|
||||
*/
|
||||
addMetaAttrs = newAttrs: drv:
|
||||
drv // { meta = (drv.meta or {}) // newAttrs; };
|
||||
|
||||
|
||||
/* Disable Hydra builds of given derivation.
|
||||
*/
|
||||
dontDistribute = drv: addMetaAttrs { hydraPlatforms = []; } drv;
|
||||
|
||||
|
||||
/* Change the symbolic name of a package for presentation purposes
|
||||
(i.e., so that nix-env users can tell them apart).
|
||||
*/
|
||||
setName = name: drv: drv // {inherit name;};
|
||||
|
||||
|
||||
/* Like `setName', but takes the previous name as an argument.
|
||||
|
||||
Example:
|
||||
updateName (oldName: oldName + "-experimental") somePkg
|
||||
*/
|
||||
updateName = updater: drv: drv // {name = updater (drv.name);};
|
||||
|
||||
|
||||
/* Append a suffix to the name of a package (before the version
|
||||
part). */
|
||||
appendToName = suffix: updateName (name:
|
||||
let x = builtins.parseDrvName name; in "${x.name}-${suffix}-${x.version}");
|
||||
|
||||
|
||||
/* Apply a function to each derivation and only to derivations in an attrset.
|
||||
*/
|
||||
mapDerivationAttrset = f: set: lib.mapAttrs (name: pkg: if lib.isDerivation pkg then (f pkg) else pkg) set;
|
||||
|
||||
/* Set the nix-env priority of the package.
|
||||
*/
|
||||
setPrio = priority: addMetaAttrs { inherit priority; };
|
||||
|
||||
/* Decrease the nix-env priority of the package, i.e., other
|
||||
versions/variants of the package will be preferred.
|
||||
*/
|
||||
lowPrio = setPrio 10;
|
||||
|
||||
/* Apply lowPrio to an attrset with derivations
|
||||
*/
|
||||
lowPrioSet = set: mapDerivationAttrset lowPrio set;
|
||||
|
||||
|
||||
/* Increase the nix-env priority of the package, i.e., this
|
||||
version/variant of the package will be preferred.
|
||||
*/
|
||||
hiPrio = setPrio (-10);
|
||||
|
||||
/* Apply hiPrio to an attrset with derivations
|
||||
*/
|
||||
hiPrioSet = set: mapDerivationAttrset hiPrio set;
|
||||
|
||||
|
||||
/* Check to see if a platform is matched by the given `meta.platforms`
|
||||
element.
|
||||
|
||||
A `meta.platform` pattern is either
|
||||
|
||||
1. (legacy) a system string.
|
||||
|
||||
2. (modern) a pattern for the platform `parsed` field.
|
||||
|
||||
We can inject these into a patten for the whole of a structured platform,
|
||||
and then match that.
|
||||
*/
|
||||
platformMatch = platform: elem: let
|
||||
pattern =
|
||||
if builtins.isString elem
|
||||
then { system = elem; }
|
||||
else { parsed = elem; };
|
||||
in lib.matchAttrs pattern platform;
|
||||
}
|
||||
@@ -1,2 +0,0 @@
|
||||
# Expose the minimum required version for evaluating Nixpkgs
|
||||
"2.0"
|
||||
734
lib/modules.nix
734
lib/modules.nix
@@ -1,734 +0,0 @@
|
||||
{ lib }:
|
||||
|
||||
with lib.lists;
|
||||
with lib.strings;
|
||||
with lib.trivial;
|
||||
with lib.attrsets;
|
||||
with lib.options;
|
||||
with lib.debug;
|
||||
with lib.types;
|
||||
|
||||
rec {
|
||||
|
||||
/* Evaluate a set of modules. The result is a set of two
|
||||
attributes: ‘options’: the nested set of all option declarations,
|
||||
and ‘config’: the nested set of all option values.
|
||||
!!! Please think twice before adding to this argument list! The more
|
||||
that is specified here instead of in the modules themselves the harder
|
||||
it is to transparently move a set of modules to be a submodule of another
|
||||
config (as the proper arguments need to be replicated at each call to
|
||||
evalModules) and the less declarative the module set is. */
|
||||
evalModules = { modules
|
||||
, prefix ? []
|
||||
, # This should only be used for special arguments that need to be evaluated
|
||||
# when resolving module structure (like in imports). For everything else,
|
||||
# there's _module.args. If specialArgs.modulesPath is defined it will be
|
||||
# used as the base path for disabledModules.
|
||||
specialArgs ? {}
|
||||
, # This would be remove in the future, Prefer _module.args option instead.
|
||||
args ? {}
|
||||
, # This would be remove in the future, Prefer _module.check option instead.
|
||||
check ? true
|
||||
}:
|
||||
let
|
||||
# This internal module declare internal options under the `_module'
|
||||
# attribute. These options are fragile, as they are used by the
|
||||
# module system to change the interpretation of modules.
|
||||
internalModule = rec {
|
||||
_file = ./modules.nix;
|
||||
|
||||
key = _file;
|
||||
|
||||
options = {
|
||||
_module.args = mkOption {
|
||||
type = types.attrsOf types.unspecified;
|
||||
internal = true;
|
||||
description = "Arguments passed to each module.";
|
||||
};
|
||||
|
||||
_module.check = mkOption {
|
||||
type = types.bool;
|
||||
internal = true;
|
||||
default = check;
|
||||
description = "Whether to check whether all option definitions have matching declarations.";
|
||||
};
|
||||
};
|
||||
|
||||
config = {
|
||||
_module.args = args;
|
||||
};
|
||||
};
|
||||
|
||||
closed = closeModules (modules ++ [ internalModule ]) ({ inherit config options lib; } // specialArgs);
|
||||
|
||||
options = mergeModules prefix (reverseList (filterModules (specialArgs.modulesPath or "") closed));
|
||||
|
||||
# Traverse options and extract the option values into the final
|
||||
# config set. At the same time, check whether all option
|
||||
# definitions have matching declarations.
|
||||
# !!! _module.check's value can't depend on any other config values
|
||||
# without an infinite recursion. One way around this is to make the
|
||||
# 'config' passed around to the modules be unconditionally unchecked,
|
||||
# and only do the check in 'result'.
|
||||
config = yieldConfig prefix options;
|
||||
yieldConfig = prefix: set:
|
||||
let res = removeAttrs (mapAttrs (n: v:
|
||||
if isOption v then v.value
|
||||
else yieldConfig (prefix ++ [n]) v) set) ["_definedNames"];
|
||||
in
|
||||
if options._module.check.value && set ? _definedNames then
|
||||
foldl' (res: m:
|
||||
foldl' (res: name:
|
||||
if set ? ${name} then res else throw "The option `${showOption (prefix ++ [name])}' defined in `${m.file}' does not exist.")
|
||||
res m.names)
|
||||
res set._definedNames
|
||||
else
|
||||
res;
|
||||
result = { inherit options config; };
|
||||
in result;
|
||||
|
||||
|
||||
# Filter disabled modules. Modules can be disabled allowing
|
||||
# their implementation to be replaced.
|
||||
filterModules = modulesPath: modules:
|
||||
let
|
||||
moduleKey = m: if isString m then toString modulesPath + "/" + m else toString m;
|
||||
disabledKeys = map moduleKey (concatMap (m: m.disabledModules) modules);
|
||||
in
|
||||
filter (m: !(elem m.key disabledKeys)) modules;
|
||||
|
||||
/* Close a set of modules under the ‘imports’ relation. */
|
||||
closeModules = modules: args:
|
||||
let
|
||||
toClosureList = file: parentKey: imap1 (n: x:
|
||||
if isAttrs x || isFunction x then
|
||||
let key = "${parentKey}:anon-${toString n}"; in
|
||||
unifyModuleSyntax file key (unpackSubmodule (applyIfFunction key) x args)
|
||||
else
|
||||
let file = toString x; key = toString x; in
|
||||
unifyModuleSyntax file key (applyIfFunction key (import x) args));
|
||||
in
|
||||
builtins.genericClosure {
|
||||
startSet = toClosureList unknownModule "" modules;
|
||||
operator = m: toClosureList m.file m.key m.imports;
|
||||
};
|
||||
|
||||
/* Massage a module into canonical form, that is, a set consisting
|
||||
of ‘options’, ‘config’ and ‘imports’ attributes. */
|
||||
unifyModuleSyntax = file: key: m:
|
||||
let metaSet = if m ? meta
|
||||
then { meta = m.meta; }
|
||||
else {};
|
||||
in
|
||||
if m ? config || m ? options then
|
||||
let badAttrs = removeAttrs m ["_file" "key" "disabledModules" "imports" "options" "config" "meta"]; in
|
||||
if badAttrs != {} then
|
||||
throw "Module `${key}' has an unsupported attribute `${head (attrNames badAttrs)}'. This is caused by assignments to the top-level attributes `config' or `options'."
|
||||
else
|
||||
{ file = m._file or file;
|
||||
key = toString m.key or key;
|
||||
disabledModules = m.disabledModules or [];
|
||||
imports = m.imports or [];
|
||||
options = m.options or {};
|
||||
config = mkMerge [ (m.config or {}) metaSet ];
|
||||
}
|
||||
else
|
||||
{ file = m._file or file;
|
||||
key = toString m.key or key;
|
||||
disabledModules = m.disabledModules or [];
|
||||
imports = m.require or [] ++ m.imports or [];
|
||||
options = {};
|
||||
config = mkMerge [ (removeAttrs m ["_file" "key" "disabledModules" "require" "imports"]) metaSet ];
|
||||
};
|
||||
|
||||
applyIfFunction = key: f: args@{ config, options, lib, ... }: if isFunction f then
|
||||
let
|
||||
# Module arguments are resolved in a strict manner when attribute set
|
||||
# deconstruction is used. As the arguments are now defined with the
|
||||
# config._module.args option, the strictness used on the attribute
|
||||
# set argument would cause an infinite loop, if the result of the
|
||||
# option is given as argument.
|
||||
#
|
||||
# To work-around the strictness issue on the deconstruction of the
|
||||
# attributes set argument, we create a new attribute set which is
|
||||
# constructed to satisfy the expected set of attributes. Thus calling
|
||||
# a module will resolve strictly the attributes used as argument but
|
||||
# not their values. The values are forwarding the result of the
|
||||
# evaluation of the option.
|
||||
requiredArgs = builtins.attrNames (lib.functionArgs f);
|
||||
context = name: ''while evaluating the module argument `${name}' in "${key}":'';
|
||||
extraArgs = builtins.listToAttrs (map (name: {
|
||||
inherit name;
|
||||
value = builtins.addErrorContext (context name)
|
||||
(args.${name} or config._module.args.${name});
|
||||
}) requiredArgs);
|
||||
|
||||
# Note: we append in the opposite order such that we can add an error
|
||||
# context on the explicited arguments of "args" too. This update
|
||||
# operator is used to make the "args@{ ... }: with args.lib;" notation
|
||||
# works.
|
||||
in f (args // extraArgs)
|
||||
else
|
||||
f;
|
||||
|
||||
/* We have to pack and unpack submodules. We cannot wrap the expected
|
||||
result of the function as we would no longer be able to list the arguments
|
||||
of the submodule. (see applyIfFunction) */
|
||||
unpackSubmodule = unpack: m: args:
|
||||
if isType "submodule" m then
|
||||
{ _file = m.file; } // (unpack m.submodule args)
|
||||
else unpack m args;
|
||||
|
||||
packSubmodule = file: m:
|
||||
{ _type = "submodule"; file = file; submodule = m; };
|
||||
|
||||
/* Merge a list of modules. This will recurse over the option
|
||||
declarations in all modules, combining them into a single set.
|
||||
At the same time, for each option declaration, it will merge the
|
||||
corresponding option definitions in all machines, returning them
|
||||
in the ‘value’ attribute of each option. */
|
||||
mergeModules = prefix: modules:
|
||||
mergeModules' prefix modules
|
||||
(concatMap (m: map (config: { inherit (m) file; inherit config; }) (pushDownProperties m.config)) modules);
|
||||
|
||||
mergeModules' = prefix: options: configs:
|
||||
let
|
||||
/* byName is like foldAttrs, but will look for attributes to merge in the
|
||||
specified attribute name.
|
||||
|
||||
byName "foo" (module: value: ["module.hidden=${module.hidden},value=${value}"])
|
||||
[
|
||||
{
|
||||
hidden="baz";
|
||||
foo={qux="bar"; gla="flop";};
|
||||
}
|
||||
{
|
||||
hidden="fli";
|
||||
foo={qux="gne"; gli="flip";};
|
||||
}
|
||||
]
|
||||
===>
|
||||
{
|
||||
gla = [ "module.hidden=baz,value=flop" ];
|
||||
gli = [ "module.hidden=fli,value=flip" ];
|
||||
qux = [ "module.hidden=baz,value=bar" "module.hidden=fli,value=gne" ];
|
||||
}
|
||||
*/
|
||||
byName = attr: f: modules:
|
||||
foldl' (acc: module:
|
||||
acc // (mapAttrs (n: v:
|
||||
(acc.${n} or []) ++ f module v
|
||||
) module.${attr}
|
||||
)
|
||||
) {} modules;
|
||||
# an attrset 'name' => list of submodules that declare ‘name’.
|
||||
declsByName = byName "options" (module: option:
|
||||
[{ inherit (module) file; options = option; }]
|
||||
) options;
|
||||
# an attrset 'name' => list of submodules that define ‘name’.
|
||||
defnsByName = byName "config" (module: value:
|
||||
map (config: { inherit (module) file; inherit config; }) (pushDownProperties value)
|
||||
) configs;
|
||||
# extract the definitions for each loc
|
||||
defnsByName' = byName "config" (module: value:
|
||||
[{ inherit (module) file; inherit value; }]
|
||||
) configs;
|
||||
in
|
||||
(flip mapAttrs declsByName (name: decls:
|
||||
# We're descending into attribute ‘name’.
|
||||
let
|
||||
loc = prefix ++ [name];
|
||||
defns = defnsByName.${name} or [];
|
||||
defns' = defnsByName'.${name} or [];
|
||||
nrOptions = count (m: isOption m.options) decls;
|
||||
in
|
||||
if nrOptions == length decls then
|
||||
let opt = fixupOptionType loc (mergeOptionDecls loc decls);
|
||||
in evalOptionValue loc opt defns'
|
||||
else if nrOptions != 0 then
|
||||
let
|
||||
firstOption = findFirst (m: isOption m.options) "" decls;
|
||||
firstNonOption = findFirst (m: !isOption m.options) "" decls;
|
||||
in
|
||||
throw "The option `${showOption loc}' in `${firstOption.file}' is a prefix of options in `${firstNonOption.file}'."
|
||||
else
|
||||
mergeModules' loc decls defns
|
||||
))
|
||||
// { _definedNames = map (m: { inherit (m) file; names = attrNames m.config; }) configs; };
|
||||
|
||||
/* Merge multiple option declarations into a single declaration. In
|
||||
general, there should be only one declaration of each option.
|
||||
The exception is the ‘options’ attribute, which specifies
|
||||
sub-options. These can be specified multiple times to allow one
|
||||
module to add sub-options to an option declared somewhere else
|
||||
(e.g. multiple modules define sub-options for ‘fileSystems’).
|
||||
|
||||
'loc' is the list of attribute names where the option is located.
|
||||
|
||||
'opts' is a list of modules. Each module has an options attribute which
|
||||
correspond to the definition of 'loc' in 'opt.file'. */
|
||||
mergeOptionDecls = loc: opts:
|
||||
foldl' (res: opt:
|
||||
let t = res.type;
|
||||
t' = opt.options.type;
|
||||
mergedType = t.typeMerge t'.functor;
|
||||
typesMergeable = mergedType != null;
|
||||
typeSet = if (bothHave "type") && typesMergeable
|
||||
then { type = mergedType; }
|
||||
else {};
|
||||
bothHave = k: opt.options ? ${k} && res ? ${k};
|
||||
in
|
||||
if bothHave "default" ||
|
||||
bothHave "example" ||
|
||||
bothHave "description" ||
|
||||
bothHave "apply" ||
|
||||
(bothHave "type" && (! typesMergeable))
|
||||
then
|
||||
throw "The option `${showOption loc}' in `${opt.file}' is already declared in ${showFiles res.declarations}."
|
||||
else
|
||||
let
|
||||
/* Add the modules of the current option to the list of modules
|
||||
already collected. The options attribute except either a list of
|
||||
submodules or a submodule. For each submodule, we add the file of the
|
||||
current option declaration as the file use for the submodule. If the
|
||||
submodule defines any filename, then we ignore the enclosing option file. */
|
||||
options' = toList opt.options.options;
|
||||
coerceOption = file: opt:
|
||||
if isFunction opt then packSubmodule file opt
|
||||
else packSubmodule file { options = opt; };
|
||||
getSubModules = opt.options.type.getSubModules or null;
|
||||
submodules =
|
||||
if getSubModules != null then map (packSubmodule opt.file) getSubModules ++ res.options
|
||||
else if opt.options ? options then map (coerceOption opt.file) options' ++ res.options
|
||||
else res.options;
|
||||
in opt.options // res //
|
||||
{ declarations = res.declarations ++ [opt.file];
|
||||
options = submodules;
|
||||
} // typeSet
|
||||
) { inherit loc; declarations = []; options = []; } opts;
|
||||
|
||||
/* Merge all the definitions of an option to produce the final
|
||||
config value. */
|
||||
evalOptionValue = loc: opt: defs:
|
||||
let
|
||||
# Add in the default value for this option, if any.
|
||||
defs' =
|
||||
(optional (opt ? default)
|
||||
{ file = head opt.declarations; value = mkOptionDefault opt.default; }) ++ defs;
|
||||
|
||||
# Handle properties, check types, and merge everything together.
|
||||
res =
|
||||
if opt.readOnly or false && length defs' > 1 then
|
||||
throw "The option `${showOption loc}' is read-only, but it's set multiple times."
|
||||
else
|
||||
mergeDefinitions loc opt.type defs';
|
||||
|
||||
# Check whether the option is defined, and apply the ‘apply’
|
||||
# function to the merged value. This allows options to yield a
|
||||
# value computed from the definitions.
|
||||
value =
|
||||
if !res.isDefined then
|
||||
throw "The option `${showOption loc}' is used but not defined."
|
||||
else if opt ? apply then
|
||||
opt.apply res.mergedValue
|
||||
else
|
||||
res.mergedValue;
|
||||
|
||||
in opt //
|
||||
{ value = builtins.addErrorContext "while evaluating the option `${showOption loc}':" value;
|
||||
inherit (res.defsFinal') highestPrio;
|
||||
definitions = map (def: def.value) res.defsFinal;
|
||||
files = map (def: def.file) res.defsFinal;
|
||||
inherit (res) isDefined;
|
||||
};
|
||||
|
||||
# Merge definitions of a value of a given type.
|
||||
mergeDefinitions = loc: type: defs: rec {
|
||||
defsFinal' =
|
||||
let
|
||||
# Process mkMerge and mkIf properties.
|
||||
defs' = concatMap (m:
|
||||
map (value: { inherit (m) file; inherit value; }) (dischargeProperties m.value)
|
||||
) defs;
|
||||
|
||||
# Process mkOverride properties.
|
||||
defs'' = filterOverrides' defs';
|
||||
|
||||
# Sort mkOrder properties.
|
||||
defs''' =
|
||||
# Avoid sorting if we don't have to.
|
||||
if any (def: def.value._type or "" == "order") defs''.values
|
||||
then sortProperties defs''.values
|
||||
else defs''.values;
|
||||
in {
|
||||
values = defs''';
|
||||
inherit (defs'') highestPrio;
|
||||
};
|
||||
defsFinal = defsFinal'.values;
|
||||
|
||||
# Type-check the remaining definitions, and merge them.
|
||||
mergedValue = foldl' (res: def:
|
||||
if type.check def.value then res
|
||||
else throw "The option value `${showOption loc}' in `${def.file}' is not of type `${type.description}'.")
|
||||
(type.merge loc defsFinal) defsFinal;
|
||||
|
||||
isDefined = defsFinal != [];
|
||||
|
||||
optionalValue =
|
||||
if isDefined then { value = mergedValue; }
|
||||
else {};
|
||||
};
|
||||
|
||||
/* Given a config set, expand mkMerge properties, and push down the
|
||||
other properties into the children. The result is a list of
|
||||
config sets that do not have properties at top-level. For
|
||||
example,
|
||||
|
||||
mkMerge [ { boot = set1; } (mkIf cond { boot = set2; services = set3; }) ]
|
||||
|
||||
is transformed into
|
||||
|
||||
[ { boot = set1; } { boot = mkIf cond set2; services = mkIf cond set3; } ].
|
||||
|
||||
This transform is the critical step that allows mkIf conditions
|
||||
to refer to the full configuration without creating an infinite
|
||||
recursion.
|
||||
*/
|
||||
pushDownProperties = cfg:
|
||||
if cfg._type or "" == "merge" then
|
||||
concatMap pushDownProperties cfg.contents
|
||||
else if cfg._type or "" == "if" then
|
||||
map (mapAttrs (n: v: mkIf cfg.condition v)) (pushDownProperties cfg.content)
|
||||
else if cfg._type or "" == "override" then
|
||||
map (mapAttrs (n: v: mkOverride cfg.priority v)) (pushDownProperties cfg.content)
|
||||
else # FIXME: handle mkOrder?
|
||||
[ cfg ];
|
||||
|
||||
/* Given a config value, expand mkMerge properties, and discharge
|
||||
any mkIf conditions. That is, this is the place where mkIf
|
||||
conditions are actually evaluated. The result is a list of
|
||||
config values. For example, ‘mkIf false x’ yields ‘[]’,
|
||||
‘mkIf true x’ yields ‘[x]’, and
|
||||
|
||||
mkMerge [ 1 (mkIf true 2) (mkIf true (mkIf false 3)) ]
|
||||
|
||||
yields ‘[ 1 2 ]’.
|
||||
*/
|
||||
dischargeProperties = def:
|
||||
if def._type or "" == "merge" then
|
||||
concatMap dischargeProperties def.contents
|
||||
else if def._type or "" == "if" then
|
||||
if isBool def.condition then
|
||||
if def.condition then
|
||||
dischargeProperties def.content
|
||||
else
|
||||
[ ]
|
||||
else
|
||||
throw "‘mkIf’ called with a non-Boolean condition"
|
||||
else
|
||||
[ def ];
|
||||
|
||||
/* Given a list of config values, process the mkOverride properties,
|
||||
that is, return the values that have the highest (that is,
|
||||
numerically lowest) priority, and strip the mkOverride
|
||||
properties. For example,
|
||||
|
||||
[ { file = "/1"; value = mkOverride 10 "a"; }
|
||||
{ file = "/2"; value = mkOverride 20 "b"; }
|
||||
{ file = "/3"; value = "z"; }
|
||||
{ file = "/4"; value = mkOverride 10 "d"; }
|
||||
]
|
||||
|
||||
yields
|
||||
|
||||
[ { file = "/1"; value = "a"; }
|
||||
{ file = "/4"; value = "d"; }
|
||||
]
|
||||
|
||||
Note that "z" has the default priority 100.
|
||||
*/
|
||||
filterOverrides = defs: (filterOverrides' defs).values;
|
||||
|
||||
filterOverrides' = defs:
|
||||
let
|
||||
getPrio = def: if def.value._type or "" == "override" then def.value.priority else defaultPriority;
|
||||
highestPrio = foldl' (prio: def: min (getPrio def) prio) 9999 defs;
|
||||
strip = def: if def.value._type or "" == "override" then def // { value = def.value.content; } else def;
|
||||
in {
|
||||
values = concatMap (def: if getPrio def == highestPrio then [(strip def)] else []) defs;
|
||||
inherit highestPrio;
|
||||
};
|
||||
|
||||
/* Sort a list of properties. The sort priority of a property is
|
||||
1000 by default, but can be overridden by wrapping the property
|
||||
using mkOrder. */
|
||||
sortProperties = defs:
|
||||
let
|
||||
strip = def:
|
||||
if def.value._type or "" == "order"
|
||||
then def // { value = def.value.content; inherit (def.value) priority; }
|
||||
else def;
|
||||
defs' = map strip defs;
|
||||
compare = a: b: (a.priority or 1000) < (b.priority or 1000);
|
||||
in sort compare defs';
|
||||
|
||||
/* Hack for backward compatibility: convert options of type
|
||||
optionSet to options of type submodule. FIXME: remove
|
||||
eventually. */
|
||||
fixupOptionType = loc: opt:
|
||||
let
|
||||
options = opt.options or
|
||||
(throw "Option `${showOption loc'}' has type optionSet but has no option attribute, in ${showFiles opt.declarations}.");
|
||||
f = tp:
|
||||
let optionSetIn = type: (tp.name == type) && (tp.functor.wrapped.name == "optionSet");
|
||||
in
|
||||
if tp.name == "option set" || tp.name == "submodule" then
|
||||
throw "The option ${showOption loc} uses submodules without a wrapping type, in ${showFiles opt.declarations}."
|
||||
else if optionSetIn "attrsOf" then types.attrsOf (types.submodule options)
|
||||
else if optionSetIn "loaOf" then types.loaOf (types.submodule options)
|
||||
else if optionSetIn "listOf" then types.listOf (types.submodule options)
|
||||
else if optionSetIn "nullOr" then types.nullOr (types.submodule options)
|
||||
else tp;
|
||||
in
|
||||
if opt.type.getSubModules or null == null
|
||||
then opt // { type = f (opt.type or types.unspecified); }
|
||||
else opt // { type = opt.type.substSubModules opt.options; options = []; };
|
||||
|
||||
|
||||
/* Properties. */
|
||||
|
||||
mkIf = condition: content:
|
||||
{ _type = "if";
|
||||
inherit condition content;
|
||||
};
|
||||
|
||||
mkAssert = assertion: message: content:
|
||||
mkIf
|
||||
(if assertion then true else throw "\nFailed assertion: ${message}")
|
||||
content;
|
||||
|
||||
mkMerge = contents:
|
||||
{ _type = "merge";
|
||||
inherit contents;
|
||||
};
|
||||
|
||||
mkOverride = priority: content:
|
||||
{ _type = "override";
|
||||
inherit priority content;
|
||||
};
|
||||
|
||||
mkOptionDefault = mkOverride 1500; # priority of option defaults
|
||||
mkDefault = mkOverride 1000; # used in config sections of non-user modules to set a default
|
||||
mkForce = mkOverride 50;
|
||||
mkVMOverride = mkOverride 10; # used by ‘nixos-rebuild build-vm’
|
||||
|
||||
mkStrict = builtins.trace "`mkStrict' is obsolete; use `mkOverride 0' instead." (mkOverride 0);
|
||||
|
||||
mkFixStrictness = id; # obsolete, no-op
|
||||
|
||||
mkOrder = priority: content:
|
||||
{ _type = "order";
|
||||
inherit priority content;
|
||||
};
|
||||
|
||||
mkBefore = mkOrder 500;
|
||||
mkAfter = mkOrder 1500;
|
||||
|
||||
# The default priority for things that don't have a priority specified.
|
||||
defaultPriority = 100;
|
||||
|
||||
# Convenient property used to transfer all definitions and their
|
||||
# properties from one option to another. This property is useful for
|
||||
# renaming options, and also for including properties from another module
|
||||
# system, including sub-modules.
|
||||
#
|
||||
# { config, options, ... }:
|
||||
#
|
||||
# {
|
||||
# # 'bar' might not always be defined in the current module-set.
|
||||
# config.foo.enable = mkAliasDefinitions (options.bar.enable or {});
|
||||
#
|
||||
# # 'barbaz' has to be defined in the current module-set.
|
||||
# config.foobar.paths = mkAliasDefinitions options.barbaz.paths;
|
||||
# }
|
||||
#
|
||||
# Note, this is different than taking the value of the option and using it
|
||||
# as a definition, as the new definition will not keep the mkOverride /
|
||||
# mkDefault properties of the previous option.
|
||||
#
|
||||
mkAliasDefinitions = mkAliasAndWrapDefinitions id;
|
||||
mkAliasAndWrapDefinitions = wrap: option:
|
||||
mkAliasIfDef option (wrap (mkMerge option.definitions));
|
||||
|
||||
# Similar to mkAliasAndWrapDefinitions but copies over the priority from the
|
||||
# option as well.
|
||||
#
|
||||
# If a priority is not set, it assumes a priority of defaultPriority.
|
||||
mkAliasAndWrapDefsWithPriority = wrap: option:
|
||||
let
|
||||
prio = option.highestPrio or defaultPriority;
|
||||
defsWithPrio = map (mkOverride prio) option.definitions;
|
||||
in mkAliasIfDef option (wrap (mkMerge defsWithPrio));
|
||||
|
||||
mkAliasIfDef = option:
|
||||
mkIf (isOption option && option.isDefined);
|
||||
|
||||
/* Compatibility. */
|
||||
fixMergeModules = modules: args: evalModules { inherit modules args; check = false; };
|
||||
|
||||
|
||||
/* Return a module that causes a warning to be shown if the
|
||||
specified option is defined. For example,
|
||||
|
||||
mkRemovedOptionModule [ "boot" "loader" "grub" "bootDevice" ] "<replacement instructions>"
|
||||
|
||||
causes a warning if the user defines boot.loader.grub.bootDevice.
|
||||
|
||||
replacementInstructions is a string that provides instructions on
|
||||
how to achieve the same functionality without the removed option,
|
||||
or alternatively a reasoning why the functionality is not needed.
|
||||
replacementInstructions SHOULD be provided!
|
||||
*/
|
||||
mkRemovedOptionModule = optionName: replacementInstructions:
|
||||
{ options, ... }:
|
||||
{ options = setAttrByPath optionName (mkOption {
|
||||
visible = false;
|
||||
});
|
||||
config.warnings =
|
||||
let opt = getAttrFromPath optionName options; in
|
||||
optional opt.isDefined ''
|
||||
The option definition `${showOption optionName}' in ${showFiles opt.files} no longer has any effect; please remove it.
|
||||
${replacementInstructions}'';
|
||||
};
|
||||
|
||||
/* Return a module that causes a warning to be shown if the
|
||||
specified "from" option is defined; the defined value is however
|
||||
forwarded to the "to" option. This can be used to rename options
|
||||
while providing backward compatibility. For example,
|
||||
|
||||
mkRenamedOptionModule [ "boot" "copyKernels" ] [ "boot" "loader" "grub" "copyKernels" ]
|
||||
|
||||
forwards any definitions of boot.copyKernels to
|
||||
boot.loader.grub.copyKernels while printing a warning.
|
||||
|
||||
This also copies over the priority from the aliased option to the
|
||||
non-aliased option.
|
||||
*/
|
||||
mkRenamedOptionModule = from: to: doRename {
|
||||
inherit from to;
|
||||
visible = false;
|
||||
warn = true;
|
||||
use = builtins.trace "Obsolete option `${showOption from}' is used. It was renamed to `${showOption to}'.";
|
||||
};
|
||||
|
||||
/* Return a module that causes a warning to be shown if any of the "from"
|
||||
option is defined; the defined values can be used in the "mergeFn" to set
|
||||
the "to" value.
|
||||
This function can be used to merge multiple options into one that has a
|
||||
different type.
|
||||
|
||||
"mergeFn" takes the module "config" as a parameter and must return a value
|
||||
of "to" option type.
|
||||
|
||||
mkMergedOptionModule
|
||||
[ [ "a" "b" "c" ]
|
||||
[ "d" "e" "f" ] ]
|
||||
[ "x" "y" "z" ]
|
||||
(config:
|
||||
let value = p: getAttrFromPath p config;
|
||||
in
|
||||
if (value [ "a" "b" "c" ]) == true then "foo"
|
||||
else if (value [ "d" "e" "f" ]) == true then "bar"
|
||||
else "baz")
|
||||
|
||||
- options.a.b.c is a removed boolean option
|
||||
- options.d.e.f is a removed boolean option
|
||||
- options.x.y.z is a new str option that combines a.b.c and d.e.f
|
||||
functionality
|
||||
|
||||
This show a warning if any a.b.c or d.e.f is set, and set the value of
|
||||
x.y.z to the result of the merge function
|
||||
*/
|
||||
mkMergedOptionModule = from: to: mergeFn:
|
||||
{ config, options, ... }:
|
||||
{
|
||||
options = foldl recursiveUpdate {} (map (path: setAttrByPath path (mkOption {
|
||||
visible = false;
|
||||
# To use the value in mergeFn without triggering errors
|
||||
default = "_mkMergedOptionModule";
|
||||
})) from);
|
||||
|
||||
config = {
|
||||
warnings = filter (x: x != "") (map (f:
|
||||
let val = getAttrFromPath f config;
|
||||
opt = getAttrFromPath f options;
|
||||
in
|
||||
optionalString
|
||||
(val != "_mkMergedOptionModule")
|
||||
"The option `${showOption f}' defined in ${showFiles opt.files} has been changed to `${showOption to}' that has a different type. Please read `${showOption to}' documentation and update your configuration accordingly."
|
||||
) from);
|
||||
} // setAttrByPath to (mkMerge
|
||||
(optional
|
||||
(any (f: (getAttrFromPath f config) != "_mkMergedOptionModule") from)
|
||||
(mergeFn config)));
|
||||
};
|
||||
|
||||
/* Single "from" version of mkMergedOptionModule.
|
||||
Return a module that causes a warning to be shown if the "from" option is
|
||||
defined; the defined value can be used in the "mergeFn" to set the "to"
|
||||
value.
|
||||
This function can be used to change an option into another that has a
|
||||
different type.
|
||||
|
||||
"mergeFn" takes the module "config" as a parameter and must return a value of
|
||||
"to" option type.
|
||||
|
||||
mkChangedOptionModule [ "a" "b" "c" ] [ "x" "y" "z" ]
|
||||
(config:
|
||||
let value = getAttrFromPath [ "a" "b" "c" ] config;
|
||||
in
|
||||
if value > 100 then "high"
|
||||
else "normal")
|
||||
|
||||
- options.a.b.c is a removed int option
|
||||
- options.x.y.z is a new str option that supersedes a.b.c
|
||||
|
||||
This show a warning if a.b.c is set, and set the value of x.y.z to the
|
||||
result of the change function
|
||||
*/
|
||||
mkChangedOptionModule = from: to: changeFn:
|
||||
mkMergedOptionModule [ from ] to changeFn;
|
||||
|
||||
/* Like ‘mkRenamedOptionModule’, but doesn't show a warning. */
|
||||
mkAliasOptionModule = from: to: doRename {
|
||||
inherit from to;
|
||||
visible = true;
|
||||
warn = false;
|
||||
use = id;
|
||||
};
|
||||
|
||||
doRename = { from, to, visible, warn, use, withPriority ? true }:
|
||||
{ config, options, ... }:
|
||||
let
|
||||
fromOpt = getAttrFromPath from options;
|
||||
toOf = attrByPath to
|
||||
(abort "Renaming error: option `${showOption to}' does not exist.");
|
||||
in
|
||||
{
|
||||
options = setAttrByPath from (mkOption {
|
||||
inherit visible;
|
||||
description = "Alias of <option>${showOption to}</option>.";
|
||||
apply = x: use (toOf config);
|
||||
});
|
||||
config = mkMerge [
|
||||
{
|
||||
warnings = optional (warn && fromOpt.isDefined)
|
||||
"The option `${showOption from}' defined in ${showFiles fromOpt.files} has been renamed to `${showOption to}'.";
|
||||
}
|
||||
(if withPriority
|
||||
then mkAliasAndWrapDefsWithPriority (setAttrByPath to) fromOpt
|
||||
else mkAliasAndWrapDefinitions (setAttrByPath to) fromOpt)
|
||||
];
|
||||
};
|
||||
|
||||
}
|
||||
207
lib/options.nix
207
lib/options.nix
@@ -1,207 +0,0 @@
|
||||
# Nixpkgs/NixOS option handling.
|
||||
{ lib }:
|
||||
|
||||
with lib.trivial;
|
||||
with lib.lists;
|
||||
with lib.attrsets;
|
||||
with lib.strings;
|
||||
|
||||
rec {
|
||||
|
||||
/* Returns true when the given argument is an option
|
||||
|
||||
Type: isOption :: a -> bool
|
||||
|
||||
Example:
|
||||
isOption 1 // => false
|
||||
isOption (mkOption {}) // => true
|
||||
*/
|
||||
isOption = lib.isType "option";
|
||||
|
||||
/* Creates an Option attribute set. mkOption accepts an attribute set with the following keys:
|
||||
|
||||
All keys default to `null` when not given.
|
||||
|
||||
Example:
|
||||
mkOption { } // => { _type = "option"; }
|
||||
mkOption { defaultText = "foo"; } // => { _type = "option"; defaultText = "foo"; }
|
||||
*/
|
||||
mkOption =
|
||||
{
|
||||
# Default value used when no definition is given in the configuration.
|
||||
default ? null,
|
||||
# Textual representation of the default, for the manual.
|
||||
defaultText ? null,
|
||||
# Example value used in the manual.
|
||||
example ? null,
|
||||
# String describing the option.
|
||||
description ? null,
|
||||
# Related packages used in the manual (see `genRelatedPackages` in ../nixos/doc/manual/default.nix).
|
||||
relatedPackages ? null,
|
||||
# Option type, providing type-checking and value merging.
|
||||
type ? null,
|
||||
# Function that converts the option value to something else.
|
||||
apply ? null,
|
||||
# Whether the option is for NixOS developers only.
|
||||
internal ? null,
|
||||
# Whether the option shows up in the manual.
|
||||
visible ? null,
|
||||
# Whether the option can be set only once
|
||||
readOnly ? null,
|
||||
# Deprecated, used by types.optionSet.
|
||||
options ? null
|
||||
} @ attrs:
|
||||
attrs // { _type = "option"; };
|
||||
|
||||
/* Creates an Option attribute set for a boolean value option i.e an
|
||||
option to be toggled on or off:
|
||||
|
||||
Example:
|
||||
mkEnableOption "foo"
|
||||
=> { _type = "option"; default = false; description = "Whether to enable foo."; example = true; type = { ... }; }
|
||||
*/
|
||||
mkEnableOption =
|
||||
# Name for the created option
|
||||
name: mkOption {
|
||||
default = false;
|
||||
example = true;
|
||||
description = "Whether to enable ${name}.";
|
||||
type = lib.types.bool;
|
||||
};
|
||||
|
||||
/* This option accepts anything, but it does not produce any result.
|
||||
|
||||
This is useful for sharing a module across different module sets
|
||||
without having to implement similar features as long as the
|
||||
values of the options are not accessed. */
|
||||
mkSinkUndeclaredOptions = attrs: mkOption ({
|
||||
internal = true;
|
||||
visible = false;
|
||||
default = false;
|
||||
description = "Sink for option definitions.";
|
||||
type = mkOptionType {
|
||||
name = "sink";
|
||||
check = x: true;
|
||||
merge = loc: defs: false;
|
||||
};
|
||||
apply = x: throw "Option value is not readable because the option is not declared.";
|
||||
} // attrs);
|
||||
|
||||
mergeDefaultOption = loc: defs:
|
||||
let list = getValues defs; in
|
||||
if length list == 1 then head list
|
||||
else if all isFunction list then x: mergeDefaultOption loc (map (f: f x) list)
|
||||
else if all isList list then concatLists list
|
||||
else if all isAttrs list then foldl' lib.mergeAttrs {} list
|
||||
else if all isBool list then foldl' lib.or false list
|
||||
else if all isString list then lib.concatStrings list
|
||||
else if all isInt list && all (x: x == head list) list then head list
|
||||
else throw "Cannot merge definitions of `${showOption loc}' given in ${showFiles (getFiles defs)}.";
|
||||
|
||||
mergeOneOption = loc: defs:
|
||||
if defs == [] then abort "This case should never happen."
|
||||
else if length defs != 1 then
|
||||
throw "The unique option `${showOption loc}' is defined multiple times, in ${showFiles (getFiles defs)}."
|
||||
else (head defs).value;
|
||||
|
||||
/* "Merge" option definitions by checking that they all have the same value. */
|
||||
mergeEqualOption = loc: defs:
|
||||
if defs == [] then abort "This case should never happen."
|
||||
else foldl' (val: def:
|
||||
if def.value != val then
|
||||
throw "The option `${showOption loc}' has conflicting definitions, in ${showFiles (getFiles defs)}."
|
||||
else
|
||||
val) (head defs).value defs;
|
||||
|
||||
/* Extracts values of all "value" keys of the given list.
|
||||
|
||||
Type: getValues :: [ { value :: a } ] -> [a]
|
||||
|
||||
Example:
|
||||
getValues [ { value = 1; } { value = 2; } ] // => [ 1 2 ]
|
||||
getValues [ ] // => [ ]
|
||||
*/
|
||||
getValues = map (x: x.value);
|
||||
|
||||
/* Extracts values of all "file" keys of the given list
|
||||
|
||||
Type: getFiles :: [ { file :: a } ] -> [a]
|
||||
|
||||
Example:
|
||||
getFiles [ { file = "file1"; } { file = "file2"; } ] // => [ "file1" "file2" ]
|
||||
getFiles [ ] // => [ ]
|
||||
*/
|
||||
getFiles = map (x: x.file);
|
||||
|
||||
# Generate documentation template from the list of option declaration like
|
||||
# the set generated with filterOptionSets.
|
||||
optionAttrSetToDocList = optionAttrSetToDocList' [];
|
||||
|
||||
optionAttrSetToDocList' = prefix: options:
|
||||
concatMap (opt:
|
||||
let
|
||||
docOption = rec {
|
||||
loc = opt.loc;
|
||||
name = showOption opt.loc;
|
||||
description = opt.description or (throw "Option `${name}' has no description.");
|
||||
declarations = filter (x: x != unknownModule) opt.declarations;
|
||||
internal = opt.internal or false;
|
||||
visible = opt.visible or true;
|
||||
readOnly = opt.readOnly or false;
|
||||
type = opt.type.description or null;
|
||||
}
|
||||
// optionalAttrs (opt ? example) { example = scrubOptionValue opt.example; }
|
||||
// optionalAttrs (opt ? default) { default = scrubOptionValue opt.default; }
|
||||
// optionalAttrs (opt ? defaultText) { default = opt.defaultText; }
|
||||
// optionalAttrs (opt ? relatedPackages && opt.relatedPackages != null) { inherit (opt) relatedPackages; };
|
||||
|
||||
subOptions =
|
||||
let ss = opt.type.getSubOptions opt.loc;
|
||||
in if ss != {} then optionAttrSetToDocList' opt.loc ss else [];
|
||||
in
|
||||
[ docOption ] ++ subOptions) (collect isOption options);
|
||||
|
||||
|
||||
/* This function recursively removes all derivation attributes from
|
||||
`x` except for the `name` attribute.
|
||||
|
||||
This is to make the generation of `options.xml` much more
|
||||
efficient: the XML representation of derivations is very large
|
||||
(on the order of megabytes) and is not actually used by the
|
||||
manual generator.
|
||||
*/
|
||||
scrubOptionValue = x:
|
||||
if isDerivation x then
|
||||
{ type = "derivation"; drvPath = x.name; outPath = x.name; name = x.name; }
|
||||
else if isList x then map scrubOptionValue x
|
||||
else if isAttrs x then mapAttrs (n: v: scrubOptionValue v) (removeAttrs x ["_args"])
|
||||
else x;
|
||||
|
||||
|
||||
/* For use in the `example` option attribute. It causes the given
|
||||
text to be included verbatim in documentation. This is necessary
|
||||
for example values that are not simple values, e.g., functions.
|
||||
*/
|
||||
literalExample = text: { _type = "literalExample"; inherit text; };
|
||||
|
||||
# Helper functions.
|
||||
|
||||
/* Convert an option, described as a list of the option parts in to a
|
||||
safe, human readable version.
|
||||
|
||||
Example:
|
||||
(showOption ["foo" "bar" "baz"]) == "foo.bar.baz"
|
||||
(showOption ["foo" "bar.baz" "tux"]) == "foo.\"bar.baz\".tux"
|
||||
*/
|
||||
showOption = parts: let
|
||||
escapeOptionPart = part:
|
||||
let
|
||||
escaped = lib.strings.escapeNixString part;
|
||||
in if escaped == "\"${part}\""
|
||||
then part
|
||||
else escaped;
|
||||
in (concatStringsSep ".") (map escapeOptionPart parts);
|
||||
showFiles = files: concatStringsSep " and " (map (f: "`${f}'") files);
|
||||
unknownModule = "<unknown-file>";
|
||||
|
||||
}
|
||||
104
lib/sources.nix
104
lib/sources.nix
@@ -1,104 +0,0 @@
|
||||
# Functions for copying sources to the Nix store.
|
||||
{ lib }:
|
||||
|
||||
rec {
|
||||
|
||||
# Returns the type of a path: regular (for file), symlink, or directory
|
||||
pathType = p: with builtins; getAttr (baseNameOf p) (readDir (dirOf p));
|
||||
|
||||
# Returns true if the path exists and is a directory, false otherwise
|
||||
pathIsDirectory = p: if builtins.pathExists p then (pathType p) == "directory" else false;
|
||||
|
||||
# Bring in a path as a source, filtering out all Subversion and CVS
|
||||
# directories, as well as backup files (*~).
|
||||
cleanSourceFilter = name: type: let baseName = baseNameOf (toString name); in ! (
|
||||
# Filter out Subversion and CVS directories.
|
||||
(type == "directory" && (baseName == ".git" || baseName == ".svn" || baseName == "CVS" || baseName == ".hg")) ||
|
||||
# Filter out editor backup / swap files.
|
||||
lib.hasSuffix "~" baseName ||
|
||||
builtins.match "^\\.sw[a-z]$" baseName != null ||
|
||||
builtins.match "^\\..*\\.sw[a-z]$" baseName != null ||
|
||||
|
||||
# Filter out generates files.
|
||||
lib.hasSuffix ".o" baseName ||
|
||||
lib.hasSuffix ".so" baseName ||
|
||||
# Filter out nix-build result symlinks
|
||||
(type == "symlink" && lib.hasPrefix "result" baseName)
|
||||
);
|
||||
|
||||
# Filters a source tree removing version control files and directories using cleanSourceWith
|
||||
#
|
||||
# Example:
|
||||
# cleanSource ./.
|
||||
cleanSource = src: cleanSourceWith { filter = cleanSourceFilter; inherit src; };
|
||||
|
||||
# Like `builtins.filterSource`, except it will compose with itself,
|
||||
# allowing you to chain multiple calls together without any
|
||||
# intermediate copies being put in the nix store.
|
||||
#
|
||||
# lib.cleanSourceWith f (lib.cleanSourceWith g ./.) # Succeeds!
|
||||
# builtins.filterSource f (builtins.filterSource g ./.) # Fails!
|
||||
cleanSourceWith = { filter, src }:
|
||||
let
|
||||
isFiltered = src ? _isLibCleanSourceWith;
|
||||
origSrc = if isFiltered then src.origSrc else src;
|
||||
filter' = if isFiltered then name: type: filter name type && src.filter name type else filter;
|
||||
in {
|
||||
inherit origSrc;
|
||||
filter = filter';
|
||||
outPath = builtins.filterSource filter' origSrc;
|
||||
_isLibCleanSourceWith = true;
|
||||
};
|
||||
|
||||
# Filter sources by a list of regular expressions.
|
||||
#
|
||||
# E.g. `src = sourceByRegex ./my-subproject [".*\.py$" "^database.sql$"]`
|
||||
sourceByRegex = src: regexes: cleanSourceWith {
|
||||
filter = (path: type:
|
||||
let relPath = lib.removePrefix (toString src + "/") (toString path);
|
||||
in lib.any (re: builtins.match re relPath != null) regexes);
|
||||
inherit src;
|
||||
};
|
||||
|
||||
# Get all files ending with the specified suffices from the given
|
||||
# directory or its descendants. E.g. `sourceFilesBySuffices ./dir
|
||||
# [".xml" ".c"]'.
|
||||
sourceFilesBySuffices = path: exts:
|
||||
let filter = name: type:
|
||||
let base = baseNameOf (toString name);
|
||||
in type == "directory" || lib.any (ext: lib.hasSuffix ext base) exts;
|
||||
in cleanSourceWith { inherit filter; src = path; };
|
||||
|
||||
|
||||
# Get the commit id of a git repo
|
||||
# Example: commitIdFromGitRepo <nixpkgs/.git>
|
||||
commitIdFromGitRepo =
|
||||
let readCommitFromFile = file: path:
|
||||
with builtins;
|
||||
let fileName = toString path + "/" + file;
|
||||
packedRefsName = toString path + "/packed-refs";
|
||||
in if lib.pathExists fileName
|
||||
then
|
||||
let fileContent = lib.fileContents fileName;
|
||||
# Sometimes git stores the commitId directly in the file but
|
||||
# sometimes it stores something like: «ref: refs/heads/branch-name»
|
||||
matchRef = match "^ref: (.*)$" fileContent;
|
||||
in if isNull matchRef
|
||||
then fileContent
|
||||
else readCommitFromFile (lib.head matchRef) path
|
||||
# Sometimes, the file isn't there at all and has been packed away in the
|
||||
# packed-refs file, so we have to grep through it:
|
||||
else if lib.pathExists packedRefsName
|
||||
then
|
||||
let fileContent = readFile packedRefsName;
|
||||
matchRef = match (".*\n([^\n ]*) " + file + "\n.*") fileContent;
|
||||
in if isNull matchRef
|
||||
then throw ("Could not find " + file + " in " + packedRefsName)
|
||||
else lib.head matchRef
|
||||
else throw ("Not a .git directory: " + path);
|
||||
in readCommitFromFile "HEAD";
|
||||
|
||||
pathHasContext = builtins.hasContext or (lib.hasPrefix builtins.storeDir);
|
||||
|
||||
canCleanSource = src: src ? _isLibCleanSourceWith || !(pathHasContext (toString src));
|
||||
}
|
||||
@@ -1,79 +0,0 @@
|
||||
{ lib }:
|
||||
/*
|
||||
Usage:
|
||||
|
||||
You define you custom builder script by adding all build steps to a list.
|
||||
for example:
|
||||
builder = writeScript "fsg-4.4-builder"
|
||||
(textClosure [doUnpack addInputs preBuild doMake installPhase doForceShare]);
|
||||
|
||||
a step is defined by noDepEntry, fullDepEntry or packEntry.
|
||||
To ensure that prerequisite are met those are added before the task itself by
|
||||
textClosureDupList. Duplicated items are removed again.
|
||||
|
||||
See trace/nixpkgs/trunk/pkgs/top-level/builder-defs.nix for some predefined build steps
|
||||
|
||||
Attention:
|
||||
|
||||
let
|
||||
pkgs = (import <nixpkgs>) {};
|
||||
in let
|
||||
inherit (pkgs.stringsWithDeps) fullDepEntry packEntry noDepEntry textClosureMap;
|
||||
inherit (pkgs.lib) id;
|
||||
|
||||
nameA = noDepEntry "Text a";
|
||||
nameB = fullDepEntry "Text b" ["nameA"];
|
||||
nameC = fullDepEntry "Text c" ["nameA"];
|
||||
|
||||
stages = {
|
||||
nameHeader = noDepEntry "#! /bin/sh \n";
|
||||
inherit nameA nameB nameC;
|
||||
};
|
||||
in
|
||||
textClosureMap id stages
|
||||
[ "nameHeader" "nameA" "nameB" "nameC"
|
||||
nameC # <- added twice. add a dep entry if you know that it will be added once only [1]
|
||||
"nameB" # <- this will not be added again because the attr name (reference) is used
|
||||
]
|
||||
|
||||
# result: Str("#! /bin/sh \n\nText a\nText b\nText c\nText c",[])
|
||||
|
||||
[1] maybe this behaviour should be removed to keep things simple (?)
|
||||
*/
|
||||
|
||||
with lib.lists;
|
||||
with lib.attrsets;
|
||||
with lib.strings;
|
||||
|
||||
rec {
|
||||
|
||||
/* !!! The interface of this function is kind of messed up, since
|
||||
it's way too overloaded and almost but not quite computes a
|
||||
topological sort of the depstrings. */
|
||||
|
||||
textClosureList = predefined: arg:
|
||||
let
|
||||
f = done: todo:
|
||||
if todo == [] then {result = []; inherit done;}
|
||||
else
|
||||
let entry = head todo; in
|
||||
if isAttrs entry then
|
||||
let x = f done entry.deps;
|
||||
y = f x.done (tail todo);
|
||||
in { result = x.result ++ [entry.text] ++ y.result;
|
||||
done = y.done;
|
||||
}
|
||||
else if done ? ${entry} then f done (tail todo)
|
||||
else f (done // listToAttrs [{name = entry; value = 1;}]) ([predefined.${entry}] ++ tail todo);
|
||||
in (f {} arg).result;
|
||||
|
||||
textClosureMap = f: predefined: names:
|
||||
concatStringsSep "\n" (map f (textClosureList predefined names));
|
||||
|
||||
noDepEntry = text: {inherit text; deps = [];};
|
||||
fullDepEntry = text: deps: {inherit text deps;};
|
||||
packEntry = deps: {inherit deps; text="";};
|
||||
|
||||
stringAfter = deps: text: { inherit text deps; };
|
||||
|
||||
}
|
||||
664
lib/strings.nix
664
lib/strings.nix
@@ -1,664 +0,0 @@
|
||||
/* String manipulation functions. */
|
||||
{ lib }:
|
||||
let
|
||||
|
||||
inherit (builtins) length;
|
||||
|
||||
in
|
||||
|
||||
rec {
|
||||
|
||||
inherit (builtins) stringLength substring head tail isString replaceStrings;
|
||||
|
||||
/* Concatenate a list of strings.
|
||||
|
||||
Type: concatStrings :: [string] -> string
|
||||
|
||||
Example:
|
||||
concatStrings ["foo" "bar"]
|
||||
=> "foobar"
|
||||
*/
|
||||
concatStrings = builtins.concatStringsSep "";
|
||||
|
||||
/* Map a function over a list and concatenate the resulting strings.
|
||||
|
||||
Type: concatMapStrings :: (a -> string) -> [a] -> string
|
||||
|
||||
Example:
|
||||
concatMapStrings (x: "a" + x) ["foo" "bar"]
|
||||
=> "afooabar"
|
||||
*/
|
||||
concatMapStrings = f: list: concatStrings (map f list);
|
||||
|
||||
/* Like `concatMapStrings` except that the f functions also gets the
|
||||
position as a parameter.
|
||||
|
||||
Type: concatImapStrings :: (int -> a -> string) -> [a] -> string
|
||||
|
||||
Example:
|
||||
concatImapStrings (pos: x: "${toString pos}-${x}") ["foo" "bar"]
|
||||
=> "1-foo2-bar"
|
||||
*/
|
||||
concatImapStrings = f: list: concatStrings (lib.imap1 f list);
|
||||
|
||||
/* Place an element between each element of a list
|
||||
|
||||
Type: intersperse :: a -> [a] -> [a]
|
||||
|
||||
Example:
|
||||
intersperse "/" ["usr" "local" "bin"]
|
||||
=> ["usr" "/" "local" "/" "bin"].
|
||||
*/
|
||||
intersperse =
|
||||
# Separator to add between elements
|
||||
separator:
|
||||
# Input list
|
||||
list:
|
||||
if list == [] || length list == 1
|
||||
then list
|
||||
else tail (lib.concatMap (x: [separator x]) list);
|
||||
|
||||
/* Concatenate a list of strings with a separator between each element
|
||||
|
||||
Type: concatStringsSep :: string -> [string] -> string
|
||||
|
||||
Example:
|
||||
concatStringsSep "/" ["usr" "local" "bin"]
|
||||
=> "usr/local/bin"
|
||||
*/
|
||||
concatStringsSep = builtins.concatStringsSep or (separator: list:
|
||||
concatStrings (intersperse separator list));
|
||||
|
||||
/* Maps a function over a list of strings and then concatenates the
|
||||
result with the specified separator interspersed between
|
||||
elements.
|
||||
|
||||
Type: concatMapStringsSep :: string -> (string -> string) -> [string] -> string
|
||||
|
||||
Example:
|
||||
concatMapStringsSep "-" (x: toUpper x) ["foo" "bar" "baz"]
|
||||
=> "FOO-BAR-BAZ"
|
||||
*/
|
||||
concatMapStringsSep =
|
||||
# Separator to add between elements
|
||||
sep:
|
||||
# Function to map over the list
|
||||
f:
|
||||
# List of input strings
|
||||
list: concatStringsSep sep (map f list);
|
||||
|
||||
/* Same as `concatMapStringsSep`, but the mapping function
|
||||
additionally receives the position of its argument.
|
||||
|
||||
Type: concatMapStringsSep :: string -> (int -> string -> string) -> [string] -> string
|
||||
|
||||
Example:
|
||||
concatImapStringsSep "-" (pos: x: toString (x / pos)) [ 6 6 6 ]
|
||||
=> "6-3-2"
|
||||
*/
|
||||
concatImapStringsSep =
|
||||
# Separator to add between elements
|
||||
sep:
|
||||
# Function that receives elements and their positions
|
||||
f:
|
||||
# List of input strings
|
||||
list: concatStringsSep sep (lib.imap1 f list);
|
||||
|
||||
/* Construct a Unix-style, colon-separated search path consisting of
|
||||
the given `subDir` appended to each of the given paths.
|
||||
|
||||
Type: makeSearchPath :: string -> [string] -> string
|
||||
|
||||
Example:
|
||||
makeSearchPath "bin" ["/root" "/usr" "/usr/local"]
|
||||
=> "/root/bin:/usr/bin:/usr/local/bin"
|
||||
makeSearchPath "bin" [""]
|
||||
=> "/bin"
|
||||
*/
|
||||
makeSearchPath =
|
||||
# Directory name to append
|
||||
subDir:
|
||||
# List of base paths
|
||||
paths:
|
||||
concatStringsSep ":" (map (path: path + "/" + subDir) (builtins.filter (x: x != null) paths));
|
||||
|
||||
/* Construct a Unix-style search path by appending the given
|
||||
`subDir` to the specified `output` of each of the packages. If no
|
||||
output by the given name is found, fallback to `.out` and then to
|
||||
the default.
|
||||
|
||||
Type: string -> string -> [package] -> string
|
||||
|
||||
Example:
|
||||
makeSearchPathOutput "dev" "bin" [ pkgs.openssl pkgs.zlib ]
|
||||
=> "/nix/store/9rz8gxhzf8sw4kf2j2f1grr49w8zx5vj-openssl-1.0.1r-dev/bin:/nix/store/wwh7mhwh269sfjkm6k5665b5kgp7jrk2-zlib-1.2.8/bin"
|
||||
*/
|
||||
makeSearchPathOutput =
|
||||
# Package output to use
|
||||
output:
|
||||
# Directory name to append
|
||||
subDir:
|
||||
# List of packages
|
||||
pkgs: makeSearchPath subDir (map (lib.getOutput output) pkgs);
|
||||
|
||||
/* Construct a library search path (such as RPATH) containing the
|
||||
libraries for a set of packages
|
||||
|
||||
Example:
|
||||
makeLibraryPath [ "/usr" "/usr/local" ]
|
||||
=> "/usr/lib:/usr/local/lib"
|
||||
pkgs = import <nixpkgs> { }
|
||||
makeLibraryPath [ pkgs.openssl pkgs.zlib ]
|
||||
=> "/nix/store/9rz8gxhzf8sw4kf2j2f1grr49w8zx5vj-openssl-1.0.1r/lib:/nix/store/wwh7mhwh269sfjkm6k5665b5kgp7jrk2-zlib-1.2.8/lib"
|
||||
*/
|
||||
makeLibraryPath = makeSearchPathOutput "lib" "lib";
|
||||
|
||||
/* Construct a binary search path (such as $PATH) containing the
|
||||
binaries for a set of packages.
|
||||
|
||||
Example:
|
||||
makeBinPath ["/root" "/usr" "/usr/local"]
|
||||
=> "/root/bin:/usr/bin:/usr/local/bin"
|
||||
*/
|
||||
makeBinPath = makeSearchPathOutput "bin" "bin";
|
||||
|
||||
/* Depending on the boolean `cond', return either the given string
|
||||
or the empty string. Useful to concatenate against a bigger string.
|
||||
|
||||
Type: optionalString :: bool -> string -> string
|
||||
|
||||
Example:
|
||||
optionalString true "some-string"
|
||||
=> "some-string"
|
||||
optionalString false "some-string"
|
||||
=> ""
|
||||
*/
|
||||
optionalString =
|
||||
# Condition
|
||||
cond:
|
||||
# String to return if condition is true
|
||||
string: if cond then string else "";
|
||||
|
||||
/* Determine whether a string has given prefix.
|
||||
|
||||
Type: hasPrefix :: string -> string -> bool
|
||||
|
||||
Example:
|
||||
hasPrefix "foo" "foobar"
|
||||
=> true
|
||||
hasPrefix "foo" "barfoo"
|
||||
=> false
|
||||
*/
|
||||
hasPrefix =
|
||||
# Prefix to check for
|
||||
pref:
|
||||
# Input string
|
||||
str: substring 0 (stringLength pref) str == pref;
|
||||
|
||||
/* Determine whether a string has given suffix.
|
||||
|
||||
Type: hasSuffix :: string -> string -> bool
|
||||
|
||||
Example:
|
||||
hasSuffix "foo" "foobar"
|
||||
=> false
|
||||
hasSuffix "foo" "barfoo"
|
||||
=> true
|
||||
*/
|
||||
hasSuffix =
|
||||
# Suffix to check for
|
||||
suffix:
|
||||
# Input string
|
||||
content:
|
||||
let
|
||||
lenContent = stringLength content;
|
||||
lenSuffix = stringLength suffix;
|
||||
in lenContent >= lenSuffix &&
|
||||
substring (lenContent - lenSuffix) lenContent content == suffix;
|
||||
|
||||
/* Determine whether a string contains the given infix
|
||||
|
||||
Type: hasInfix :: string -> string -> bool
|
||||
|
||||
Example:
|
||||
hasInfix "bc" "abcd"
|
||||
=> true
|
||||
hasInfix "ab" "abcd"
|
||||
=> true
|
||||
hasInfix "cd" "abcd"
|
||||
=> true
|
||||
hasInfix "foo" "abcd"
|
||||
=> false
|
||||
*/
|
||||
hasInfix = infix: content:
|
||||
let
|
||||
drop = x: substring 1 (stringLength x) x;
|
||||
in hasPrefix infix content
|
||||
|| content != "" && hasInfix infix (drop content);
|
||||
|
||||
/* Convert a string to a list of characters (i.e. singleton strings).
|
||||
This allows you to, e.g., map a function over each character. However,
|
||||
note that this will likely be horribly inefficient; Nix is not a
|
||||
general purpose programming language. Complex string manipulations
|
||||
should, if appropriate, be done in a derivation.
|
||||
Also note that Nix treats strings as a list of bytes and thus doesn't
|
||||
handle unicode.
|
||||
|
||||
Type: stringtoCharacters :: string -> [string]
|
||||
|
||||
Example:
|
||||
stringToCharacters ""
|
||||
=> [ ]
|
||||
stringToCharacters "abc"
|
||||
=> [ "a" "b" "c" ]
|
||||
stringToCharacters "💩"
|
||||
=> [ "<EFBFBD>" "<EFBFBD>" "<EFBFBD>" "<EFBFBD>" ]
|
||||
*/
|
||||
stringToCharacters = s:
|
||||
map (p: substring p 1 s) (lib.range 0 (stringLength s - 1));
|
||||
|
||||
/* Manipulate a string character by character and replace them by
|
||||
strings before concatenating the results.
|
||||
|
||||
Type: stringAsChars :: (string -> string) -> string -> string
|
||||
|
||||
Example:
|
||||
stringAsChars (x: if x == "a" then "i" else x) "nax"
|
||||
=> "nix"
|
||||
*/
|
||||
stringAsChars =
|
||||
# Function to map over each individual character
|
||||
f:
|
||||
# Input string
|
||||
s: concatStrings (
|
||||
map f (stringToCharacters s)
|
||||
);
|
||||
|
||||
/* Escape occurrence of the elements of `list` in `string` by
|
||||
prefixing it with a backslash.
|
||||
|
||||
Type: escape :: [string] -> string -> string
|
||||
|
||||
Example:
|
||||
escape ["(" ")"] "(foo)"
|
||||
=> "\\(foo\\)"
|
||||
*/
|
||||
escape = list: replaceChars list (map (c: "\\${c}") list);
|
||||
|
||||
/* Quote string to be used safely within the Bourne shell.
|
||||
|
||||
Type: escapeShellArg :: string -> string
|
||||
|
||||
Example:
|
||||
escapeShellArg "esc'ape\nme"
|
||||
=> "'esc'\\''ape\nme'"
|
||||
*/
|
||||
escapeShellArg = arg: "'${replaceStrings ["'"] ["'\\''"] (toString arg)}'";
|
||||
|
||||
/* Quote all arguments to be safely passed to the Bourne shell.
|
||||
|
||||
Type: escapeShellArgs :: [string] -> string
|
||||
|
||||
Example:
|
||||
escapeShellArgs ["one" "two three" "four'five"]
|
||||
=> "'one' 'two three' 'four'\\''five'"
|
||||
*/
|
||||
escapeShellArgs = concatMapStringsSep " " escapeShellArg;
|
||||
|
||||
/* Turn a string into a Nix expression representing that string
|
||||
|
||||
Type: string -> string
|
||||
|
||||
Example:
|
||||
escapeNixString "hello\${}\n"
|
||||
=> "\"hello\\\${}\\n\""
|
||||
*/
|
||||
escapeNixString = s: escape ["$"] (builtins.toJSON s);
|
||||
|
||||
# Obsolete - use replaceStrings instead.
|
||||
replaceChars = builtins.replaceStrings or (
|
||||
del: new: s:
|
||||
let
|
||||
substList = lib.zipLists del new;
|
||||
subst = c:
|
||||
let found = lib.findFirst (sub: sub.fst == c) null substList; in
|
||||
if found == null then
|
||||
c
|
||||
else
|
||||
found.snd;
|
||||
in
|
||||
stringAsChars subst s);
|
||||
|
||||
# Case conversion utilities.
|
||||
lowerChars = stringToCharacters "abcdefghijklmnopqrstuvwxyz";
|
||||
upperChars = stringToCharacters "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
|
||||
|
||||
/* Converts an ASCII string to lower-case.
|
||||
|
||||
Type: toLower :: string -> string
|
||||
|
||||
Example:
|
||||
toLower "HOME"
|
||||
=> "home"
|
||||
*/
|
||||
toLower = replaceChars upperChars lowerChars;
|
||||
|
||||
/* Converts an ASCII string to upper-case.
|
||||
|
||||
Type: toUpper :: string -> string
|
||||
|
||||
Example:
|
||||
toUpper "home"
|
||||
=> "HOME"
|
||||
*/
|
||||
toUpper = replaceChars lowerChars upperChars;
|
||||
|
||||
/* Appends string context from another string. This is an implementation
|
||||
detail of Nix.
|
||||
|
||||
Strings in Nix carry an invisible `context` which is a list of strings
|
||||
representing store paths. If the string is later used in a derivation
|
||||
attribute, the derivation will properly populate the inputDrvs and
|
||||
inputSrcs.
|
||||
|
||||
Example:
|
||||
pkgs = import <nixpkgs> { };
|
||||
addContextFrom pkgs.coreutils "bar"
|
||||
=> "bar"
|
||||
*/
|
||||
addContextFrom = a: b: substring 0 0 a + b;
|
||||
|
||||
/* Cut a string with a separator and produces a list of strings which
|
||||
were separated by this separator.
|
||||
|
||||
NOTE: this function is not performant and should never be used.
|
||||
|
||||
Example:
|
||||
splitString "." "foo.bar.baz"
|
||||
=> [ "foo" "bar" "baz" ]
|
||||
splitString "/" "/usr/local/bin"
|
||||
=> [ "" "usr" "local" "bin" ]
|
||||
*/
|
||||
splitString = _sep: _s:
|
||||
let
|
||||
sep = addContextFrom _s _sep;
|
||||
s = addContextFrom _sep _s;
|
||||
sepLen = stringLength sep;
|
||||
sLen = stringLength s;
|
||||
lastSearch = sLen - sepLen;
|
||||
startWithSep = startAt:
|
||||
substring startAt sepLen s == sep;
|
||||
|
||||
recurse = index: startAt:
|
||||
let cutUntil = i: [(substring startAt (i - startAt) s)]; in
|
||||
if index <= lastSearch then
|
||||
if startWithSep index then
|
||||
let restartAt = index + sepLen; in
|
||||
cutUntil index ++ recurse restartAt restartAt
|
||||
else
|
||||
recurse (index + 1) startAt
|
||||
else
|
||||
cutUntil sLen;
|
||||
in
|
||||
recurse 0 0;
|
||||
|
||||
/* Return a string without the specified prefix, if the prefix matches.
|
||||
|
||||
Type: string -> string -> string
|
||||
|
||||
Example:
|
||||
removePrefix "foo." "foo.bar.baz"
|
||||
=> "bar.baz"
|
||||
removePrefix "xxx" "foo.bar.baz"
|
||||
=> "foo.bar.baz"
|
||||
*/
|
||||
removePrefix =
|
||||
# Prefix to remove if it matches
|
||||
prefix:
|
||||
# Input string
|
||||
str:
|
||||
let
|
||||
preLen = stringLength prefix;
|
||||
sLen = stringLength str;
|
||||
in
|
||||
if hasPrefix prefix str then
|
||||
substring preLen (sLen - preLen) str
|
||||
else
|
||||
str;
|
||||
|
||||
/* Return a string without the specified suffix, if the suffix matches.
|
||||
|
||||
Type: string -> string -> string
|
||||
|
||||
Example:
|
||||
removeSuffix "front" "homefront"
|
||||
=> "home"
|
||||
removeSuffix "xxx" "homefront"
|
||||
=> "homefront"
|
||||
*/
|
||||
removeSuffix =
|
||||
# Suffix to remove if it matches
|
||||
suffix:
|
||||
# Input string
|
||||
str:
|
||||
let
|
||||
sufLen = stringLength suffix;
|
||||
sLen = stringLength str;
|
||||
in
|
||||
if sufLen <= sLen && suffix == substring (sLen - sufLen) sufLen str then
|
||||
substring 0 (sLen - sufLen) str
|
||||
else
|
||||
str;
|
||||
|
||||
/* Return true if string v1 denotes a version older than v2.
|
||||
|
||||
Example:
|
||||
versionOlder "1.1" "1.2"
|
||||
=> true
|
||||
versionOlder "1.1" "1.1"
|
||||
=> false
|
||||
*/
|
||||
versionOlder = v1: v2: builtins.compareVersions v2 v1 == 1;
|
||||
|
||||
/* Return true if string v1 denotes a version equal to or newer than v2.
|
||||
|
||||
Example:
|
||||
versionAtLeast "1.1" "1.0"
|
||||
=> true
|
||||
versionAtLeast "1.1" "1.1"
|
||||
=> true
|
||||
versionAtLeast "1.1" "1.2"
|
||||
=> false
|
||||
*/
|
||||
versionAtLeast = v1: v2: !versionOlder v1 v2;
|
||||
|
||||
/* This function takes an argument that's either a derivation or a
|
||||
derivation's "name" attribute and extracts the version part from that
|
||||
argument.
|
||||
|
||||
Example:
|
||||
getVersion "youtube-dl-2016.01.01"
|
||||
=> "2016.01.01"
|
||||
getVersion pkgs.youtube-dl
|
||||
=> "2016.01.01"
|
||||
*/
|
||||
getVersion = x:
|
||||
let
|
||||
parse = drv: (builtins.parseDrvName drv).version;
|
||||
in if isString x
|
||||
then parse x
|
||||
else x.version or (parse x.name);
|
||||
|
||||
/* Extract name with version from URL. Ask for separator which is
|
||||
supposed to start extension.
|
||||
|
||||
Example:
|
||||
nameFromURL "https://nixos.org/releases/nix/nix-1.7/nix-1.7-x86_64-linux.tar.bz2" "-"
|
||||
=> "nix"
|
||||
nameFromURL "https://nixos.org/releases/nix/nix-1.7/nix-1.7-x86_64-linux.tar.bz2" "_"
|
||||
=> "nix-1.7-x86"
|
||||
*/
|
||||
nameFromURL = url: sep:
|
||||
let
|
||||
components = splitString "/" url;
|
||||
filename = lib.last components;
|
||||
name = builtins.head (splitString sep filename);
|
||||
in assert name != filename; name;
|
||||
|
||||
/* Create an --{enable,disable}-<feat> string that can be passed to
|
||||
standard GNU Autoconf scripts.
|
||||
|
||||
Example:
|
||||
enableFeature true "shared"
|
||||
=> "--enable-shared"
|
||||
enableFeature false "shared"
|
||||
=> "--disable-shared"
|
||||
*/
|
||||
enableFeature = enable: feat: "--${if enable then "enable" else "disable"}-${feat}";
|
||||
|
||||
/* Create an --{enable-<feat>=<value>,disable-<feat>} string that can be passed to
|
||||
standard GNU Autoconf scripts.
|
||||
|
||||
Example:
|
||||
enableFeature true "shared" "foo"
|
||||
=> "--enable-shared=foo"
|
||||
enableFeature false "shared" (throw "ignored")
|
||||
=> "--disable-shared"
|
||||
*/
|
||||
enableFeatureAs = enable: feat: value: enableFeature enable feat + optionalString enable "=${value}";
|
||||
|
||||
/* Create an --{with,without}-<feat> string that can be passed to
|
||||
standard GNU Autoconf scripts.
|
||||
|
||||
Example:
|
||||
withFeature true "shared"
|
||||
=> "--with-shared"
|
||||
withFeature false "shared"
|
||||
=> "--without-shared"
|
||||
*/
|
||||
withFeature = with_: feat: "--${if with_ then "with" else "without"}-${feat}";
|
||||
|
||||
/* Create an --{with-<feat>=<value>,without-<feat>} string that can be passed to
|
||||
standard GNU Autoconf scripts.
|
||||
|
||||
Example:
|
||||
with_Feature true "shared" "foo"
|
||||
=> "--with-shared=foo"
|
||||
with_Feature false "shared" (throw "ignored")
|
||||
=> "--without-shared"
|
||||
*/
|
||||
withFeatureAs = with_: feat: value: withFeature with_ feat + optionalString with_ "=${value}";
|
||||
|
||||
/* Create a fixed width string with additional prefix to match
|
||||
required width.
|
||||
|
||||
This function will fail if the input string is longer than the
|
||||
requested length.
|
||||
|
||||
Type: fixedWidthString :: int -> string -> string
|
||||
|
||||
Example:
|
||||
fixedWidthString 5 "0" (toString 15)
|
||||
=> "00015"
|
||||
*/
|
||||
fixedWidthString = width: filler: str:
|
||||
let
|
||||
strw = lib.stringLength str;
|
||||
reqWidth = width - (lib.stringLength filler);
|
||||
in
|
||||
assert lib.assertMsg (strw <= width)
|
||||
"fixedWidthString: requested string length (${
|
||||
toString width}) must not be shorter than actual length (${
|
||||
toString strw})";
|
||||
if strw == width then str else filler + fixedWidthString reqWidth filler str;
|
||||
|
||||
/* Format a number adding leading zeroes up to fixed width.
|
||||
|
||||
Example:
|
||||
fixedWidthNumber 5 15
|
||||
=> "00015"
|
||||
*/
|
||||
fixedWidthNumber = width: n: fixedWidthString width "0" (toString n);
|
||||
|
||||
/* Check whether a value can be coerced to a string */
|
||||
isCoercibleToString = x:
|
||||
builtins.elem (builtins.typeOf x) [ "path" "string" "null" "int" "float" "bool" ] ||
|
||||
(builtins.isList x && lib.all isCoercibleToString x) ||
|
||||
x ? outPath ||
|
||||
x ? __toString;
|
||||
|
||||
/* Check whether a value is a store path.
|
||||
|
||||
Example:
|
||||
isStorePath "/nix/store/d945ibfx9x185xf04b890y4f9g3cbb63-python-2.7.11/bin/python"
|
||||
=> false
|
||||
isStorePath "/nix/store/d945ibfx9x185xf04b890y4f9g3cbb63-python-2.7.11/"
|
||||
=> true
|
||||
isStorePath pkgs.python
|
||||
=> true
|
||||
isStorePath [] || isStorePath 42 || isStorePath {} || …
|
||||
=> false
|
||||
*/
|
||||
isStorePath = x:
|
||||
if isCoercibleToString x then
|
||||
let str = toString x; in
|
||||
builtins.substring 0 1 str == "/"
|
||||
&& dirOf str == builtins.storeDir
|
||||
else
|
||||
false;
|
||||
|
||||
/* Parse a string string as an int.
|
||||
|
||||
Type: string -> int
|
||||
|
||||
Example:
|
||||
toInt "1337"
|
||||
=> 1337
|
||||
toInt "-4"
|
||||
=> -4
|
||||
toInt "3.14"
|
||||
=> error: floating point JSON numbers are not supported
|
||||
*/
|
||||
# Obviously, it is a bit hacky to use fromJSON this way.
|
||||
toInt = str:
|
||||
let may_be_int = builtins.fromJSON str; in
|
||||
if builtins.isInt may_be_int
|
||||
then may_be_int
|
||||
else throw "Could not convert ${str} to int.";
|
||||
|
||||
/* Read a list of paths from `file`, relative to the `rootPath`.
|
||||
Lines beginning with `#` are treated as comments and ignored.
|
||||
Whitespace is significant.
|
||||
|
||||
NOTE: This function is not performant and should be avoided.
|
||||
|
||||
Example:
|
||||
readPathsFromFile /prefix
|
||||
./pkgs/development/libraries/qt-5/5.4/qtbase/series
|
||||
=> [ "/prefix/dlopen-resolv.patch" "/prefix/tzdir.patch"
|
||||
"/prefix/dlopen-libXcursor.patch" "/prefix/dlopen-openssl.patch"
|
||||
"/prefix/dlopen-dbus.patch" "/prefix/xdg-config-dirs.patch"
|
||||
"/prefix/nix-profiles-library-paths.patch"
|
||||
"/prefix/compose-search-path.patch" ]
|
||||
*/
|
||||
readPathsFromFile = rootPath: file:
|
||||
let
|
||||
lines = lib.splitString "\n" (builtins.readFile file);
|
||||
removeComments = lib.filter (line: line != "" && !(lib.hasPrefix "#" line));
|
||||
relativePaths = removeComments lines;
|
||||
absolutePaths = builtins.map (path: rootPath + "/${path}") relativePaths;
|
||||
in
|
||||
absolutePaths;
|
||||
|
||||
/* Read the contents of a file removing the trailing \n
|
||||
|
||||
Type: fileContents :: path -> string
|
||||
|
||||
Example:
|
||||
$ echo "1.0" > ./version
|
||||
|
||||
fileContents ./version
|
||||
=> "1.0"
|
||||
*/
|
||||
fileContents = file: removeSuffix "\n" (builtins.readFile file);
|
||||
}
|
||||
@@ -1,121 +0,0 @@
|
||||
{ lib }:
|
||||
let inherit (lib.attrsets) mapAttrs; in
|
||||
|
||||
rec {
|
||||
doubles = import ./doubles.nix { inherit lib; };
|
||||
forMeta = import ./for-meta.nix { inherit lib; };
|
||||
parse = import ./parse.nix { inherit lib; };
|
||||
inspect = import ./inspect.nix { inherit lib; };
|
||||
platforms = import ./platforms.nix { inherit lib; };
|
||||
examples = import ./examples.nix { inherit lib; };
|
||||
|
||||
# Elaborate a `localSystem` or `crossSystem` so that it contains everything
|
||||
# necessary.
|
||||
#
|
||||
# `parsed` is inferred from args, both because there are two options with one
|
||||
# clearly prefered, and to prevent cycles. A simpler fixed point where the RHS
|
||||
# always just used `final.*` would fail on both counts.
|
||||
elaborate = args: let
|
||||
final = {
|
||||
# Prefer to parse `config` as it is strictly more informative.
|
||||
parsed = parse.mkSystemFromString (if args ? config then args.config else args.system);
|
||||
# Either of these can be losslessly-extracted from `parsed` iff parsing succeeds.
|
||||
system = parse.doubleFromSystem final.parsed;
|
||||
config = parse.tripleFromSystem final.parsed;
|
||||
# Just a guess, based on `system`
|
||||
platform = platforms.selectBySystem final.system;
|
||||
# Derived meta-data
|
||||
libc =
|
||||
/**/ if final.isDarwin then "libSystem"
|
||||
else if final.isMinGW then "msvcrt"
|
||||
else if final.isMusl then "musl"
|
||||
else if final.isUClibc then "uclibc"
|
||||
else if final.isAndroid then "bionic"
|
||||
else if final.isLinux /* default */ then "glibc"
|
||||
else if final.isAvr then "avrlibc"
|
||||
# TODO(@Ericson2314) think more about other operating systems
|
||||
else "native/impure";
|
||||
extensions = {
|
||||
sharedLibrary =
|
||||
/**/ if final.isDarwin then ".dylib"
|
||||
else if final.isWindows then ".dll"
|
||||
else ".so";
|
||||
executable =
|
||||
/**/ if final.isWindows then ".exe"
|
||||
else "";
|
||||
};
|
||||
# Misc boolean options
|
||||
useAndroidPrebuilt = false;
|
||||
useiOSPrebuilt = false;
|
||||
|
||||
# Output from uname
|
||||
uname = {
|
||||
# uname -s
|
||||
system = {
|
||||
"linux" = "Linux";
|
||||
"windows" = "Windows";
|
||||
"darwin" = "Darwin";
|
||||
"netbsd" = "NetBSD";
|
||||
"freebsd" = "FreeBSD";
|
||||
"openbsd" = "OpenBSD";
|
||||
"wasm" = "Wasm";
|
||||
}.${final.parsed.kernel.name} or null;
|
||||
|
||||
# uname -p
|
||||
processor = final.parsed.cpu.name;
|
||||
|
||||
# uname -r
|
||||
release = null;
|
||||
};
|
||||
|
||||
qemuArch =
|
||||
if final.isArm then "arm"
|
||||
else if final.isx86_64 then "x86_64"
|
||||
else if final.isx86 then "i386"
|
||||
else {
|
||||
"powerpc" = "ppc";
|
||||
"powerpc64" = "ppc64";
|
||||
"powerpc64le" = "ppc64";
|
||||
"mips64" = "mips";
|
||||
"mipsel64" = "mipsel";
|
||||
}.${final.parsed.cpu.name} or final.parsed.cpu.name;
|
||||
|
||||
emulator = pkgs: let
|
||||
qemu-user = pkgs.qemu.override {
|
||||
smartcardSupport = false;
|
||||
spiceSupport = false;
|
||||
openGLSupport = false;
|
||||
virglSupport = false;
|
||||
vncSupport = false;
|
||||
gtkSupport = false;
|
||||
sdlSupport = false;
|
||||
pulseSupport = false;
|
||||
smbdSupport = false;
|
||||
seccompSupport = false;
|
||||
hostCpuTargets = ["${final.qemuArch}-linux-user"];
|
||||
};
|
||||
wine-name = "wine${toString final.parsed.cpu.bits}";
|
||||
wine = (pkgs.winePackagesFor wine-name).minimal;
|
||||
in
|
||||
if final.parsed.kernel.name == pkgs.stdenv.hostPlatform.parsed.kernel.name &&
|
||||
(final.parsed.cpu.name == pkgs.stdenv.hostPlatform.parsed.cpu.name ||
|
||||
(final.isi686 && pkgs.stdenv.hostPlatform.isx86_64))
|
||||
then pkgs.runtimeShell
|
||||
else if final.isWindows
|
||||
then "${wine}/bin/${wine-name}"
|
||||
else if final.isLinux && pkgs.stdenv.hostPlatform.isLinux
|
||||
then "${qemu-user}/bin/qemu-${final.qemuArch}"
|
||||
else throw "Don't know how to run ${final.config} executables.";
|
||||
|
||||
} // mapAttrs (n: v: v final.parsed) inspect.predicates
|
||||
// args;
|
||||
in assert final.useAndroidPrebuilt -> final.isAndroid;
|
||||
assert lib.foldl
|
||||
(pass: { assertion, message }:
|
||||
if assertion final
|
||||
then pass
|
||||
else throw message)
|
||||
true
|
||||
(final.parsed.abi.assertions or []);
|
||||
final;
|
||||
}
|
||||
@@ -1,51 +0,0 @@
|
||||
{ lib }:
|
||||
let
|
||||
inherit (lib) lists;
|
||||
inherit (lib.systems) parse;
|
||||
inherit (lib.systems.inspect) predicates;
|
||||
inherit (lib.attrsets) matchAttrs;
|
||||
|
||||
all = [
|
||||
"aarch64-linux"
|
||||
"armv5tel-linux" "armv6l-linux" "armv7l-linux"
|
||||
|
||||
"mipsel-linux"
|
||||
|
||||
"i686-cygwin" "i686-freebsd" "i686-linux" "i686-netbsd" "i686-openbsd"
|
||||
|
||||
"x86_64-cygwin" "x86_64-darwin" "x86_64-freebsd" "x86_64-linux"
|
||||
"x86_64-netbsd" "x86_64-openbsd" "x86_64-solaris"
|
||||
|
||||
"x86_64-windows" "i686-windows"
|
||||
];
|
||||
|
||||
allParsed = map parse.mkSystemFromString all;
|
||||
|
||||
filterDoubles = f: map parse.doubleFromSystem (lists.filter f allParsed);
|
||||
|
||||
in rec {
|
||||
inherit all;
|
||||
|
||||
none = [];
|
||||
|
||||
arm = filterDoubles predicates.isAarch32;
|
||||
aarch64 = filterDoubles predicates.isAarch64;
|
||||
x86 = filterDoubles predicates.isx86;
|
||||
i686 = filterDoubles predicates.isi686;
|
||||
x86_64 = filterDoubles predicates.isx86_64;
|
||||
mips = filterDoubles predicates.isMips;
|
||||
|
||||
cygwin = filterDoubles predicates.isCygwin;
|
||||
darwin = filterDoubles predicates.isDarwin;
|
||||
freebsd = filterDoubles predicates.isFreeBSD;
|
||||
# Should be better, but MinGW is unclear.
|
||||
gnu = filterDoubles (matchAttrs { kernel = parse.kernels.linux; abi = parse.abis.gnu; }) ++ filterDoubles (matchAttrs { kernel = parse.kernels.linux; abi = parse.abis.gnueabi; }) ++ filterDoubles (matchAttrs { kernel = parse.kernels.linux; abi = parse.abis.gnueabihf; });
|
||||
illumos = filterDoubles predicates.isSunOS;
|
||||
linux = filterDoubles predicates.isLinux;
|
||||
netbsd = filterDoubles predicates.isNetBSD;
|
||||
openbsd = filterDoubles predicates.isOpenBSD;
|
||||
unix = filterDoubles predicates.isUnix;
|
||||
windows = filterDoubles predicates.isWindows;
|
||||
|
||||
mesaPlatforms = ["i686-linux" "x86_64-linux" "x86_64-darwin" "armv5tel-linux" "armv6l-linux" "armv7l-linux" "aarch64-linux" "powerpc64le-linux"];
|
||||
}
|
||||
@@ -1,215 +0,0 @@
|
||||
# These can be passed to nixpkgs as either the `localSystem` or
|
||||
# `crossSystem`. They are put here for user convenience, but also used by cross
|
||||
# tests and linux cross stdenv building, so handle with care!
|
||||
{ lib }:
|
||||
let
|
||||
platforms = import ./platforms.nix { inherit lib; };
|
||||
|
||||
riscv = bits: {
|
||||
config = "riscv${bits}-unknown-linux-gnu";
|
||||
platform = platforms.riscv-multiplatform bits;
|
||||
};
|
||||
in
|
||||
|
||||
rec {
|
||||
#
|
||||
# Linux
|
||||
#
|
||||
powernv = {
|
||||
config = "powerpc64le-unknown-linux-gnu";
|
||||
platform = platforms.powernv;
|
||||
};
|
||||
musl-power = {
|
||||
config = "powerpc64le-unknown-linux-musl";
|
||||
platform = platforms.powernv;
|
||||
};
|
||||
|
||||
sheevaplug = rec {
|
||||
config = "armv5tel-unknown-linux-gnueabi";
|
||||
platform = platforms.sheevaplug;
|
||||
};
|
||||
|
||||
raspberryPi = rec {
|
||||
config = "armv6l-unknown-linux-gnueabihf";
|
||||
platform = platforms.raspberrypi;
|
||||
};
|
||||
|
||||
armv7l-hf-multiplatform = rec {
|
||||
config = "armv7l-unknown-linux-gnueabihf";
|
||||
platform = platforms.armv7l-hf-multiplatform;
|
||||
};
|
||||
|
||||
aarch64-multiplatform = rec {
|
||||
config = "aarch64-unknown-linux-gnu";
|
||||
platform = platforms.aarch64-multiplatform;
|
||||
};
|
||||
|
||||
armv5te-android-prebuilt = rec {
|
||||
config = "armv5tel-unknown-linux-androideabi";
|
||||
sdkVer = "21";
|
||||
ndkVer = "18b";
|
||||
platform = platforms.armv5te-android;
|
||||
useAndroidPrebuilt = true;
|
||||
};
|
||||
|
||||
armv7a-android-prebuilt = rec {
|
||||
config = "armv7a-unknown-linux-androideabi";
|
||||
sdkVer = "24";
|
||||
ndkVer = "18b";
|
||||
platform = platforms.armv7a-android;
|
||||
useAndroidPrebuilt = true;
|
||||
};
|
||||
|
||||
aarch64-android-prebuilt = rec {
|
||||
config = "aarch64-unknown-linux-android";
|
||||
sdkVer = "24";
|
||||
ndkVer = "18b";
|
||||
platform = platforms.aarch64-multiplatform;
|
||||
useAndroidPrebuilt = true;
|
||||
};
|
||||
|
||||
scaleway-c1 = armv7l-hf-multiplatform // rec {
|
||||
platform = platforms.scaleway-c1;
|
||||
inherit (platform.gcc) fpu;
|
||||
};
|
||||
|
||||
pogoplug4 = rec {
|
||||
config = "armv5tel-unknown-linux-gnueabi";
|
||||
platform = platforms.pogoplug4;
|
||||
};
|
||||
|
||||
ben-nanonote = rec {
|
||||
config = "mipsel-unknown-linux-uclibc";
|
||||
platform = platforms.ben_nanonote;
|
||||
};
|
||||
|
||||
fuloongminipc = rec {
|
||||
config = "mipsel-unknown-linux-gnu";
|
||||
platform = platforms.fuloong2f_n32;
|
||||
};
|
||||
|
||||
muslpi = raspberryPi // {
|
||||
config = "armv6l-unknown-linux-musleabihf";
|
||||
};
|
||||
|
||||
aarch64-multiplatform-musl = aarch64-multiplatform // {
|
||||
config = "aarch64-unknown-linux-musl";
|
||||
};
|
||||
|
||||
musl64 = { config = "x86_64-unknown-linux-musl"; };
|
||||
musl32 = { config = "i686-unknown-linux-musl"; };
|
||||
|
||||
riscv64 = riscv "64";
|
||||
riscv32 = riscv "32";
|
||||
|
||||
avr = {
|
||||
config = "avr";
|
||||
};
|
||||
|
||||
arm-embedded = {
|
||||
config = "arm-none-eabi";
|
||||
libc = "newlib";
|
||||
};
|
||||
armhf-embedded = {
|
||||
config = "arm-none-eabihf";
|
||||
libc = "newlib";
|
||||
};
|
||||
|
||||
aarch64-embedded = {
|
||||
config = "aarch64-none-elf";
|
||||
libc = "newlib";
|
||||
};
|
||||
|
||||
aarch64be-embedded = {
|
||||
config = "aarch64_be-none-elf";
|
||||
libc = "newlib";
|
||||
};
|
||||
|
||||
ppc-embedded = {
|
||||
config = "powerpc-none-eabi";
|
||||
libc = "newlib";
|
||||
};
|
||||
|
||||
ppcle-embedded = {
|
||||
config = "powerpcle-none-eabi";
|
||||
libc = "newlib";
|
||||
};
|
||||
|
||||
alpha-embedded = {
|
||||
config = "alpha-elf";
|
||||
libc = "newlib";
|
||||
};
|
||||
|
||||
i686-embedded = {
|
||||
config = "i686-elf";
|
||||
libc = "newlib";
|
||||
};
|
||||
|
||||
x86_64-embedded = {
|
||||
config = "x86_64-elf";
|
||||
libc = "newlib";
|
||||
};
|
||||
|
||||
#
|
||||
# Darwin
|
||||
#
|
||||
|
||||
iphone64 = {
|
||||
config = "aarch64-apple-ios";
|
||||
# config = "aarch64-apple-darwin14";
|
||||
sdkVer = "10.2";
|
||||
xcodeVer = "8.2";
|
||||
xcodePlatform = "iPhoneOS";
|
||||
useiOSPrebuilt = true;
|
||||
platform = {};
|
||||
};
|
||||
|
||||
iphone32 = {
|
||||
config = "armv7a-apple-ios";
|
||||
# config = "arm-apple-darwin10";
|
||||
sdkVer = "10.2";
|
||||
xcodeVer = "8.2";
|
||||
xcodePlatform = "iPhoneOS";
|
||||
useiOSPrebuilt = true;
|
||||
platform = {};
|
||||
};
|
||||
|
||||
iphone64-simulator = {
|
||||
config = "x86_64-apple-ios";
|
||||
# config = "x86_64-apple-darwin14";
|
||||
sdkVer = "10.2";
|
||||
xcodeVer = "8.2";
|
||||
xcodePlatform = "iPhoneSimulator";
|
||||
useiOSPrebuilt = true;
|
||||
platform = {};
|
||||
};
|
||||
|
||||
iphone32-simulator = {
|
||||
config = "i686-apple-ios";
|
||||
# config = "i386-apple-darwin11";
|
||||
sdkVer = "10.2";
|
||||
xcodeVer = "8.2";
|
||||
xcodePlatform = "iPhoneSimulator";
|
||||
useiOSPrebuilt = true;
|
||||
platform = {};
|
||||
};
|
||||
|
||||
#
|
||||
# Windows
|
||||
#
|
||||
|
||||
# 32 bit mingw-w64
|
||||
mingw32 = {
|
||||
config = "i686-pc-mingw32";
|
||||
libc = "msvcrt"; # This distinguishes the mingw (non posix) toolchain
|
||||
platform = {};
|
||||
};
|
||||
|
||||
# 64 bit mingw-w64
|
||||
mingwW64 = {
|
||||
# That's the triplet they use in the mingw-w64 docs.
|
||||
config = "x86_64-pc-mingw32";
|
||||
libc = "msvcrt"; # This distinguishes the mingw (non posix) toolchain
|
||||
platform = {};
|
||||
};
|
||||
}
|
||||
@@ -1,37 +0,0 @@
|
||||
{ lib }:
|
||||
let
|
||||
inherit (lib.systems) parse;
|
||||
inherit (lib.systems.inspect) patterns;
|
||||
|
||||
abis = lib.mapAttrs (_: abi: builtins.removeAttrs abi [ "assertions" ]) parse.abis;
|
||||
|
||||
in rec {
|
||||
all = [ {} ]; # `{}` matches anything
|
||||
none = [];
|
||||
|
||||
arm = [ patterns.isAarch32 ];
|
||||
aarch64 = [ patterns.isAarch64 ];
|
||||
x86 = [ patterns.isx86 ];
|
||||
i686 = [ patterns.isi686 ];
|
||||
x86_64 = [ patterns.isx86_64 ];
|
||||
mips = [ patterns.isMips ];
|
||||
riscv = [ patterns.isRiscV ];
|
||||
|
||||
cygwin = [ patterns.isCygwin ];
|
||||
darwin = [ patterns.isDarwin ];
|
||||
freebsd = [ patterns.isFreeBSD ];
|
||||
# Should be better, but MinGW is unclear.
|
||||
gnu = [
|
||||
{ kernel = parse.kernels.linux; abi = abis.gnu; }
|
||||
{ kernel = parse.kernels.linux; abi = abis.gnueabi; }
|
||||
{ kernel = parse.kernels.linux; abi = abis.gnueabihf; }
|
||||
];
|
||||
illumos = [ patterns.isSunOS ];
|
||||
linux = [ patterns.isLinux ];
|
||||
netbsd = [ patterns.isNetBSD ];
|
||||
openbsd = [ patterns.isOpenBSD ];
|
||||
unix = patterns.isUnix; # Actually a list
|
||||
windows = [ patterns.isWindows ];
|
||||
|
||||
inherit (lib.systems.doubles) mesaPlatforms;
|
||||
}
|
||||
@@ -1,62 +0,0 @@
|
||||
{ lib }:
|
||||
with import ./parse.nix { inherit lib; };
|
||||
with lib.attrsets;
|
||||
with lib.lists;
|
||||
|
||||
let abis_ = abis; in
|
||||
let abis = lib.mapAttrs (_: abi: builtins.removeAttrs abi [ "assertions" ]) abis_; in
|
||||
|
||||
rec {
|
||||
patterns = rec {
|
||||
isi686 = { cpu = cpuTypes.i686; };
|
||||
isx86_32 = { cpu = { family = "x86"; bits = 32; }; };
|
||||
isx86_64 = { cpu = { family = "x86"; bits = 64; }; };
|
||||
isPowerPC = { cpu = cpuTypes.powerpc; };
|
||||
isPower = { cpu = { family = "power"; }; };
|
||||
isx86 = { cpu = { family = "x86"; }; };
|
||||
isAarch32 = { cpu = { family = "arm"; bits = 32; }; };
|
||||
isAarch64 = { cpu = { family = "arm"; bits = 64; }; };
|
||||
isMips = { cpu = { family = "mips"; }; };
|
||||
isRiscV = { cpu = { family = "riscv"; }; };
|
||||
isSparc = { cpu = { family = "sparc"; }; };
|
||||
isWasm = { cpu = { family = "wasm"; }; };
|
||||
isAvr = { cpu = { family = "avr"; }; };
|
||||
isAlpha = { cpu = { family = "alpha"; }; };
|
||||
|
||||
is32bit = { cpu = { bits = 32; }; };
|
||||
is64bit = { cpu = { bits = 64; }; };
|
||||
isBigEndian = { cpu = { significantByte = significantBytes.bigEndian; }; };
|
||||
isLittleEndian = { cpu = { significantByte = significantBytes.littleEndian; }; };
|
||||
|
||||
isBSD = { kernel = { families = { inherit (kernelFamilies) bsd; }; }; };
|
||||
isDarwin = { kernel = { families = { inherit (kernelFamilies) darwin; }; }; };
|
||||
isUnix = [ isBSD isDarwin isLinux isSunOS isCygwin ];
|
||||
|
||||
isMacOS = { kernel = kernels.macos; };
|
||||
isiOS = { kernel = kernels.ios; };
|
||||
isLinux = { kernel = kernels.linux; };
|
||||
isSunOS = { kernel = kernels.solaris; };
|
||||
isFreeBSD = { kernel = kernels.freebsd; };
|
||||
isNetBSD = { kernel = kernels.netbsd; };
|
||||
isOpenBSD = { kernel = kernels.openbsd; };
|
||||
isWindows = { kernel = kernels.windows; };
|
||||
isCygwin = { kernel = kernels.windows; abi = abis.cygnus; };
|
||||
isMinGW = { kernel = kernels.windows; abi = abis.gnu; };
|
||||
|
||||
isAndroid = [ { abi = abis.android; } { abi = abis.androideabi; } ];
|
||||
isMusl = with abis; map (a: { abi = a; }) [ musl musleabi musleabihf ];
|
||||
isUClibc = with abis; map (a: { abi = a; }) [ uclibc uclibceabi uclibceabihf ];
|
||||
|
||||
isEfi = map (family: { cpu.family = family; })
|
||||
[ "x86" "arm" "aarch64" ];
|
||||
|
||||
# Deprecated after 18.03
|
||||
isArm = isAarch32;
|
||||
};
|
||||
|
||||
matchAnyAttrs = patterns:
|
||||
if builtins.isList patterns then attrs: any (pattern: matchAttrs pattern attrs) patterns
|
||||
else matchAttrs patterns;
|
||||
|
||||
predicates = mapAttrs (_: matchAnyAttrs) patterns;
|
||||
}
|
||||
@@ -1,357 +0,0 @@
|
||||
# Define the list of system with their properties.
|
||||
#
|
||||
# See https://clang.llvm.org/docs/CrossCompilation.html and
|
||||
# http://llvm.org/docs/doxygen/html/Triple_8cpp_source.html especially
|
||||
# Triple::normalize. Parsing should essentially act as a more conservative
|
||||
# version of that last function.
|
||||
#
|
||||
# Most of the types below come in "open" and "closed" pairs. The open ones
|
||||
# specify what information we need to know about systems in general, and the
|
||||
# closed ones are sub-types representing the whitelist of systems we support in
|
||||
# practice.
|
||||
#
|
||||
# Code in the remainder of nixpkgs shouldn't rely on the closed ones in
|
||||
# e.g. exhaustive cases. Its more a sanity check to make sure nobody defines
|
||||
# systems that overlap with existing ones and won't notice something amiss.
|
||||
#
|
||||
{ lib }:
|
||||
with lib.lists;
|
||||
with lib.types;
|
||||
with lib.attrsets;
|
||||
with lib.strings;
|
||||
with (import ./inspect.nix { inherit lib; }).predicates;
|
||||
|
||||
let
|
||||
inherit (lib.options) mergeOneOption;
|
||||
|
||||
setTypes = type:
|
||||
mapAttrs (name: value:
|
||||
assert type.check value;
|
||||
setType type.name ({ inherit name; } // value));
|
||||
|
||||
in
|
||||
|
||||
rec {
|
||||
|
||||
################################################################################
|
||||
|
||||
types.openSignificantByte = mkOptionType {
|
||||
name = "significant-byte";
|
||||
description = "Endianness";
|
||||
merge = mergeOneOption;
|
||||
};
|
||||
|
||||
types.significantByte = enum (attrValues significantBytes);
|
||||
|
||||
significantBytes = setTypes types.openSignificantByte {
|
||||
bigEndian = {};
|
||||
littleEndian = {};
|
||||
};
|
||||
|
||||
################################################################################
|
||||
|
||||
# Reasonable power of 2
|
||||
types.bitWidth = enum [ 8 16 32 64 128 ];
|
||||
|
||||
################################################################################
|
||||
|
||||
types.openCpuType = mkOptionType {
|
||||
name = "cpu-type";
|
||||
description = "instruction set architecture name and information";
|
||||
merge = mergeOneOption;
|
||||
check = x: types.bitWidth.check x.bits
|
||||
&& (if 8 < x.bits
|
||||
then types.significantByte.check x.significantByte
|
||||
else !(x ? significantByte));
|
||||
};
|
||||
|
||||
types.cpuType = enum (attrValues cpuTypes);
|
||||
|
||||
cpuTypes = with significantBytes; setTypes types.openCpuType {
|
||||
arm = { bits = 32; significantByte = littleEndian; family = "arm"; };
|
||||
armv5tel = { bits = 32; significantByte = littleEndian; family = "arm"; version = "5"; };
|
||||
armv6m = { bits = 32; significantByte = littleEndian; family = "arm"; version = "6"; };
|
||||
armv6l = { bits = 32; significantByte = littleEndian; family = "arm"; version = "6"; };
|
||||
armv7a = { bits = 32; significantByte = littleEndian; family = "arm"; version = "7"; };
|
||||
armv7r = { bits = 32; significantByte = littleEndian; family = "arm"; version = "7"; };
|
||||
armv7m = { bits = 32; significantByte = littleEndian; family = "arm"; version = "7"; };
|
||||
armv7l = { bits = 32; significantByte = littleEndian; family = "arm"; version = "7"; };
|
||||
armv8a = { bits = 32; significantByte = littleEndian; family = "arm"; version = "8"; };
|
||||
armv8r = { bits = 32; significantByte = littleEndian; family = "arm"; version = "8"; };
|
||||
armv8m = { bits = 32; significantByte = littleEndian; family = "arm"; version = "8"; };
|
||||
aarch64 = { bits = 64; significantByte = littleEndian; family = "arm"; version = "8"; };
|
||||
aarch64_be = { bits = 64; significantByte = bigEndian; family = "arm"; version = "8"; };
|
||||
|
||||
i386 = { bits = 32; significantByte = littleEndian; family = "x86"; };
|
||||
i486 = { bits = 32; significantByte = littleEndian; family = "x86"; };
|
||||
i586 = { bits = 32; significantByte = littleEndian; family = "x86"; };
|
||||
i686 = { bits = 32; significantByte = littleEndian; family = "x86"; };
|
||||
x86_64 = { bits = 64; significantByte = littleEndian; family = "x86"; };
|
||||
|
||||
mips = { bits = 32; significantByte = bigEndian; family = "mips"; };
|
||||
mipsel = { bits = 32; significantByte = littleEndian; family = "mips"; };
|
||||
mips64 = { bits = 64; significantByte = bigEndian; family = "mips"; };
|
||||
mips64el = { bits = 64; significantByte = littleEndian; family = "mips"; };
|
||||
|
||||
powerpc = { bits = 32; significantByte = bigEndian; family = "power"; };
|
||||
powerpc64 = { bits = 64; significantByte = bigEndian; family = "power"; };
|
||||
powerpc64le = { bits = 64; significantByte = littleEndian; family = "power"; };
|
||||
powerpcle = { bits = 32; significantByte = littleEndian; family = "power"; };
|
||||
|
||||
riscv32 = { bits = 32; significantByte = littleEndian; family = "riscv"; };
|
||||
riscv64 = { bits = 64; significantByte = littleEndian; family = "riscv"; };
|
||||
|
||||
sparc = { bits = 32; significantByte = bigEndian; family = "sparc"; };
|
||||
sparc64 = { bits = 64; significantByte = bigEndian; family = "sparc"; };
|
||||
|
||||
wasm32 = { bits = 32; significantByte = littleEndian; family = "wasm"; };
|
||||
wasm64 = { bits = 64; significantByte = littleEndian; family = "wasm"; };
|
||||
|
||||
alpha = { bits = 64; significantByte = littleEndian; family = "alpha"; };
|
||||
|
||||
avr = { bits = 8; family = "avr"; };
|
||||
};
|
||||
|
||||
################################################################################
|
||||
|
||||
types.openVendor = mkOptionType {
|
||||
name = "vendor";
|
||||
description = "vendor for the platform";
|
||||
merge = mergeOneOption;
|
||||
};
|
||||
|
||||
types.vendor = enum (attrValues vendors);
|
||||
|
||||
vendors = setTypes types.openVendor {
|
||||
apple = {};
|
||||
pc = {};
|
||||
|
||||
none = {};
|
||||
unknown = {};
|
||||
};
|
||||
|
||||
################################################################################
|
||||
|
||||
types.openExecFormat = mkOptionType {
|
||||
name = "exec-format";
|
||||
description = "executable container used by the kernel";
|
||||
merge = mergeOneOption;
|
||||
};
|
||||
|
||||
types.execFormat = enum (attrValues execFormats);
|
||||
|
||||
execFormats = setTypes types.openExecFormat {
|
||||
aout = {}; # a.out
|
||||
elf = {};
|
||||
macho = {};
|
||||
pe = {};
|
||||
|
||||
unknown = {};
|
||||
};
|
||||
|
||||
################################################################################
|
||||
|
||||
types.openKernelFamily = mkOptionType {
|
||||
name = "exec-format";
|
||||
description = "executable container used by the kernel";
|
||||
merge = mergeOneOption;
|
||||
};
|
||||
|
||||
types.kernelFamily = enum (attrValues kernelFamilies);
|
||||
|
||||
kernelFamilies = setTypes types.openKernelFamily {
|
||||
bsd = {};
|
||||
darwin = {};
|
||||
};
|
||||
|
||||
################################################################################
|
||||
|
||||
types.openKernel = mkOptionType {
|
||||
name = "kernel";
|
||||
description = "kernel name and information";
|
||||
merge = mergeOneOption;
|
||||
check = x: types.execFormat.check x.execFormat
|
||||
&& all types.kernelFamily.check (attrValues x.families);
|
||||
};
|
||||
|
||||
types.kernel = enum (attrValues kernels);
|
||||
|
||||
kernels = with execFormats; with kernelFamilies; setTypes types.openKernel {
|
||||
# TODO(@Ericson2314): Don't want to mass-rebuild yet to keeping 'darwin' as
|
||||
# the nnormalized name for macOS.
|
||||
macos = { execFormat = macho; families = { inherit darwin; }; name = "darwin"; };
|
||||
ios = { execFormat = macho; families = { inherit darwin; }; };
|
||||
freebsd = { execFormat = elf; families = { inherit bsd; }; };
|
||||
linux = { execFormat = elf; families = { }; };
|
||||
netbsd = { execFormat = elf; families = { inherit bsd; }; };
|
||||
none = { execFormat = unknown; families = { }; };
|
||||
openbsd = { execFormat = elf; families = { inherit bsd; }; };
|
||||
solaris = { execFormat = elf; families = { }; };
|
||||
windows = { execFormat = pe; families = { }; };
|
||||
} // { # aliases
|
||||
# 'darwin' is the kernel for all of them. We choose macOS by default.
|
||||
darwin = kernels.macos;
|
||||
watchos = kernels.ios;
|
||||
tvos = kernels.ios;
|
||||
win32 = kernels.windows;
|
||||
};
|
||||
|
||||
################################################################################
|
||||
|
||||
types.openAbi = mkOptionType {
|
||||
name = "abi";
|
||||
description = "binary interface for compiled code and syscalls";
|
||||
merge = mergeOneOption;
|
||||
};
|
||||
|
||||
types.abi = enum (attrValues abis);
|
||||
|
||||
abis = setTypes types.openAbi {
|
||||
cygnus = {};
|
||||
msvc = {};
|
||||
|
||||
# Note: eabi is specific to ARM and PowerPC.
|
||||
# On PowerPC, this corresponds to PPCEABI.
|
||||
# On ARM, this corresponds to ARMEABI.
|
||||
eabi = { float = "soft"; };
|
||||
eabihf = { float = "hard"; };
|
||||
|
||||
# Other architectures should use ELF in embedded situations.
|
||||
elf = {};
|
||||
|
||||
androideabi = {};
|
||||
android = {
|
||||
assertions = [
|
||||
{ assertion = platform: !platform.isAarch32;
|
||||
message = ''
|
||||
The "android" ABI is not for 32-bit ARM. Use "androideabi" instead.
|
||||
'';
|
||||
}
|
||||
];
|
||||
};
|
||||
|
||||
gnueabi = { float = "soft"; };
|
||||
gnueabihf = { float = "hard"; };
|
||||
gnu = {
|
||||
assertions = [
|
||||
{ assertion = platform: !platform.isAarch32;
|
||||
message = ''
|
||||
The "gnu" ABI is ambiguous on 32-bit ARM. Use "gnueabi" or "gnueabihf" instead.
|
||||
'';
|
||||
}
|
||||
];
|
||||
};
|
||||
|
||||
musleabi = { float = "soft"; };
|
||||
musleabihf = { float = "hard"; };
|
||||
musl = {};
|
||||
|
||||
uclibceabihf = { float = "soft"; };
|
||||
uclibceabi = { float = "hard"; };
|
||||
uclibc = {};
|
||||
|
||||
unknown = {};
|
||||
};
|
||||
|
||||
################################################################################
|
||||
|
||||
types.parsedPlatform = mkOptionType {
|
||||
name = "system";
|
||||
description = "fully parsed representation of llvm- or nix-style platform tuple";
|
||||
merge = mergeOneOption;
|
||||
check = { cpu, vendor, kernel, abi }:
|
||||
types.cpuType.check cpu
|
||||
&& types.vendor.check vendor
|
||||
&& types.kernel.check kernel
|
||||
&& types.abi.check abi;
|
||||
};
|
||||
|
||||
isSystem = isType "system";
|
||||
|
||||
mkSystem = components:
|
||||
assert types.parsedPlatform.check components;
|
||||
setType "system" components;
|
||||
|
||||
mkSkeletonFromList = l: {
|
||||
"1" = if elemAt l 0 == "avr"
|
||||
then { cpu = elemAt l 0; kernel = "none"; abi = "unknown"; }
|
||||
else throw "Target specification with 1 components is ambiguous";
|
||||
"2" = # We only do 2-part hacks for things Nix already supports
|
||||
if elemAt l 1 == "cygwin"
|
||||
then { cpu = elemAt l 0; kernel = "windows"; abi = "cygnus"; }
|
||||
# MSVC ought to be the default ABI so this case isn't needed. But then it
|
||||
# becomes difficult to handle the gnu* variants for Aarch32 correctly for
|
||||
# minGW. So it's easier to make gnu* the default for the MinGW, but
|
||||
# hack-in MSVC for the non-MinGW case right here.
|
||||
else if elemAt l 1 == "windows"
|
||||
then { cpu = elemAt l 0; kernel = "windows"; abi = "msvc"; }
|
||||
else if (elemAt l 1) == "elf"
|
||||
then { cpu = elemAt l 0; vendor = "unknown"; kernel = "none"; abi = elemAt l 1; }
|
||||
else { cpu = elemAt l 0; kernel = elemAt l 1; };
|
||||
"3" = # Awkwards hacks, beware!
|
||||
if elemAt l 1 == "apple"
|
||||
then { cpu = elemAt l 0; vendor = "apple"; kernel = elemAt l 2; }
|
||||
else if (elemAt l 1 == "linux") || (elemAt l 2 == "gnu")
|
||||
then { cpu = elemAt l 0; kernel = elemAt l 1; abi = elemAt l 2; }
|
||||
else if (elemAt l 2 == "mingw32") # autotools breaks on -gnu for window
|
||||
then { cpu = elemAt l 0; vendor = elemAt l 1; kernel = "windows"; }
|
||||
else if hasPrefix "netbsd" (elemAt l 2)
|
||||
then { cpu = elemAt l 0; vendor = elemAt l 1; kernel = elemAt l 2; }
|
||||
else if (elem (elemAt l 2) ["eabi" "eabihf" "elf"])
|
||||
then { cpu = elemAt l 0; vendor = "unknown"; kernel = elemAt l 1; abi = elemAt l 2; }
|
||||
else throw "Target specification with 3 components is ambiguous";
|
||||
"4" = { cpu = elemAt l 0; vendor = elemAt l 1; kernel = elemAt l 2; abi = elemAt l 3; };
|
||||
}.${toString (length l)}
|
||||
or (throw "system string has invalid number of hyphen-separated components");
|
||||
|
||||
# This should revert the job done by config.guess from the gcc compiler.
|
||||
mkSystemFromSkeleton = { cpu
|
||||
, # Optional, but fallback too complex for here.
|
||||
# Inferred below instead.
|
||||
vendor ? assert false; null
|
||||
, kernel
|
||||
, # Also inferred below
|
||||
abi ? assert false; null
|
||||
} @ args: let
|
||||
getCpu = name: cpuTypes.${name} or (throw "Unknown CPU type: ${name}");
|
||||
getVendor = name: vendors.${name} or (throw "Unknown vendor: ${name}");
|
||||
getKernel = name: kernels.${name} or (throw "Unknown kernel: ${name}");
|
||||
getAbi = name: abis.${name} or (throw "Unknown ABI: ${name}");
|
||||
|
||||
parsed = rec {
|
||||
cpu = getCpu args.cpu;
|
||||
vendor =
|
||||
/**/ if args ? vendor then getVendor args.vendor
|
||||
else if isDarwin parsed then vendors.apple
|
||||
else if isWindows parsed then vendors.pc
|
||||
else vendors.unknown;
|
||||
kernel = if hasPrefix "darwin" args.kernel then getKernel "darwin"
|
||||
else if hasPrefix "netbsd" args.kernel then getKernel "netbsd"
|
||||
else getKernel args.kernel;
|
||||
abi =
|
||||
/**/ if args ? abi then getAbi args.abi
|
||||
else if isLinux parsed || isWindows parsed then
|
||||
if isAarch32 parsed then
|
||||
if lib.versionAtLeast (parsed.cpu.version or "0") "6"
|
||||
then abis.gnueabihf
|
||||
else abis.gnueabi
|
||||
else abis.gnu
|
||||
else abis.unknown;
|
||||
};
|
||||
|
||||
in mkSystem parsed;
|
||||
|
||||
mkSystemFromString = s: mkSystemFromSkeleton (mkSkeletonFromList (lib.splitString "-" s));
|
||||
|
||||
doubleFromSystem = { cpu, vendor, kernel, abi, ... }:
|
||||
/**/ if abi == abis.cygnus then "${cpu.name}-cygwin"
|
||||
else if kernel.families ? darwin then "${cpu.name}-darwin"
|
||||
else "${cpu.name}-${kernel.name}";
|
||||
|
||||
tripleFromSystem = { cpu, vendor, kernel, abi, ... } @ sys: assert isSystem sys; let
|
||||
optAbi = lib.optionalString (abi != abis.unknown) "-${abi.name}";
|
||||
in "${cpu.name}-${vendor.name}-${kernel.name}${optAbi}";
|
||||
|
||||
################################################################################
|
||||
|
||||
}
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user