I heard about tup a while back and finally attempted to look into it today and try replacing some of my Makefile's with Tupfile's. Unfortunately my googling and researching all seem to indicate that tup simply doesn't support any type of .PHONY targets. To that end, `tup` also doesn't seem to support even "basic" stuff (from my POV) like a `clean` and `install` target - which is fine, except that without .PHONY targets you can't add support for such things in your Tupfile's. Even the tup project's Tupfile doesn't support any way of directly installing it, I had to just copy the files by hand.
IMO that's just a killer for me, which stinks because I don't really feel like such a feature should be that complicated, but the developers seem to take the stance that phony targets, and `clean` and `install` are unnecessary.
> ...phony targets, and `clean` and `install` are unnecessary.
For clean, there is a solution if you are using git; tup can generate a .gitignore for all the output files, and there is a git command to remove all ignored files. I'm with you on "clean" being something that is both easy to implement and useful in tup.
The author's stance on phony and install isn't that they are unnecessary, but rather that they are orthogonal to the problem Tup is trying to solve. install and phony targets are handled by an external script. I will have either a Makefile or a shell script that perform the tup invocation as part of the process.
The thing that tup does well is prevent you from making certain mistakes in your build system. If you have a missing dependency, it will error out; I have actually found bugs in makefiles that I converted to tup.
I read about the solution using `git`, but it definitely seems like side-stepping the problem. If you're going to provide a way to get a list of all the generated files so you can remove them by other means, why not just allow you to do it directly? But I don't think we're in disagreement here.
Perhaps I just don't completely understand what problem tup is trying to solve then. When I read about tup, I picture it being a complete replacement for something like make (And indeed, it says as much right on the website). Packaging a Tupfile along with a Makefile seems like an annoying solution to something that I really don't think should be a problem in the first place. It seems like taking a stance to a bit of an absurd degree for a feature I really don't think is that big of a deal. The author is free to do what they want, but I think they're sacrificing usability for purity.
Tup is appealing to me, but a tup/make combo isn't nearly as appealing.
Not providing a .PHONY equivalent makes sense to me: why not just turn those into separate shell scripts?
Clean and install seem like special cases though, the build system already knows what to clean up (or, at least, Tup seems to), and install should be handled by a proper package instead.
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.
IMO that's just a killer for me, which stinks because I don't really feel like such a feature should be that complicated, but the developers seem to take the stance that phony targets, and `clean` and `install` are unnecessary.