Unexpected massive memory usage when evaluating a derivation from a cross compiling nixpkgs

Mic92 · August 24, 2024, 8:57am

I think it’s known that cross-compiling evaluates slower. However I didn’t knew it was that much slower.
The main code that handles that is here:

github.com

NixOS/nixpkgs/blob/67602af1d270803422a53bec44a96c6985b102e5/pkgs/top-level/splice.nix

# The `splicedPackages' package set, and its use by `callPackage`
#
# The `buildPackages` pkg set is a new concept, and the vast majority package
# expression (the other *.nix files) are not designed with it in mind. This
# presents us with a problem with how to get the right version (build-time vs
# run-time) of a package to a consumer that isn't used to thinking so cleverly.
#
# The solution is to splice the package sets together as we do below, so every
# `callPackage`d expression in fact gets both versions. Each derivation (and
# each derivation's outputs) consists of the run-time version, augmented with
# a `__spliced.buildHost` field for the build-time version, and
# `__spliced.hostTarget` field for the run-time version.
#
# For performance reasons, rather than uniformally splice in all cases, we only
# do so when `pkgs` and `buildPackages` are distinct. The `actuallySplice`
# parameter there the boolean value of that equality check.
lib: pkgs: actuallySplice:

let

This file has been truncated. show original

“Splicing” select host and build dependencies in a hacky way. You can read about more complaints here: Frustrations about splicing