I’m currently working on a build tool, which does caching based on the last-modified timestamp of files. And yeah, man, I was prepared for a world of pain, where I’d have to store a list of all files, so I could tell when one of them disappears.
I probably would’ve also had to make up some non-existent last-modified timestamp to try to pretend I know when that file got deleted. I figured, there’s no way to ask the deleted file when it got deleted, because it doesn’t exist anymore.
Thank you, to whomever had that smart idea to design it like that. I can just take the directory last-modified timestamp now, if it’s the highest value.
In fact, my implementation accidentally does this correct already. That’s how I found out. 🫠
Yeah, I’m building more-or-less an alternative to
make. Major difference is that I’m not using shell commands, but rather users will define their build code in Rust …because it’s intended to be a build tool for Rust applications (beyond whatcargodoes).Thanks for the comment, though. So far, I haven’t limited inputs to just be files, so I don’t actually assume to have a last-modified timestamp. Rather, my assumption is that I can get some value which changes when the input changes. In the case of a file, that’s the last-modified timestamp, but theoretically, it could also be a hash. But that means I have to store these values to be able to detect a change. Being able to just say that one thing is newer than the other without storing anything, that is pretty cool and might be worth changing my assumption for.