[nrclark]

Make can do all of those, easily, even eliminating TABs if you really care that much (I don't, my IDE handles them and it's really not a big deal). Have you ever taken the time to learn how to use it?

Make targets can be whatever you want, and don't have to produce files.

Make -n TARGET will list everything that Make thinks it needs to do to achieve TARGET, including anything that has to happen for any expressed dependencies (which can be tasks, and don't have to produce files).

Make recipes are arbitrary shell scripts that can do whatever you want, including changing directory. Make can also include other Makefiles, or call other Makefiles.

At its core, Make is a way to express "snippets of shell scripts, with a dependency graph between them". It can track files as dependency input and output -if you want-, but Make does not care if you don't. Call your targets whatever, and don't have them produce files. Boom, command runner. Make also has a powerful design, with a lot that you can do at parse-time.

And as it turns out, most tasks -do- have some amount of file dependencies. Maybe they need to consume a key file. Maybe they download a tarball. Maybe they produce a logfile that another task uploads. Being able to express as much (or as little) of that dependency graph as I want is a feature, not a bug.

[0points]

Give just a try, or don't.

But it's simply not true that Make does all of that.

I moved from make about 5 years ago, never been happier.

[nrclark]

Can you give me a specific example of what I said that's incorrect?

[sarlalian]

Make can't (at least that I've seen) enumerate it's own commands/targets. Yes there are recipes that you can cargo cult into your make file to do that using sed/awk but natively it doesn't have a way to enumerate it's commands/targets.

By the logic that since make exists, and can do everything, then we really shouldn't build any new command runners. Since C exists and can do everything we really shouldn't use rust, zig, java, python.

Make is great, I've used it for nearly 30 years now, and it's really good at certain things, but it's not particularly good as a generic command runner. It's difficult to debug, it requires a lot of extra boilerplate text to be an ok command runner.

Just is a more ergonomic tool than make to use as a command runner, zsh is a more ergonomic tool to use as a shell than sh.

Yes make, when combined with some other tools like sed/awk can do everything that just can do, just not as easily, and it definitely requires a lot more depth of understanding to write a well formed Makefile than it does a well formed justfile.

[cassianoleal]

Recent Make versions have a `--print-targets` option that lists all targets.

[freeone3000]

Having to “take the time to learn how to use it” is never a point in a tool’s favor. It might be worth the time, but even if all of that time is spent with Make, you end up at the same place.

[VWWHFSfQ]

Make is painful to use unless you're producing C object files. And even then it's painful to use.

But we get it, you don't want to try anything new.

[nrclark]

There's no reason to reinvent a tool that has literally decades of development behind it, is included in pretty much every Linux distro, and does what you need.

Dismissing it as being for olds is short-sighted.

[sarlalian]

There are plenty of reasons to reinvent tools that have existed for literally decades and are included in pretty much every Linux distro.

1. Someone wants to do it. Most open source is developed because someone just wants to. 2. You aren't happy with the language it's written in C vs Rust. 3. The tool is lacking some set of features that you want. 4. The tool isn't as easy to use as you would like. 5. The tool doesn't support some platform you care about. 6. Using the tool requires more knowledge or cognitive load than you would like. 7. The tool you are replacing has multiple variants that have different feature sets slightly different supported syntax (gnu make vs bsd make).

[jonjojojon]

Just has the advantage that it is really cross platform instead of having subtly different "makes" on the unixes and windows.

Same issue with bash. Having something that really cares about windows support is useful.