Inotify (and various equivalent change notification mechanisms on other systems) is probably ideal, but needs a fallback for a cold start. If a cold start isn’t the common case (as it is in Make), using slower cryptographic hashing instead of less reliable mtimes might be a good tradeoff. But I don’t think you could marry this to Make without major surgery. (Tup, mentioned elsethread, is this + automatic dependencies based on syscall tracing.)

This is not what the article is about, however,—it’s about building a build-input-addressable artifact cache that can be shared across machines, à la Bazel or Nix. (That Nix is a build system—and NixOS is a distro built on said build system, the same way that Gittup is built on Tup, the BSDs on Make, or Gentoo on its thing—seems to be a well-kept secret. The distinguishing idea that in that case “build artifact cache” = “binary repo” is brilliant, though.)

What I don’t get is what purpose Make serves in the context of the article: when the build process turns a whole bunch of files into one with no intermediate steps or separate compilation, it seems a plain shell script would do just as well as Make + auxiliary shell scripts. You could perhaps obtain some more structure (less strict source ordering?) with Make, but the article doesn’t seem to do that.

Any non-trivial project would quickly reach RLIMIT_NOFILE as inotify is non-recursive, so you'd need to open a new fd for each monitored file.