3 ms·
I built a dependency checker that worked similarly to this once. By hooking the filesystem calls, you can make a list of all files that a given process touches
by cecilpl2 6y ago
I built a dependency checker that worked similarly to this once.
By hooking the filesystem calls, you can make a list of all files that a given process touches. When that process finishes, serialize a dependency file containing the hashes, timestamps, and sizes of all those files. Next time you run that same command line, read the dependency file from the last run and compare to the current filesystem state. If it's the same, and you know your command is idempotent, you can skip execution entirely.
Now, if you put that logic in a dll, you can inject it into arbitrary third-party processes to which you don't have source code and it will still work. Name the dependency file after the hash of the command line.
- phone8675309 6y agoThe ClearCase SCM does something similar - it has the notion of "derived objects" and "audited builds". You can run an audited build command under a special ClearCase wrapper and it will look at the versions of the elements used in the build - if that build has already occurred with the same input elements before, even if in a different view, it can "wink in" the derived object result - that is, it can cause that previous build to be visible in your current view. This can save a lot of time when you're building a large codebase.