wroclaw-git-backups/nix
1
0
Fork 0
mirror of https://github.com/NixOS/nix synced 2025-06-25 06:31:14 +02:00
Code Activity

build step -> build rule

Browse source 
"step" sounds atomic, while "rule" hints at internal structure, which in
our case consists of mapping inputs to outputs using build instructions.
This commit is contained in:
Valentin Gagarin 2022-05-03 14:06:51 +02:00
parent 87523f01e3
commit 902638c519
2 changed files with 7 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

7
doc/manual/src/architecture/architecture.md
View file

@ -27,7 +27,7 @@ Nix consists of hierarchical [layers](https://en.m.wikipedia.org/wiki/Multitier_
At the top is the *command line interface*, translating from invocations of Nix executables to interactions with the underlying layers.
Below that is the *Nix language*, a [purely functional](https://en.m.wikipedia.org/wiki/Purely_functional_programming) configuration language.
It is used to compose expressions which ultimately evaluate to self-contained *build plans*, used to derive *build results* from referenced *build inputs*.
It is used to compose expressions which ultimately evaluate to self-contained *build rules*, used to derive *build results* from referenced *build inputs*.
::: {.note}
The Nix language itself does not have a notion of *packages* or *configurations*.
@ -37,6 +37,7 @@ In practice this amounts to a set of files in a file system.
The command line and Nix language are what users interact with most.
Underlying everything is the *Nix store*, a mechanism to keep track of build plans, data, and references between them.
It can also execute *build instructions*, captured in the build plans, to produce new data.
Underlying everything is the *Nix store*, a mechanism to keep track of build rules, data, and references between them.
It can also execute *build instructions*, captured in the build rules, to produce new data.
A series of build rules is a *build plan*.