| Age | Commit message (Collapse) | Author |
|---|
|
This doesn't comprehensively fix everything outdated in the manual, or
make the manual greatly better, but it does note down where at least
jade noticed it was wrong, and it does fix all the instances of
referencing Nix to conform to the style guide to the best of our
ability.
A lot of things have been commented out for being wrong, and there are
three types of FIXME introduced:
- FIXME(Lix): generically Lix needs to fix it
- FIXME(Qyriad): re https://git.lix.systems/lix-project/lix/issues/215
- FIXME(meson): docs got outdated by meson changes and need rewriting
I did fix a bunch of it that I could, but there could certainly be
mistakes and this is definitely just an incremental improvement.
Fixes: https://git.lix.systems/lix-project/lix/issues/266
Change-Id: I5993c4603d7f026a887089fce77db08394362135
|
|
The big ones here are `trim-trailing-whitespace` and `end-of-file-fixer`
(which makes sure that every file ends with exactly one newline
character).
Change-Id: Idca73b640883188f068f9903e013cf0d82aa1123
|
|
|
|
The targets I could find.
|
|
this is to help reading the diagrams, otherwise arrows and labels were
reported as being ambiguous.
|
|
|
|
the language has its own overview page where its properties are
described in sufficient detail.
|
|
this will at some point enable rendering them nicely for the web
|
|
Co-authored-by: Bryan Honof <bryan.honof@tweag.io>
|
|
|
|
these changes were not merged properly and had to be reverted.
see merge commit d8e54d19f71f78540dd967b2e42be6a5d8a0b1bb for full
history leading up to here.
|
|
This reverts commit 81e101345fda2a8651c470f08b364a1ca6fa37cf, reversing
changes made to 7d1280bbaf7f4cd142c2259dec620c42bf6f96fd.
|
|
So we can iterate without worrying so much.
|
|
|
|
|
|
|
|
while it appears a bit much for the overview, this way we set the stage
for going directly into data types when describing the store, instead of
first having to say what build tasks are and how they relate to build
plans.
|
|
do not introduce build tasks yet, that is the next level of detail.
|
|
|
|
this displays correct composition again. build inputs and build results
are not part of build plans in terms of data objects.
also this is a much less complicated setup. this will be the first
impression of architecture, and we want to get it right.
|
|
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
|
the overview should only link to the three main concepts presented. the
store is now fairly fleshed out. others can follow later.
|
|
|
|
update summary title to match file contents
|
|
|
|
closer to "build systems a la carte", satisfies all other complaints
|
|
"step" sounds atomic, while "rule" hints at internal structure, which in
our case consists of mapping inputs to outputs using build instructions.
|
|
|
|
|
|
attempt to explain used and documented terminology, as well as how
the declarative programming paradigm relates to building software.
in the future one could highlight encouraged terms to shape future
material into higher consistency.
|
|
following ideas found in Architecture of Gazelle[1]
[1]: https://github.com/bazelbuild/bazel-gazelle/blob/56d35f8db086bb65ef876f96f7baa7b71516daf8/Design.rst
|
