This changes our GHA CI and nix-store-tests packaging
to build and run the benchmarks. This does not affect
the default packaging - the overrides apply only for the
GHA CI.
GCC doesn't really benefit as much as Clang does from
using precompiled headers. Another aspect to consider is that
clangd doesn't really like GCC's PCH flags in the compilation database,
so GCC based devshells would continue to work with clangd.
This also has the slight advantage of ensuring that our includes are in
order, since we build with both Clang and GCC.
Instead of parsing a structured attrs at some later point, we parsed it
right away when parsing the A-Term format, and likewise serialize it to
`__json = <JSON dump>` when serializing a derivation to A-Term.
The JSON format can directly contain the JSON structured attrs without
so encoding it, so we just do that.
Add a new setting to warn about path literals that don't start with "." or "/". When enabled,
expressions like `foo/bar` will emit a warning suggesting to use `./foo/bar` instead.
A functional test is included.
The setting defaults to false for backward compatibility but could eventually default to true in
the future.
Closes: #13374
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
All of the existing tests only run on x86_64-linux and
the whole `nixpkgsFor` makes it hard to reuse those for
e.g. running the nixos tests with a sanitizer build of nix.
This rips off the bandaid and removes the `nixpkgsFor` parameter
in favor of a single instance of nixpkgs with a separate `nixComponents`.
This moves out the checks that get run in GHA CI into ci/gha/tests
folder and splits those into `topLevel` and `componentTests` attributes.
The idea behind this is to make it easier to parametrize tests that can
be run with sanitizers in order to run those as a matrix of jobs. The same
can be said for static builds.
Existing stdenv selection infrastructure via `lib.makeComponents` would
also allow us to switch over to using `clangStdenv` to significantly speed
up pre-merge CI (though the default stdenv would still be used for non-overridable
topLevel checks, like installer artifacts).
Prior patches in 54dc5314e8
and 6db6190002 fixed the default
system double for i686 and ppc/ppc64. This also patch also covers
32 bit arm and mips. ARM cpu names are taken from host_machine.cpu()
for a lack of a better option, but host_machine.cpu_family() is
preferred, since that is supposed to be somewhat standard for cross
files. Endianness is handled correctly by looking at host_machine.endian().
This also updates the documentation to be up to date to how system cpu
is translated from the host_machine specification.
Before this change, if you were cross compiling Nix, then the nix-manual
subproject would never get built. In some situations, it makes sense to
not build the nix-manual subproject when cross compiling. For example,
if the build system is x86_64 and the host system is riscv64, then it
makes sense to not build the manual. Building the manual requires
executing certain build artifacts, and you can’t run x86_64 executables
on riscv64 systems.
That being said, there are some situations where it does make sense to
build the nix-manual subproject when cross compiling. For example, if
the build system is x86_64 and the host system is i686, then it doesn’t
make sense to not build the manual. You can run i686 executables on
x86_64 systems just fine.
This change makes it so that the nix-manual subproject will sometimes
get built when cross compiling. Specifically, the nix-manual subproject
will get built as long as the doc-gen option is enabled and the build
system is capable of running host binaries.
---
The main motivation behind this change is to fix this Nixpkgs issue [1].
Building pkgs.nixStatic counts as cross compiling Nix, and
pkgs.nixStatic is supposed to produce a man output. Building
pkgs.nixStatic currently fails because it isn’t actually producing a man
output. That issue will go away once this commit gets backported to Nix
2.28.x.
[1]: <https://github.com/NixOS/nixpkgs/issues/426410>
SHA-256 is Git's next hash algorithm. The world is still basically stuck
on SHA-1 with git, but shouldn't be. We can at least do our part to get
ready.
On the C++ implementation side, only a little bit of generalization was
needed, and that was fairly straight-forward. The tests (unit and
system) were actually bigger, and care was taken to make sure they were
all cover both algorithms equally.
For regular, non-executable files, there is no str("") between str("regular")
and str("contents"). Note that str("") is exactly 8 zero bytes, while just ""
is actual empty string (0 bytes).
libfetchers uses `git_mempack_write_thin_pack` which was introduced in libgit2-1.9.0
This avoids error like:
../src/libfetchers/git-utils.cc: In member function ‘virtual void nix::GitRepoImpl::flush()’:
../src/libfetchers/git-utils.cc:270:13: error: ‘git_mempack_write_thin_pack’ was not declared in this scope
270 | git_mempack_write_thin_pack(mempack_backend, packBuilder.get())
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
on older libgit2 (like 1.7.2 in Centos Stream 10)
If the reference for git+file is an annotated tag, the revision will
differ than when it's fetched using other fetchers such as `github:`
since Github seems to automatiacally peel to the underlying commit.
Turns out that rev-parse has the capability through it's syntax to
request the underlying commit by "peeling" using the `^{commit}` syntax.
This is safe to apply in all scenarios where the goal is to get an
underlying commit.
fixes#11266
I've missed this while reviewing 6db6190002.
I only built big endian ppc64, so that didn't occur to me.
From meson manual:
> Those porting from autotools should note that Meson does not add
> endianness to the name of the cpu_family. For example, autotools will
> call little endian PPC64 "ppc64le", Meson will not, you must also check
> the .endian() value of the machine for this information.
This code should handle that correctly.
