Generally speaking a lot of .PHONY targets require information that the build system, and build system alone has. You would have to replicate that information i

Generally speaking a lot of .PHONY targets require information that the build system, and build system alone has. You would have to replicate that information in the scripts if you wanted them to work, which is at the very least a messy situation, and somewhat defeats part of the purpose of using tup in the first place. This is obvious for targets like `clean` - hence why you suggest it should be supported in the build system - but most phony's require a certain amount of information from the build system. I also disagree on `install`. `install` is useful for creating packages in the first place. The build system already knows (or is told) which files are suppose to go in which general locations (configured via environment variables for the paths) and then install the correct files for your configuration. It is easy enough to use this to create a package by installing into a separate directory then /. The key is that the build system knows all the information to make `install` work as wanted (Along with being provided some paths). Separate scripts would not. Providing nothing at all to do for an `install` like the tup project does is simply not user-friendly. I install packages directly to `/usr/local/` all the time, and even ignoring that use-case there's no reason to leave the user wondering "Where do I put what files?". The developer know this information, the person attempting to use it or make a package generally doesn't (Or doesn't know all of them). Allowing you to define such a 'command' in the build system makes it a lot easier to write, and providing such a command makes the entire project tons easier to use and make into a package.