Even with a well-specified dependency tree there are areas where an incremental build can still bite you in the ass. Things like inlining and transitive dependencies ... I think you still need to build from scratch to be sure.
- A: Builds well for small projects, scales poorly for large projects
- B: Builds well for small projects and scales well for large projects
Why not choose B?
EDIT my proposition is that the described build system actually scales poorly for large projects, because you've to maintain an entire tree of hashes! Notwithstanding of course having a helper process in the background to do this for me ...
Two bullet points jumped out at me straightway:
- Single monolithic code tree with mixed language code
- Development on head; all releases from source
Just one other concern I have now.
Something like Make, or most other build-systems run pretty much straight out of the box.
Something like Bazel lets say is apparently an order of magnitude more complicated. There's a few more moving parts.
My only remaining qualm relates to the additional cognitive load of this stuff. At scale, as in Google this isn't so much a problem because these costs would diminish at the point where you can actually assign people to look after it.
I really like the idea though! Would be nice to work in a place like Google some day ...
In my experience this kind of incremental build is a matter of developer convenience so that small changes can be made and checked quickly, but builds for test and release are always built clean.
I guess the codebases we're talking about here are at such a scale that the incremental approach is actually used for releases too?
It still seems to me as though this is something that s should be solved architecturally though with an appropriate composition of modules ...