Hacker News Reader

Comment by tkiolp4 | Hacker News Reader

Honest question: why don’t we see a new version of Make tailored to more modern use cases, and that is available immediately/automatically in the most used Linux distributions (e.g., Ubuntu, Debian, etc.)?

I’ve seen dozens of new libraries, frameworks and prog. languages appeared in the last 20 years… but no one is interested in improving Make? I’m not talking about creating an alternative (e.g., Task), I’m talking about Make 2.0

Same goes for Bash.

View on HN

Because Make is perfect for 99% of cases. And adding the extra 1% of features would be a mountain of extra work and complexity. Bazel does that, but I don't work on anything that needs its complexity, so for me and most other projects it wouldn't be a step forward.

Make is great. Even has a debugger: https://remake.readthedocs.io/en/latest/debugger.html

plan9 mk⁰ is a simplified and improved make derivative (the same is true for other components, and the entirety of the system, of plan9 in relation to unix).

mk is generally available in modern systems' package repositories through plan9port¹ or 9base².

0. https://9p.io/sys/doc/mk.html

1. https://9fans.github.io/plan9port/

2. https://tools.suckless.org/9base/

I think it comes down to user segmentation and legacy. There are a few tools that I feel could fit into this space but Make has serious legacy that would making moving projects, people, and build systems over a real pain. Same idea with Bash as well. Maybe we'll see it but I don't have a ton of faith.

I fully agree that Bash is trash. It's useful, but every control structure is convoluted crap. That said, there are probably hundred of alternatives. Csh is the most obvious. Why people continue to use sh, I'm not sure beyond historical reasons. Sure it's shipped, but csh is often shipped as well.

I use Bash because it's ubiquitous, it works well enough (even if it has several flaws), and because a lot of other people know how to use it. Find me another language that meets the same criteria while retaining the core syntax for executingprograms, redirection, and pipes, and I'll switch to it.

Csh and Tcsh might be improvements, but I don't know how to use them and none of my coworkers do either.

Powershell is an option at my particular company, but it has a handful of other problems (some of which are gradually being fixed in newer versions) and it's not "portable" to other organizations.

And I personally use Zsh, which I think is an improvement over Bash, but again, none of my coworkers know how to use it, even though it's the default of everyone's Mac.

People have similar complaints about SQL. It's kind of bad, but nothing has replaced it because it's just too hard to accumulate the critical mass of adoption for any one replacement.

there's also nushell and powershell, which i think are an evolution over the shells which only pipe streams of bytes to programs

Powershell is supposed to be good, but I’ve always been confused how it sends objects between programs. Seems like every program would have be modifed to support whatever rich IPC it uses.

Unix’s philosophy that everything is a file, and everything is stream of bytes is Good™. Dumb pipes and smart ends are future proof. The smarter the pipe, the more likely you’re going to run into things just not being possible.

> Dumb pipes and smart ends are future proof

Shell scripts should not live long enough to require being future proof. If you need to rely long term on some code, write it in an actual programming language

Where did you get this from? Who told you that shell scripts must have a lifetime and can't be crucial for production?

There is no such a thing as serious programming vs baby shell programming. There are just tools, that are means to an end, simple as that. If the tool sufficiently and efficiently does the job, there is no need to replace it with an 'actual' programming language.

The PROGRAMS. Who wants to rewrite everything because you can no longer pipe or redirect?

You can still pipe

No shit.

I don’t think you understand what I’m talking about. Powershell isn’t just a shell with some rudimentary flow control, like every Unix shell since thr 1960s. Powershell can hook together apps with a rich IPC objects, not just the old stream of bytes that kicked off this thread. In fact, I specifically mentioned its rich IPC as its nifty feature, and a feature that I did not understand how it worked, especially since it works in a backwards compatible fashion. THAT’S the thing that moves it beyond a stream of random bytes, to something with semantics. Maybe you didn’t know that, but it does. In fact, when it came out that was its marquee feature. That’s why I’m talking about IPC, and and the fucking programs. No one give a shit about a janky ass .sh file. It’s the thing that go in it. If the programs being connected together don’t understand the rich IPC channel, you’re stuck in the 1960s, like every other shell and scripting language, and so Powershell’s benefits are nonexistent.

This thread went from interesting to absolutely infuriating because you keep smuggly chiming in about things you apparently don’t understand.

Try working on your communication/interpersonal skills, man. You're not a good communicator because I had no idea what you were trying to say until this post. You also shouldn't get upset by discussions of shells on the internet. You probably should take some time away from the computer.

This statement:

> The PROGRAMS. Who wants to rewrite everything because you can no longer pipe or redirect?

Is almost unintelligible, aside from the fact that I guess it qualifies as a nearly-correct statement in English

> and so Powershell’s benefits are nonexistent

A world where every program talks via the same IPC is utopia. Claiming that pwsh benefits are nonexistent because of that, is absurd.

Besides, there are ways to mitigate this problem. As an example, many tools now accept and return json output, which means they can be easily hooked to pwsh via ConvertTo/From-Json without any parsing whatsoever.

GNU Make is still being developed. What features are you talking about? IMHO GNU Make is pretty complete, and it shouldn't change drastically.

Also note that ninja exists as an alternative.

Tracking files based on content hash in addition to timestamps would be a very nice feature Make could add in a compatible way. The current timestamp-only tracking is problematic in many environments, especially with Docker.

DVC and Dud do this, but they're more meant for data analysis projects than building software.

https://dvc.org/

https://github.com/kevin-hanselman/dud/

Also an easier way to search subdirectories without having to invoke the shell to enumerate those files. A runtime with filewatxhers for hotswap compiling of .o files at runtime. Basically all the stuff msbuild provides

I see teams using Make to execute commands (e.g., transpile this, rename that, etc.), as a replacement (or enhancement) of npm (in the node world), for compiling Golang binaries, and even for running stuff in the pipeline. Make is quite versatile, indeed, but it feels like modern teams are using it in a way Make was never intended to be used. That’s the reason why alternatives to Make have appeared. My take is: wouldn’t it be possible to update Make so that it fits more modern use cases more naturally? The problems with Make alternatives is that: they are many and they don’t come preinstalled with your usual Linux distribution. Make has that special place to be a greater tool than what it is right now.

Make is not a command runner. That people are abusing it as such doesn't mean make needs to change, it means people need to use the right tool for the job. Shell scripts can do the exact same thing without the wonky syntax or attempted dependency resolution, so why not just write a shell script? Hell, even npm has script running functionality. Is that not sufficient?

> without the wonky syntax

Idk about you but every shell syntax on a unix-like OS is wonky to me

That's fine, you can always use something like Perl or Python then. But at some point, it certainly seems like all people want to do is run shell commands, and a shell script is still the best way to do that.

I think people want a kind of declarative way for the application to pick up their files and build them, often simultaneously

Make is literally a command runner. That’s all it does.

Yes. Thank you. Make is a victim of its own success in many ways.

You mean, just? https://github.com/casey/just

It seems like most of the effort goes into creating Make replacements (Bezel, etc). I suspect the problem could be that a Make tailored to more modern use cases may end up being incompatible with current Make - or it could be that preserving compatibility with classic Make would make using the proposed added modern features awkward.

I saw this further down in the thread: https://github.com/casey/just

Looks like a version of make optimized for running commands instead of builds.

Can you pass extra args to a Just command?

Lacking a good way to do this was the #1 reason I moved off of Make:

  make test-foo TESTOPTS='-a -b -c'

Yuck.

My team now just adds a "run" script to all of our projects and it works well enough, no extra dependencies and no fussing around with the unfamiliarity of Make macros. Simple example of how this looks:

  #!/usr/bin/env bash

  set -eu

  venv=.venv

  test-coverage() {
    "${venv}"/bin/pytest --cov=src
  }

  coverage-report() {
    "${venv}"/bin/coverage combine || true
    "${venv}"/bin/coverage report
  }

  _run() {
    source "${venv}"/bin/activate
    "$@"
  }

  _run "$@"

I'm also surprised there aren't any linters for Makefiles, at least not any that check more than a handful of rules.

I use make to set up my environment (run conan etc) and to drive cmake. Works great.

Reply on news.ycombinator.com