diff options
| -rw-r--r-- | doc/manual/src/architecture/architecture.md | 7 | ||||
| -rw-r--r-- | doc/manual/src/architecture/store/store.md | 6 |
2 files changed, 7 insertions, 6 deletions
diff --git a/doc/manual/src/architecture/architecture.md b/doc/manual/src/architecture/architecture.md index a0aa713f3..81348c570 100644 --- a/doc/manual/src/architecture/architecture.md +++ b/doc/manual/src/architecture/architecture.md @@ -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*. diff --git a/doc/manual/src/architecture/store/store.md b/doc/manual/src/architecture/store/store.md index cbb5a4169..b03aa690e 100644 --- a/doc/manual/src/architecture/store/store.md +++ b/doc/manual/src/architecture/store/store.md @@ -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 |