puck/lix
0
0
Fork 0
forked from lix-project/lix
Code Pull requests 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
Show stats 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*.

6
doc/manual/src/architecture/store/store.md
View file

@ -2,10 +2,10 @@
A Nix store is a collection of [store objects](objects.md) with associated operations.
These store objects can hold arbitrary data, and Nix makes no distinction if they are used as build inputs, build results, or build plans.
These store objects can hold arbitrary data, and Nix makes no distinction if they are used as build inputs, build results, or build rules.
A Nix store allows adding, retrieving, and deleting store objects.
It can perform builds, that is, transform build inputs using instructions from the build plans into build outputs.
It can perform builds, that is, transform build inputs using instructions from the build rules into build outputs.
It also keeps track of *references* between data and can therefore garbage-collect unused store objects.
There exist different types of stores, which all follow this model.
@ -28,7 +28,7 @@ generic build system | Nix | [Bazel](https://bazel.build/start/bazel-intro) | [B
-- | -- | -- | -- | --
data (build input, build result) | store object | [artifact](https://bazel.build/reference/glossary#artifact) | value | value
build instructions | builder | ([depends on action type](https://docs.bazel.build/versions/main/skylark/lib/actions.html)) | function | function
build step | derivation | [action](https://bazel.build/reference/glossary#action) | `Task` | [thunk](https://en.m.wikipedia.org/wiki/Thunk)
build rule | derivation | [action](https://bazel.build/reference/glossary#action) | `Task` | [thunk](https://en.m.wikipedia.org/wiki/Thunk)
build plan | derivation graph | [action graph](https://bazel.build/reference/glossary#action-graph), [build graph](https://bazel.build/reference/glossary#build-graph) | `Tasks` | [call graph](https://en.m.wikipedia.org/wiki/Call_graph)
build | build | build | application of `Build` | evaluation
persistence layer | store | [action cache](https://bazel.build/reference/glossary#action-cache) | `Store` | heap