[aliencat]

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-argument...)

2. You cannot reference the target in the body of another target. (ref: 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-vari...)

[stephenr]

So.. you just don't want to type `./my-script foo` you want to type `bud foo`.. Cool story bro.

[aliencat]

No need for the sarcasm, it's open source, you don't have to use it. But to answer your question, you can't do `./my-script foo`, because you can't call a function directly as argument.

If you also want auto-completion, you bascially re-implemented Bud.