| Age | Commit message (Collapse) | Author |
|---|
|
Here's my guide so far:
$ rg '((?!(recursive).*) Nix
(?!(daemon|store|expression|Rocks!|Packages|language|derivation|archive|account|user|sandbox|flake).*))'
-g '!doc/' --pcre2
All items from this query have been tackled. For the documentation side:
that's for https://git.lix.systems/lix-project/lix/issues/162.
Additionally, all remaining references to github.com/NixOS/nix which
were not relevant were also replaced.
Fixes: https://git.lix.systems/lix-project/lix/issues/148.
Fixes: https://git.lix.systems/lix-project/lix/issues/162.
Change-Id: Ib3451fae5cb8ab8cd9ac9e4e4551284ee6794545
Signed-off-by: Raito Bezarius <raito@lix.systems>
|
|
This breaks downstreams linking to us on purpose to make sure that if
someone is linking to Lix they're doing it on purpose and crucially not
mixing up Nix and Lix versions in compatibility code.
We still need to fix the internal includes to follow the same schema so
we can drop the single-level include system entirely. However, this
requires a little more effort.
This adds pkg-config for libfetchers and config.h.
Migration path:
expr.hh -> lix/libexpr/expr.hh
nix/config.h -> lix/config.h
To apply this migration automatically, remove all `<nix/>` from
includes, so: `#include <nix/expr.hh>` -> `#include <expr.hh>`. Then,
the correct paths will be resolved from the tangled mess, and the
clang-tidy automated fix will work.
Then run the following for out of tree projects:
```
lix_root=$HOME/lix
(cd $lix_root/clang-tidy && nix develop -c 'meson setup build && ninja -C build')
run-clang-tidy -checks='-*,lix-fixincludes' -load=$lix_root/clang-tidy/build/liblix-clang-tidy.so -p build/ -fix src
```
Related: https://git.lix.systems/lix-project/nix-eval-jobs/pulls/5
Fixes: https://git.lix.systems/lix-project/lix/issues/279
Change-Id: I7498e903afa6850a731ef8ce77a70da6b2b46966
|
|
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
|
|
This commit makes Meson the default buildsystem for Lix.
The Make buildsystem is now deprecated and will be removed soon, but has
not yet, which will be done in a later commit when all seems good. The
mesonBuild jobs have been removed, and have not been replaced with
equivalent jobs to ensure the Make buildsystem still works.
The full, new commands in a development shell are:
$ meson setup ./build "--prefix=$out" $mesonFlags
(A simple `meson setup ./build` will also build, but will do a different
thing, not having the settings from package.nix applied.)
$ meson compile -C build
$ meson test -C build --suite=check
$ meson install -C build
$ meson test -C build --suite=installcheck
(Check and installcheck may both be done after install, allowing you to
omit the --suite argument entirely, but this is the order package.nix
runs them in.)
If tests fail and Meson helpfully has no output for why, use the
`--print-error-logs` option to `meson test`. Why this is not the default
I cannot explain.
If you change a setting in the buildsystem, most cases will
automatically regenerate the Meson configuration, but some cases, like
trying to build a specific target whose name is new to the buildsystem
(e.g. `meson compile -C build src/libmelt/libmelt.dylib`, when
`libmelt.dylib` did not exist as a target the last time the buildsystem
was generated), then you can reconfigure using new settings but
existing options, and only recompiling stuff affected by the changes:
$ meson setup --reconfigure build
Note that changes to the default values in `meson.options` or in the
`default_options :` argument to project() are NOT propagated with
`--reconfigure`.
If you want a totally clean build, you can use:
$ meson setup --wipe build
That will work regardless of if `./build` exists or not.
Specific, named targets may be addressed in
`meson build -C build <target>` with the "target ID" if there is one,
which is the first string argument passed to target functions that
have one, and unrelated to the variable name, e.g.:
libexpr_dylib = library('nixexpr', …)
can be addressed with:
$ meson compile -C build nixexpr
All targets may be addressed as their output, relative to the build
directory, e.g.:
$ meson compile -C build src/libexpr/libnixexpr.so
But Meson does not consider intermediate files like object files
targets. To build a specific object file, use Ninja directly and
specify the output file relative to the build directory:
$ ninja -C build src/libexpr/libnixexpr.so.p/nixexpr.cc.o
To inspect the canonical source of truth on what the state of the
buildsystem configuration is, use:
$ meson introspect
Have fun!
Change-Id: Ia3e7b1e6fae26daf3162e655b4ded611a5cd57ad
|
|
hacking changelog-d to support not just github but also forgejo and
gerrit is a lot more complicated than it's worth, even moreso since
the entire thing can just as well be done with ~60 lines of python.
this new script is also much cheaper to instantiate (being python),
so having it enabled in all shells is far less of a hassle.
we've also adjusted existing release notes that referenced a gerrit
cl to auto-link to the cl in question, making the diff a bit bigger
closes https://git.lix.systems/lix-project/lix/issues/176
Change-Id: I8ba7dd0070aad9ba4474401731215fcf5d9d2130
|
|
Remove `clang11Stdenv`
(cherry picked from commit cbf99c71c6f58579174c1c7649a5421c1d2ba9b0)
Change-Id: I716ce1a54f2006c4a9dc9716e8529fe7858ecebb
|
|
rl-next: Fix and support markdown frontmatter syntax
(cherry picked from commit 69b7876a0810269ad71807594cfd99b26cd8a5ff)
Change-Id: I8bfb8967af0943080fdd70d257c34abaf0a9fedf
|
|
Use `buildprefix` in a few more places
(cherry picked from commit b6a3fde6b7a416929553e6be36fc991680ddf9ef)
Change-Id: I2790663fa9f8242ac2db6582b7e421d2fdf42942
|
|
Automatically compile hand-written release notes with `changelog-d`
(cherry picked from commit 928f0c13414d20c1af88b30bd6700fd730ee0bab)
Change-Id: Ia0685835c52edf185b64dd696b19305746c077e5
|
|
Get rid of `bootstrap.sh`
(cherry picked from commit aaef47a08eaf54a8856dd25c784fd85d8d7b0e22)
Change-Id: I1a74bed0c23d6fda06d5dfd8ecad443b9122da12
|
|
|
|
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
|
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
|
|
|
`hacking.md` has gotten really big!
|
|
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
|
|
|
|
|
|
|
e.g. nix-env -e subversion => nix-env --uninstall subversion
The aim is to make the documentation less cryptic for newcomers and the
long options are more self-documenting.
The change was made with the following script:
<https://github.com/aschmolck/convert-short-nix-opts-to-long-ones>
and sanity checked visually.
|
|
|
|
doc/hacking.md: Corrections and additions for cross
|
|
|
|
- `nixpkgsFor` does all of native, static, cross, and the different stdenvs.
- The main Nix derivation is no longer duplicated for static.
- DRY nixpkgs.lib and lib.genAttrs calls.
|
|
- Refer to current version in readme
- Split into flakes and non-flakes section
- Change order to move nix-build to the end, since people often start
with it in the beginning.
- Use proper "Note" syntax
- Add notes about editor integration
- Move information about target platforms and stdenvs into separate
sections
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Alexander Bantyev <alexander.bantyev@tweag.io>
Co-authored-by: Théophane Hufschmitt <theophane.hufschmitt@tweag.io>
|
|
Use a pipe for all install commands
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|
`clang11StdenvPackages` does not exist
```
│ └───x86_64-linux
│ ├───ccacheStdenv: development environment 'nix'
│ ├───clang11Stdenv: development environment 'nix'
│ ├───clangStdenv: development environment 'nix'
│ ├───default: development environment 'nix'
│ ├───gccStdenv: development environment 'nix'
│ ├───libcxxStdenv: development environment 'nix'
│ └───stdenv: development environment 'nix'
```
|
|
Property tests are great!
Co-authored-by: Cole Helbling <cole.e.helbling@outlook.com>
|
|
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|
|
|
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|
|
|
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|
First, logic is consolidated in the shell script instead of being spread
between them and makefiles. That makes understanding what is going on a
little easier.
This would not be super interesting by itself, but it gives us a way to
debug tests more easily. *That* in turn I hope is much more compelling.
See the updated manual for details.
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
|
|
|
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|
when using ccache, rebuild time has been measured
89% faster while not slowing the speed of cold builds
|
|
Mainly:
- Try to triangulate between narrative that framed this as
a new/easy process and the need for a reference that will
not quickly grow stale.
- Fix a ~continuity issue where the text was talking about
"your Cachix cache" before saying that you'd need to make
a Cachix cache to enable the installer tests.
- Adopt suggestion on titling, and nest subtitles in the
installer test section.
|
|
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|
|
|
As asked in <https://github.com/NixOS/nix/pull/6517#discussion_r869416905>
|
|
- Make it clear what the different kind of tests are, where they live
and how they can be ran
- Ask people to primarily write unit tests
|
|
Signed-off-by: Pamplemousse <xav.maso@gmail.com>
|
|
|
