For a repo where an easy to install (single binary) dependency is a non-issue, consider using just. [1] You get `just -l` where you can see all the command available, the ability to use different languages, and overall simpler command writing.

[1] https://github.com/casey/just

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.

[1]: https://fishshell.com/docs/current/interactive.html

Although SCons is Python (which is a pro or con depending upon your perspective), it has strong dependency management. Or is the argument that dependency management is part of build, not general project maintenance?

If you go a bit further down this route, you end up with build tools that generate the compilation rules for you in some form: These are Automake/CMake/Meson and SCons. I did use scons years ago and it was nice, but its definitely completely lost its market share. IIRC Scons does this without generating Makefiles.

Task and Just are following a different route. The problem people have solved by using a "hack" in Makefiles (PHONY targets), so that you can easily run "sub-commands" in Make (make install_deps, etc). It would never occur to me to use Scons in that space.

Btw. a third option is to use a shell script like the following (POSIX-shell compatible actually).

  sub_install_deps() {
   set -e -x
   # ...
  }

  sc=$1
  case $sc in
  "" | "-h" | "--help")
   sub_help
   ;;
  *)
   shift
   "sub_${sc}" "$@"
   if [ $? = 127 ]; then
    echo "Error: '${sc}' is not a known sc." >&2
    echo "       Run '${prog_name} --help' for a list of known scs." >&2
    exit 1
   fi
   ;;
  esac

Like you, I use Make as a front end to lower level build tools. It seems to fit that role well.

I get it, I do. I know there's all sorts of legacy reasons, but my 4k resolution screen with 12GB vram and 32 cores still runs make build serially, outpitx to an 80x24 window and is bottlenecked down by stdout flushing, all because we can't change defaults.

I think cmake got this absolutely right, fwiw. You define the version of cmake you're writing against, and they go to great pains to ensure that they preserve behaviour even in newer versions of cmake. As an example, we could have a special variable:

    make_ver = 4.5

This would let make do things like accept spaces instead of tabs, be parallel by default, etc in future versions while presenting old behaviour.

If your build is extremely simple and fast then it cannot add value.