hello neighbors : )
see my working prototype for cmake/ninja builds in
splitBuildInstall: split buildPhase and installPhase for large packages
im using this, to reduce the installPhase feedback loop from 2 hours to 2 minutes : )
(one minute is wasted to copy 3 GByte of cached source + build files)
related ycombinator: Bazel – Correct, reproducible, fast builds for everyone
Conceptually, your build results should be a pure function of your source tree.
it’s designed so that code generators should act as pure functions from input files to output files … Writing generators to run this way is kind of a pain, actually, sort of like writing code to run in a sandbox. Also, the generators themselves must be checked in, and often built from source. But we consider the results worth it.
Build artifacts are cached … The problem with maven and gradle is that their build actions/plugins can have have unobservable side effects.
This approach is more ‘pure functional’. You have rules which take inputs, run actions, produce outputs and memoize them. If inputs don’t change, then you use memoized outputs and don’t run the action.
As long as your actions produce observable side effects in the outputs (and don’t produce side effects which are not part of the outputs, but product state which depended upon in some manner), then you can do a lot of optimizations on this graph.
one challenge with nix:
output paths are variables, which are also included in binary files (*.so etc)
so we need to isolate the compilation objects, and patch them back together …
as a bonus, this would allow distributed object compilation,
instead of just distributed package compilation