6 ms·

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 Linu

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.

UncleOxidant 3y ago
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.
jjice 3y ago
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.
stabbles 3y ago
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.
- tkiolp4 3y ago
  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.
  - getrealyall 3y ago
    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?
    - dima55 3y ago
      Yes. Thank you. Make is a victim of its own success in many ways.
    - shortrounddev2 3y ago
      > without the wonky syntax Idk about you but every shell syntax on a unix-like OS is wonky to me
      - getrealyall 3y ago
        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.
        shortrounddev2 3y ago
        I think people want a kind of declarative way for the application to pick up their files and build them, often simultaneously
    - jonathankoren 3y ago
      Make is literally a command runner. That’s all it does.
- silverwind 3y ago
  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.
  - shortrounddev2 3y ago
    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
  - nerdponx 3y ago
    DVC and Dud do this, but they're more meant for data analysis projects than building software. https://dvc.org/ https://dvc.org/ https://github.com/kevin-hanselman/dud/ https://github.com/kevin-hanselman/dud/
jonathankoren 3y ago
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.
- shortrounddev2 3y ago
  there's also nushell and powershell, which i think are an evolution over the shells which only pipe streams of bytes to programs
  - jonathankoren 3y ago
    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.
    - shortrounddev2 3y ago
      > 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
      - jonathankoren 3y ago
        The PROGRAMS. Who wants to rewrite everything because you can no longer pipe or redirect?
        shortrounddev2 3y ago
        You can still pipe
dima55 3y ago
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 https://remake.readthedocs.io/en/latest/debugger.html
pletnes 3y ago
You mean, just? https://github.com/casey/just https://github.com/casey/just
5- 3y ago
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 https://9p.io/sys/doc/mk.html 1. https://9fans.github.io/plan9port/ https://9fans.github.io/plan9port/ 2. https://tools.suckless.org/9base/ https://tools.suckless.org/9base/
gumby 3y ago
I use make to set up my environment (run conan etc) and to drive cmake. Works great.
neuronexmachina 3y ago
I'm also surprised there aren't any linters for Makefiles, at least not any that check more than a handful of rules.
colonCapitalDee 3y ago
I saw this further down in the thread: https://github.com/casey/just https://github.com/casey/just Looks like a version of make optimized for running commands instead of builds.
- nerdponx 3y ago
  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 "$@"

UncleOxidant 3y ago

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.

jjice 3y ago

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.

stabbles 3y ago

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.

tkiolp4 3y ago
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.
- getrealyall 3y ago
  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?
  - dima55 3y ago
    Yes. Thank you. Make is a victim of its own success in many ways.
  - shortrounddev2 3y ago
    > without the wonky syntax Idk about you but every shell syntax on a unix-like OS is wonky to me
    - getrealyall 3y ago
      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.
      - shortrounddev2 3y ago
        I think people want a kind of declarative way for the application to pick up their files and build them, often simultaneously
  - jonathankoren 3y ago
    Make is literally a command runner. That’s all it does.
silverwind 3y ago
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.
- shortrounddev2 3y ago
  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
- nerdponx 3y ago
  DVC and Dud do this, but they're more meant for data analysis projects than building software. https://dvc.org/ https://dvc.org/ https://github.com/kevin-hanselman/dud/ https://github.com/kevin-hanselman/dud/

jonathankoren 3y ago

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.

shortrounddev2 3y ago
there's also nushell and powershell, which i think are an evolution over the shells which only pipe streams of bytes to programs
- jonathankoren 3y ago
  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.
  - shortrounddev2 3y ago
    > 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
    - jonathankoren 3y ago
      The PROGRAMS. Who wants to rewrite everything because you can no longer pipe or redirect?
      - shortrounddev2 3y ago
        You can still pipe

dima55 3y ago

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 https://remake.readthedocs.io/en/latest/debugger.html

pletnes 3y ago

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

5- 3y ago

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 https://9p.io/sys/doc/mk.html 1. https://9fans.github.io/plan9port/ https://9fans.github.io/plan9port/ 2. https://tools.suckless.org/9base/ https://tools.suckless.org/9base/

gumby 3y ago

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

neuronexmachina 3y ago

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

colonCapitalDee 3y ago

I saw this further down in the thread: https://github.com/casey/just https://github.com/casey/just Looks like a version of make optimized for running commands instead of builds.

nerdponx 3y ago
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 "$@"