4 ms·

Maybe not as portable, but isn't inotify better for this?

by _joel 4y ago

mananaysiempre 4y ago
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.
- pondidum 4y ago
  To address the purpose of make, this was written with a large multi workspace typescript project in mind: in the real project, there are many more make targets with dependencies on each other, and we don't want to waste time rebuilding the different workspaces if they haven't changed. I wasn't sure whether including all that extra information in the post was worth it or not, so I hope this answers your question
fbanon 4y ago
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.

Maybe not as portable, but isn't inotify better for this?

by _joel 4y ago

Maybe not as portable, but isn't inotify better for this?

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.

pondidum 4y ago
To address the purpose of make, this was written with a large multi workspace typescript project in mind: in the real project, there are many more make targets with dependencies on each other, and we don't want to waste time rebuilding the different workspaces if they haven't changed. I wasn't sure whether including all that extra information in the post was worth it or not, so I hope this answers your question

fbanon 4y ago

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.