I’ve been using nix recently for building static versions of Dawn for Linux.
I really enjoy the simplicity of the .nix expression language and definition files. Being into the idea of statically-compiled code I use musl and oh wow does it take a very long time to build/start a nix-shell. We’re talking ~1h on a 16 CPU Ryzen 3950x. But once it’s built, starting a nix-shell is reasonably quick (~1s.)
The one big issue I’ve had with nix is that it uses the host machine as its base layer (I assume they use overlayfs) and it leaks through! I.e. the same exact .nix recipe run on two different machines may yield different outcomes, which “defies” a key selling point of nix. Someone pointed out to me that I could use buildFHSUserEnv but it does not seem to be compatible with musl or some of the packages I need (llvm 13, musl, cmake, ninja, python, x11).
Anyhow, I find it a great alternative to Docker for build environments (especially since docker runs as root on Linux and does not do uid/gid mapping) and I’ll keep using nix I think.
In what way do you mean it leaks through? I thought that as long as you use pinning/hashes/flakes your whole environment+versions is a part of the package definition. Or do you mean something like different CPUs result in different optimisation which results in different ordering / other details?
“inside” the nix shell things like the host system’s /usr/lib directory is available. This caused issues for me with some build scripts that would go look in those “standard” locations and as a result link against libs from the host system. I believe the idea is that every nix tool e.g. gcc or cmake is built to only consider /nix/ stores but as soon as you run something that wasn’t patched for nix (in my case dawn and depot_tools) you start getting into trouble. Just gotta be conscious about it though and explicitly specify locations of things.