You can invoke it by naming a named rule, not a file, but the logic will remain.
If this is not what you want to be doing, and if your Makefile is full of .PHONY targets, you likely need a Justfile instead, or (worse) plain shell scripts.
I was using Make for running commands, but it interprets all command line parameters as build targets, which was annoying. And Bash scripts in Makefiles aren't type safe, became messy.
Nowadays I use Make only for building. And Deno + Typescript instead, for running commands & scripts.
(Hadn't heard about Just — the scrips aren't type safe though?)
Just runs code written in other languages. It's `sh` by default, but you can define anything (e.g. `python3 -c` to run Python scripts).
Just don't.
And do just :-)
Some people on HN believe that if you use make primarily as a task runner that you're doing it wrong and should use something else. I don't agree.
Most users are using multiple aspects of make: as a task runner and as something that handles the dependency graph when building something digital.
As a web developer, I used npm scripts, grunt, gulp, etc. to manage web builds but now I only use make and have gotten off the merry-go-round of web build tools.
When you create a Makefile, you're describing a dependency graph of what depends on what and the order tasks need to take to produce a particular set of digital artifacts--you're not writing shell scripts.
Turns out there are all kinds of edge cases and foot guns that make handles for you that you'd otherwise have to deal with if you wrote a bespoke shell script.
Plus make is battle tested and has been around since the dawn of Unix--there's literally no build scenario it can't handle.
I hadn't used make until a few years ago but it's been one of the best investments I've made in my workflow.
Well except this little case where some files or folders in your paths have spaces in them...
For example:
A) You have a recipe that installs dependencies if they're not up-to-date (such as "pip install").
B) You have a recipe that compiles stuff if it's not up-to-date; it's made to depend on A.
C) "make" can be an interface recipe that depends on B and does nothing else.
D) "make test" can be an interface recipe that depends on B, then runs tests.
E) "make run" can be an interface recipe that depends on B, then actually runs the code / a webserver to interact with.
Nowadays whenever I put one of these together there's 2 versions of A (one for python, one for node), 1+ versions of B (webpack build without watch, maybe others depending on the project), 3 versions of D ("test-js", "test-python", and "test" that does both, and each of them only requires the relevant parts of A and B).
Makes it trivial to ensure you're up-to-date after a "git pull" without having to waste time waiting on things that don't need updating.