// If you are working on a project, edit some files, and then // perform a mk, if files you haven't changed get built, I for // one would constantly question myself, about whether or // not I changed that file. It would make things confusing.
It's confusing because it doesn't match your expectations, but that's just as much because you're misunderstanding the intent of the tool. mk is not a tool for checking for changes, it is a tool for ensuring things are up to date. It just isn't designed to provide what you're looking for. That isn't to say that what you're looking for is unreasonable, but mk is not the tool to provide it. As an aside, I'd suggest learning to simply not worry about it. Internalize the fact that mk will sometimes rebuild things that don't strictly need it, but will ensure that things are up to date, and you'll have an easier time of it. // I for one favor practical usefulness over theoretical // correctness. You have not demonstrated anything that significantly impacts mk's practical usefullness. The fact that mk will, in some cases, rebuild things which don't need it doesn't significantly impact its utility for its intended purpose. In Plan 9, the heirarchy of values is different from other systems. Correctness (theoretical or otherwise) and elegance come above utility. That's not to say there are no tradeoffs in the system, but if you're going to give up even a little bit of correctness or elegance (environment variables?!?), you'd best be prepared to demonstrate a rather substantial utility gain. Given how much use this community has gotten out of mk over the past ~27 years, I think it's safe to say we're not sold. Anthony
