Your statements are correct, but they are workarounds, and doesn't cover all the use cases. And they usually requires a StackOverflow search. For the above 2 re

Your statements are correct, but they are workarounds, and doesn't cover all the use cases. And they usually requires a StackOverflow search. For the above 2 reasons, I consider them to be limitations. 1. Problem is You have to explicit define a number of arguments and they have to be named. Consider the situation where you want to call an arbitary number of arguments, can't do that. (ref: https://stackoverflow.com/questions/2214575/passing-arguments-to-make-run https://stackoverflow.com/questions/2214575/passing-argument...) 2. You cannot reference the target in the body of another target. (ref: https://stackoverflow.com/questions/3267145/makefile-execute-another-target https://stackoverflow.com/questions/3267145/makefile-execute...) Consider below: .PHONY: a b a: echo A b: echo B a # can't do this echo B 3. .PHONY should be the default when you don't use file target, which is often the case for most non-C project. With Bud, bash script become your Makefile and bash functions become your Make target. You can have arbitary numbers of arguments, you can reference other targets since they are just functions, and you don't need to explicitly add your target to .PHONY. There are other reasons you want to move away from Make. For example: * Defining variable in your target body requires workaround (ref: https://stackoverflow.com/questions/1909188/define-make-variable-at-rule-execution-time https://stackoverflow.com/questions/1909188/define-make-vari...)