build rule -> build task

closer to "build systems a la carte", satisfies all other complaints
This commit is contained in:
Valentin Gagarin 2022-05-09 16:39:26 +02:00
parent 902638c519
commit 2a8532fb61
2 changed files with 8 additions and 8 deletions

View file

@ -19,7 +19,7 @@ Nix consists of hierarchical [layers](https://en.m.wikipedia.org/wiki/Multitier_
| | evaluates to |
| | |
| referenced by V builds |
| [ build input ] ----> [ build plan ] ----> [ build result ] |
| [ build input ] --> [ build task ] --> [ build result ] |
| |
+-----------------------------------------------------------------+
```
@ -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 rules*, used to derive *build results* from referenced *build inputs*.
It is used to compose expressions which ultimately evaluate to self-contained *build tasks*, used to derive *build results* from referenced *build inputs*.
::: {.note}
The Nix language itself does not have a notion of *packages* or *configurations*.
@ -37,7 +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 rules, data, and references between them.
It can also execute *build instructions*, captured in the build rules, to produce new data.
Underlying everything is the *Nix store*, a mechanism to keep track of build tasks, data, and references between them.
It can also execute *build instructions*, captured in the build tasks, to produce new data.
A series of build rules is a *build plan*.
A series of build tasks is a *build plan*.

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 rules.
These store objects can hold arbitrary data, and Nix makes no distinction if they are used as build inputs, build results, or build tasks.
A Nix store allows adding, retrieving, and deleting store objects.
It can perform builds, that is, transform build inputs using instructions from the build rules into build outputs.
It can perform builds, that is, transform build inputs using instructions from the build tasks 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 rule | derivation | [action](https://bazel.build/reference/glossary#action) | `Task` | [thunk](https://en.m.wikipedia.org/wiki/Thunk)
build task | 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