Building without tests is useful for bootstrapping with a smaller footprint
or running the tests in a separate derivation. Otherwise, we do compile and
run them.
This isn't fine grained as to allow picking `check` but not `installcheck`
or vice versa, but it's good enough for now.
I've tried to use Nixpkgs' `checkInputs`, but those inputs weren't discovered
properly by the configure script. We can emulate its behavior very well though.
Some dependencies supposed to be skipped in the cross build, along with
not using the gold linker. But in https://github.com/NixOS/nix/pull/6538
this was accidentally not preserved.
Also since https://github.com/NixOS/nix/pull/6538 we saw some new
aarch64-linux static build failures. This is a first attempt to try to
fix those failures. If this is not sufficient, there are other things we
can try next.
- `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>
The issue *seems* to be the cross jobs, which are missing the `CXXFLAGS`
needed to get rapidcheck.
PR #6538 would be really nice to resurrect which will prevent the
`configureFlags` from going out of sync between the regular build and
the cross build again.
mdbook-linkcheck is not consistent about its warning setting.
It disables some warnings, but not the warnings about lack of
fragment checking support; hence the extra filtering.
This runs the installer in a QEMU VM. Unlike the old installer test
that ran inside a declaratively built RedHat/Debian image, this uses
an image from Vagrant.
With this, Nix will write a copy of the sandbox shell to /bin/sh in
the sandbox rather than bind-mounting it from the host filesystem.
This makes /bin/sh work out of the box with nix-static, i.e. you no
longer get
/nix/store/qa36xhc5gpf42l3z1a8m1lysi40l9p7s-bootstrap-stage4-stdenv-linux/setup: ./configure: /bin/sh: bad interpreter: No such file or directory
Python is only pulled into the build closure by Mercurial, which might end up being removed.
Let’s port the script to jq, which is more likely to stay.
Apart from a slight simplification and a bit of dogfooding, this also
make the cache behavior more predictable.
For example `nix build .` and `nix build nix/$(git rev-parse HEAD)` will
yield the exact same path, while their “intuitive” non-flake equivalents
(`nix-build` and
`nix-build https://github.com/nixos/nix/archives/$(git rev-parse HEAD).tar.gz`)
don’t.
This was a pain for example in https://github.com/NixOS/nix/pull/5059
Also, the `bar-with-logs` log format is imho nicer (even in an
non-interactive context) because prefixing each log line with the name
of the derivation that produced it makes it much easier to follow what’s
going on.
We explicitly hack around to remove them, so might as well check that
the hack is useful.
(Introduced because I feared that the changes of
https://github.com/NixOS/nix/pull/5906#discussion_r784810238 would bring
back some runtime references)
For a (currently hardcoded and limited) list of stdenvs,
make `.#$nix-${stdenvName}` correspond to a Nix built with the
corresponding stdenv.
For example, `.#nix-${clang11Stdenv}` is Nix built with clang11.
Likewise, `devShells.x86_64-linux.clang11StdenvPackages` is a development
shell for Nix with clang11, that can be used with
```shell
nix develop .#clang11StdenvPackages
```
Fix#4129
/cc @pamplemousse
Fixes the problem where a stack pointer outside the original
thread causes the collector to crash.
It could be made more accurate by recording the stack pointer
every time we switch to a coroutine. We can use this information
to update our own coroutine stacks like normal data. When the
stack pointer is on a thread, we can add a field to GC_thread
"fallback_sp" to be used when the thread sp is outside the original
thread range.
