5 ms·

Can somehow help me understand the advantages of Make over a bash script? Isn’t bash superior in almost every way?

outworlder 8y ago
If you are creating files, and these files depends on other files, Make will do the dependency resolution for you. This is difficult to do with Bash and a huge reason to use Make. Once you start abusing the ".PHONY" targets, the value starts to decrease.
duckerude 8y ago
Make has a dependency system. You can tell it how to create file A, and that it depends on file B, and tell it how to create file B. Then if you request file A, it will check whether file B exists, and create it first if it's missing or outdated. That's very valuable for building things. If you change a file, you only need to re-build the files that could reasonably be affected by the change. And things happen in the right order without micro-managing.
Pissompons 8y ago
They can produce the same result but they do it in different ways and require you to express it in different ways. Make has you describe a graph of outputs and how to produce them. It then traverses the graph to produce the requested output. Bash is just a regular sequence of commands, with functions and loops if you wish. If the pipeline you need to run can easily be turned into a dependency graph, I think make is a great fit. It's easy to use, comes with most of what you need built in and has some fun extras, like -jXXX, which allows you to parallelise things and built in caching so you don't regenerate the same asset twice if you don't need to. You can do all that in bash but you'll have to write it yourself, which takes time you could spend on other things.
tejtm 8y ago
Make is an excellent way to automatically decide to run your bash scripts (and other scripts, shell commands & executables) or not, all depending on if the existing output is newer than the available input
mmt 8y ago
In addition to all the features the sibling comments noted, it's important to note that there's no contradiction: bash is usually the scripting language one uses inside of a Makefile. It's the default, although one could use any scripting language. Point being, there's no "Make" language, beyond the syntax for describing those dependency relationships and variable assignments.
- pletnes 8y ago
  I believe /bin/sh is the default, not bash. But this can be changed.
  - mmt 8y ago
    You're right that it's /bin/sh, but, since it could be (and is, in some cases) bash, it's not quite right to call it "not bash", either. I'll grant that the distinction is important, though, in the face of the history of #!/bin/sh Linux scripts with bashisms breaking upon the Debian/Ubuntu switch to dash. Even if you're on a system where /bin/sh is bash, it's safest to set SHELL in your GNU makefiles to bash explicitly, if that's what you you're writing in.
mturmon 8y ago
The sibling comments give the top-level answer. In addition, expanding on @Pissompons's note -- make gives you job-level parallelism for free with constructs like: make -j 24 transform which will (if possible/allowed by the dependence structure in the Makefile) run 24 jobs at once to bring "transform" up to date. So for instance, if "transform" depends on a bunch of targets, one for each month across a decade, you get 24-way parallelism for free. It's kind of like gnu "xargs -P", but embedded within the make job-dispatcher.

If you are creating files, and these files depends on other files, Make will do the dependency resolution for you. This is difficult to do with Bash and a huge reason to use Make. Once you start abusing the ".PHONY" targets, the value starts to decrease.

duckerude 8y ago

Make has a dependency system. You can tell it how to create file A, and that it depends on file B, and tell it how to create file B. Then if you request file A, it will check whether file B exists, and create it first if it's missing or outdated. That's very valuable for building things. If you change a file, you only need to re-build the files that could reasonably be affected by the change. And things happen in the right order without micro-managing.

Pissompons 8y ago

They can produce the same result but they do it in different ways and require you to express it in different ways. Make has you describe a graph of outputs and how to produce them. It then traverses the graph to produce the requested output. Bash is just a regular sequence of commands, with functions and loops if you wish. If the pipeline you need to run can easily be turned into a dependency graph, I think make is a great fit. It's easy to use, comes with most of what you need built in and has some fun extras, like -jXXX, which allows you to parallelise things and built in caching so you don't regenerate the same asset twice if you don't need to. You can do all that in bash but you'll have to write it yourself, which takes time you could spend on other things.

tejtm 8y ago

Make is an excellent way to automatically decide to run your bash scripts (and other scripts, shell commands & executables) or not, all depending on if the existing output is newer than the available input

mmt 8y ago

In addition to all the features the sibling comments noted, it's important to note that there's no contradiction: bash is usually the scripting language one uses inside of a Makefile. It's the default, although one could use any scripting language. Point being, there's no "Make" language, beyond the syntax for describing those dependency relationships and variable assignments.

pletnes 8y ago
I believe /bin/sh is the default, not bash. But this can be changed.
- mmt 8y ago
  You're right that it's /bin/sh, but, since it could be (and is, in some cases) bash, it's not quite right to call it "not bash", either. I'll grant that the distinction is important, though, in the face of the history of #!/bin/sh Linux scripts with bashisms breaking upon the Debian/Ubuntu switch to dash. Even if you're on a system where /bin/sh is bash, it's safest to set SHELL in your GNU makefiles to bash explicitly, if that's what you you're writing in.

mturmon 8y ago

The sibling comments give the top-level answer. In addition, expanding on @Pissompons's note -- make gives you job-level parallelism for free with constructs like: make -j 24 transform which will (if possible/allowed by the dependence structure in the Makefile) run 24 jobs at once to bring "transform" up to date. So for instance, if "transform" depends on a bunch of targets, one for each month across a decade, you get 24-way parallelism for free. It's kind of like gnu "xargs -P", but embedded within the make job-dispatcher.