11–16 of 16 posts
This is really exciting! What are the early performance gains looking like in nix compilation?
Since there's a target that depends on a generated source file for Nix's bison parser. But other targets incrementally compile comparably with regular ninja. So far we observed that Nix's sandboxing overhead is neglible.
This is really exciting! What are the early performance gains looking like in nix compilation?
A long term end goal is that if you don't change headers and only change is single C/C++, anywhere in the build graph for your entire system you should get a quick recompile of just that file + relink just the executables/shared libraries the output object file is built in.
This will require boiling an oceans, to get all the packages' build systems using Ninja or similar like this. But that's hopefully
- less boiling that rewriting the whole world of open source in Bazel/Buck2.
- a far more incremental, crowd-source-able project, as you could convert packages one-by-one, starting with big builds like LLVM and Chromium as Edgar says.
How long do we expect it to take dynamic derivations to get stabilized? The GitHub RFC says it's only 80% complete
The short version is that dynamic derivations depends on content-addressing derivations, and content-addressing derivations has been in experimental-feature limbo for a while now. However (!), with a little push + judicious cutting scope, we can get the latter stabilized. And then the remaining road to stable dynamic derivations should be very smooth.
It's a more complicated story to tell because the work is a series of yak shaves, but it's not actually a huge amount of work.
I'll probably get downvoted. But isn't that exactly what make does? specify how an output file should be made, and which input files it depends on.
Nix provides the toolchain and dependency management (like where boost is from), as well as ability to remotely execute it which makes it attractive to scale out large builds like a `-j 999`. Nix also lets you do things like patching boost and then recompiling both boost and the downstreams (incrementally and with early cut-off if using nix-ninja) all in one build graph.
All in all, probably not useful if you're not already needing features from Nix. But if you are, this should speed up your builds by a significant amount.
I'll probably get downvoted. But isn't that exactly what make does? specify how an output file should be made, and which input files it depends on.
No worries. I think Make vs Ninja is a whole another discussion but how it relates to this project is that Ninja has less features than Make (e.g. no globs, etc) which makes it attractive as a simple build graph format. Nix provides the toolchain and dependency management (like where boost is from), as well as ability to remotely execute it which makes it attractive to scale out large builds like a `-j 999`. Nix also…
Less features is probably good, because make originally was just the dependency thing, but got abused as a build system.
Any performance improvements such as incremental compilations / incremental builds / interpreters / copy-on-write / hot-code reloading are always welcome.