Without this, it reads as FUD.
Compiler (and standard library) might be changed to do testing with multiple compilers (very common use-case).
Often Makefiles are not written with these two cases in mind, forcing a "clean" between changes.
From the article: "In determining when to rebuild, Make uses the timestamps of build inputs rather than their hashes. This results in many unnecessary rebuilds when a file has been touched, but has not actually changed. If this happens deep in the dependency tree, then the rebuild will take a long time!"
That's kinda clear to me -- why would this read as FUD?
From article:
> Since You’re Here > We recently announced BuildInfer, a new tool to optimize your C/C++ build scripts. Take a look!
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 ...
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 ...
timestamps really sucks when e.g. you change header $foo which is used by a lot of your software (say, a basic data structure, or the definition of a 3d point), build (which rebuilds everything because of time stamps), do a git pull --rebase, so git undoes your changes, applies the remote commits, and redoes your change, and so you re-have to build everything again even though the header that was used everywhere has not actually changed
After a rebase it makes sense too, but I see what you mean about where no actual changes have been made though ... dare I suggest this sounds more like a bug in git though ...
yes, me too, but in this case the rebuild happens twice while the header changes only once (from the point of view of the programmer of course, from the point of view of the filesystem it changes twice). If hashes were used this would not be a problem at all.
header.h
src1.cpp
src2.cpp
src3.cpp
1. change header.h
2. rebuild. this rebuilds all your .cpp because they all use the header - this is fine and expected.
3. git pull --rebase because your coworker fixed a bug in src1.cpp which landed in the master branch
4. here when you rebuild with make, even though only src1.cpp has changed from your point of view, everything actually gets rebuilt because git stashes your change, applies the remote commits and unstashes your change, so header.h's timestamp gets changed again.
W̶h̶i̶c̶h̶ ̶b̶u̶i̶l̶d̶ ̶s̶y̶s̶t̶e̶m̶s̶ ̶a̶c̶t̶u̶a̶l̶l̶y̶ ̶d̶o̶ ̶t̶h̶i̶s̶?̶ [answered by sibling comment]
For the record I definitely understand what the author is trying to point out, but I think they could be much more convincing.
I'd think the far more usual case is each dev has a copy of the code on his/her own machine, and another copy is on a build/test machine. There won't be any timestamp issues there.
Make is like a lot of tools, it's simple and works well, up to a point. If your project complexity exceeds its abilities, you likely can afford something more sophisticated, since you probably have dozens or hundreds of developers anyway.
For the most part though, you're right!